A nationwide identity verification exercise is only as good as its ability to reach the diverse range of people it needs to cover. It is relatively straightforward to design a process for office-based staff who hold complete documentation and are comfortable filling in a form. It is a genuinely harder design problem to build a process that works equally well for the driver, the groundskeeper, the cleaner, and the messenger — colleagues whose employment is just as real, but who may not always have every document to hand, and for whom completing a detailed form unaided is not a realistic expectation.
This was a central design consideration for 2M Corp in supporting the Government of The Gambia's Ministry of Public Service with the in-person verification exercise delivered under the World Bank-supported Public Administration Modernisation Project (PAMP).
A Two-Stage Process, Deliberately Ordered
The verification process was structured around two distinct stages, run in a specific order for good reason. The first stage, the document check, required each individual to present a small set of mandatory documents — a national identification or alien registration card, a Tax Identification Number certificate, and an appointment or promotion letter. Only individuals who passed this initial check moved on to the second stage, the verification form, where biometric data, employment details, and current contact information were recorded.
Placing the document check first, as a gate, rather than folding everything into a single long process, kept the exercise efficient at national scale. It separated a quick, well-defined screening step from the more detailed data capture that followed, and it meant the small number of cases needing follow-up on documentation could be identified and managed separately, without holding up the flow of individuals who were ready to complete the full process in one visit.
According to the exercise's public completion report, this design held up well in practice, with document-check pass rates reaching 99.3 per cent across civil servants and pensioners by the close of the exercise.
Designing the Verification Form Around the Person, Not the Paperwork
The verification form itself was deliberately built to be enumerator-led rather than self-administered. A trained verification officer conducted each session directly with the individual being verified, asking questions and recording responses on a mobile device rather than handing over a form and expecting the individual to complete it independently.
This matters enormously for an exercise covering the full breadth of the civil service workforce. A person's ability to participate should not depend on their comfort with reading a form, filling in fields, navigating a device, or understanding administrative terminology. In this model, the trained officer carries that burden throughout the session. Biometric and photographic capture also reduced reliance on information that the individual had to enter unaided.
Each verification session was kept short and structured — around fifteen minutes — striking a balance between the depth of data required and the practical need to keep the process predictable for people across different occupations, levels of seniority, and degrees of familiarity with formal administrative systems.
The broader principle is important for digital government: digitising a public process should reduce the burden placed on the individual, not simply transfer administrative work from government staff to the person being served. A system can be digital without requiring every user to become the system operator.
Anchoring Verification to an Existing Payroll Reference List
A verification exercise also needs a controlled way of determining who is expected to appear in the process.
2M Corp used the entity list functionality within ODK Central to support this. Before fieldwork began, the official payroll list supplied for the exercise — more than 50,000 records, each with an employee number, name, and organisation — was loaded into the system as an entity list.
During verification, field teams searched this pre-loaded list to locate each individual by name or employee number. Once selected, the person's existing details could populate relevant fields in the form. This reduced repetitive data entry and, more importantly, anchored the verification workflow to the population the government had asked the exercise to review.
Anyone presenting for verification who could not be found on the pre-loaded payroll list was therefore treated as a discrepancy requiring investigation rather than being quietly added to the registry on the strength of documents presented that day. Because the system also tracked which individuals from the reference list had been seen and which remained outstanding, it provided real-time visibility into verification coverage and supported targeted follow-up.
The entity list was not treated as proof that the payroll itself was correct. Like many administrative datasets, the source list contained historical and operational problems, including people who were no longer active. The reference list therefore served as a starting population to be checked, not as an unquestionable source of truth.
Designing for Legitimate Exceptions
In-person verification remained the primary operational backbone of the exercise, but the project methodology also provided a complementary self-service pathway for a limited set of cases where physical attendance was less practical, including some staff posted overseas or on approved leave.
The important design choice was that the alternative channel did not replace the main process or relax the verification standard. It existed to accommodate legitimate exceptions while keeping the core verification logic intact.
This is a useful principle for government systems more generally: a standard workflow should handle the majority of cases efficiently, while controlled exception pathways deal with the smaller number of situations that genuinely do not fit the default process.
A Process Designed for the Whole Workforce
Taken together, the design reflected several deliberate choices: a clear two-stage process; enumerator-led data capture that did not assume literacy or administrative familiarity; an entity-list mechanism that anchored each case to the official payroll reference supplied for the exercise while still allowing that source data to be questioned; and controlled alternative pathways for legitimate exceptions.
The broader lesson is that inclusive digital government is not achieved simply by putting a form on a screen. It requires designing the process around the people who must actually use it, acknowledging the limitations of existing administrative data, and deciding carefully where technology should enforce a rule and where human judgement must remain part of the system.
