One of the more useful things a platform can tell you is what it is not for. Most software does not do this well: it is easier to describe what a tool does than to state clearly where it stops, even when the boundary is deliberate.
ZeePMT has one. It is worth stating plainly.
The boundary: field data collection
ZeePMT does not provide household- or beneficiary-level field data collection. It does not manage offline survey capture, enumerator routing, mobile form design at scale, or the infrastructure needed to collect and aggregate structured responses from large numbers of individual respondents in the field.
That is a positioning decision, made for a specific reason.
Why the boundary is where it is
Field data collection is a distinct product category. It has its own technical demands: offline-first architecture, conflict resolution for data collected without connectivity, mobile device management, form logic at the complexity level needed for household surveys. It is well served by specialist tools built specifically for that job.
The organisations ZeePMT is built for (implementing agencies, large NGOs, development-sector consulting firms) frequently use those tools, and they should continue to do so. The question is what sits above and around them.
What most field data collection tools do not cover is the operational layer that precedes and follows data collection: the request that triggered the activity, the expert mobilised to design or oversee it, the action plan that situated it within the programme, the budget line that funded it, and the donor report that will draw on its results. That operational governance layer (request to closure, with the roster and calls layer built in) is what ZeePMT models natively.
What interoperability means here
The right approach for a TA facility that needs both is to find tools genuinely built for each part of the job and connect them at the data handoff that matters.
For most facilities, that handoff is from operational activity record to indicator value. ZeePMT holds the activity record (the what, who, when and budget) and can receive indicator data from field tools at the level of aggregation that belongs in the logframe. That keeps the detailed field data where it is best managed, while the programme-level results picture stays connected to the delivery record.
The practical test
If the core workflow you need to manage is a request arriving, an expert being mobilised, an action plan executed, and results reported to a donor, ZeePMT is built for that workflow end-to-end.
If the core workflow you need to manage is: enumerators collect household data across dozens of communities, validate it offline, and upload it for aggregation, ZeePMT is not the right tool, and no configuration will make it one.
Most facilities need both. The answer is two tools that each do their job well.
The bottom line
ZeePMT is built around a specific operational model: the project cycle and logical framework as they apply to externally funded technical assistance. Its scope is a consequence of that, not a gap waiting to be filled. Where the platform stops is where a different specialist tool begins.