Start after the submit button
A citizen fills out a form on a phone. The submission arrives in an inbox. An officer downloads the attachment, prints it and takes it to another desk. The website has done its job. The service has barely begun. This is the distinction that matters when a government commissions software: a form is an interface; a process is a sequence of responsibilities, evidence and decisions. Moving the interface online does not automatically change that sequence.
The right starting question is what happens next. Who receives the application? What tells them it is complete? Which activities require a referral? Can those referrals happen at the same time? Who has authority to approve an extension? Where is the reason for a refusal recorded? These questions can sound administrative beside a demonstration of new technology. They are also the questions that determine whether an applicant waits days or months.
Make the route explicit
A process that lives in the experience of individual officers can work remarkably well until someone is absent, a category changes or the volume rises. The software should make that knowledge explicit without pretending every application is identical. A configurable catalogue connects the type of application to its questions, requirements, fees and referral route. The catalogue is part of the service, not an obscure setting reserved for the engineering team.
This changes what it means to put a service online. The application enters a known state. The next responsible person or team is identified. Missing information produces a request that belongs to the record. A review produces a recorded outcome. The decision is attributable to a named officer. The register is updated from the decision, rather than reconstructed later from a folder of issued certificates.
Exceptions need a route too. A system should distinguish an incomplete application from one awaiting another agency, and both from one awaiting an applicant’s response. A single label reading “pending” hides the work. Clear states make the delay legible to the people who can do something about it. That is useful even before anyone adds a dashboard.
Measure the waiting, not just the clicking
The speed of a web form is easy to demonstrate. The time spent waiting between actions is harder to see and usually matters more. An officer may need only a few minutes to review a record that has sat unassigned for several days. Improving the review screen alone will not remove that delay. Routing, queue ownership and a visible clock address a different part of the problem.
Working-day clocks also need rules. Public holidays, requests for information and authorised extensions cannot be treated as incidental details after the timer has been built. The service owner must decide which events affect the clock, and the software must record those events. A condition nobody checks is not a condition. A deadline nobody can reconstruct is not much of a control.
The same discipline applies to results. A useful measure says which part of a process changed and for whom. Application completion, officer review and final issuance are different intervals. They should not be collapsed into a single number because the number looks better on a slide. A before-and-after comparison needs a stable definition before it needs a chart.
Keep the counter in the design
A public service cannot assume every applicant has the same device, connection, confidence or ability to upload a document. Assisted submission should enter the same workflow as an online application. Otherwise the digital service creates a second administrative system beside the first, with different records and different visibility. The counter remains part of the service even when fewer people need to use it.
The officer interface deserves the same attention as the applicant interface. A clear queue, a readable document, a visible requirement and a well-placed request-for-information action can remove repeated work throughout the day. That is less conspicuous than a new homepage, but it is the experience the ministry is operating after the launch photographs are finished.
The deliverable is a service that runs
An acceptance test should follow an application all the way through. Test a complete submission, an incomplete one, a parallel referral, an extension, a refusal, an approval and a renewal where the service has one. Ask the officers to explain what the system shows at each step. If the explanation depends on a private spreadsheet outside the application, there is still work to examine.
The final handover must preserve the operating knowledge as well as the code. Requirements, permissions, process maps, migration records and runbooks explain how the service is maintained. Training should happen by role on the system officers will actually use. A government should not need to reverse-engineer the supplier’s assumptions to change a fee or understand a decision.
A useful scoping session can trace one ordinary application and one difficult one. Ask the officer to bring the forms, correspondence and records used at each step. Write down every hand-off and every place where information is entered again. Then ask which rules are fixed, which are configurable and which need an authorised exception. This produces a practical implementation brief. It also gives the ministry a way to test the proposal: the supplier should be able to explain how the difficult application will move through the new service, not only how a clean application appears in a demonstration. The map should remain readable by the people who own the process.
The form matters. It is often the first part of government a person encounters. But the promise made by that first screen is fulfilled elsewhere: in a queue, a referral, a review and a recorded decision. That is where digital government becomes an operating service. That is the work underneath the website.