All articles
6 October 2026·Marta Rey·4 min read

Inside a TA Request Record: The Unit of Accountability

Inside a TA Request Record: The Unit of Accountability

There is a moment in every TA facility's workflow where something informal becomes something formal. A partner institution has identified a need — a gap in capacity, a reform that requires external input, a peer who should be brought in to share experience. They communicate that need, usually by email, sometimes by phone, occasionally in a meeting whose minutes someone has to write up afterward.

What happens next determines the quality of everything that follows. If the need is captured as a structured record — one that names the institution, the scope, the focal point and the expected results — it becomes the foundation for a traceable programme of work. If it is captured as an email thread or a line in a shared spreadsheet, it becomes something the team manages around rather than something they manage with.

What a request record actually contains

The value of a structured request record lies in what it holds together in one place.

Identity

The requesting institution, the programme it sits within, the focal point responsible for the submission. These fields make up the accountability chain. When a funder asks which partner institution this delivery was for, the answer should not require reading through emails to find the original message.

Scope

The sector, the geographic focus, the type of expertise required, the expected results. Scope defined at intake is scope that can be assessed, approved or declined on a consistent basis. Scope communicated informally is scope that drifts — the request that arrives as one thing and is delivered as another, with no record of when or why it changed.

Status history

Who reviewed the request, who approved it, at what date and under whose authority. The status history is the decision trail: proof that the right people made the right decisions in the right order, recorded as those decisions were taken rather than reconstructed later.

Linkage

The action plan the request triggered once approved. That link closes the loop: the request is not just a record of what was asked. It is the origin point of a chain that runs through programming, expert mobilisation, delivery and reporting.

ZeePMT requests list showing request codes, titles, countries, current statuses and performance ratings across the portfolio
ZeePMT — The requests list: the full portfolio of assistance requests, each with its status and linked record.

The status lifecycle

A request moves through a defined sequence of states, and each transition is recorded. Submitted. Under review. Approved. Programmed. In delivery. Completed. Archived.

That sequence matters because different roles have different permissions at different stages. A focal point at a partner institution may submit a request but not approve it. A programme officer may review and validate it but not authorise it above a certain threshold. The programme director's approval closes the review stage and opens programming.

When those role-bound transitions are enforced by the system, the sequence is not a procedure that depends on everyone remembering their part. It is a structural property of the record. No request can be programmed before it is approved. No budget can be committed against an activity before the action plan is in place. The rules are built in.

ZeePMT request detail showing the full record for a single request: institution, focal point, sector, status log and linked action plan
ZeePMT — A single request in full: scope, decision trail and the action plan it triggered, all in one record.

Why the record is the unit of accountability

The phrase "unit of accountability" sounds abstract until you have to answer a hard question from a donor or auditor. Who authorised this assistance? Which institution requested it? What was the approved scope? Was it delivered as specified?

If every request is a structured record with a status history and a link to the delivery that followed, these questions have clear answers. If the request was an email and the approval was a reply, they are nearly impossible to answer well.

The request record is the point from which everything else can be traced. That is the precondition for running a traceable programme of work at all.

The bottom line

A TA facility that treats requests as structured records — from the moment of submission through to the completion of the assistance they triggered — has a factual basis for every downstream decision. The expert was deployed because this activity required this expertise, under this approved request, from this institution. The cost was incurred because this contract was raised, against this budget line, within this approved programme of work. That chain of custody is available immediately, not assembled under pressure when it is needed.

Published by ZeePMT — the operations platform for Technical Assistance Facilities.

See it in action

Run your facility in one system. Request a demo.

We'll walk through the full assistance cycle — requests, experts, monitoring and reporting — tailored to your context.