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 and precise.
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 not a gap waiting to be filled. It is a positioning decision, and it was 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 honest position for a TA facility that needs both is not to find a single tool that does everything, but to find tools that are each genuinely built for their part of the job, and to 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 arrives, an expert is mobilised, an action plan is executed, results are 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 right answer is two tools that each do their job well, not one tool that does both badly.
The bottom line
A platform that claims to do everything is a platform that has not made hard decisions about what it is for. ZeePMT's scope boundary is not a limitation to be apologised for. It is a consequence of being built around a specific operational model — the project cycle and logical framework as they apply to externally funded technical assistance — rather than adapted from generic software after the fact. Knowing where the platform stops is, in that sense, the clearest indication of where it starts.