Digital public services citizens can finish online

A form on a portal is not a service

Many digital government projects begin and end with a form. The institution publishes a web page, citizens fill it in, and then the real work starts: someone prints the application, a file travels between desks, and the applicant is asked to come in with originals. Technically the service is online. In practice the citizen still has to visit an office.

A digital public service is finished when a person can start it, pay for it, prove who they are, track it and receive the outcome without leaving home. Anything less is a digital front door to a paper process.

Map the journey end to end

We begin with a single service and map how it works today, from the moment a citizen realizes they need it to the moment they hold the result. Include the back office. Who receives the request, who checks it, who approves it, where does payment get reconciled, and how is the decision recorded and communicated?

This map shows where the time goes, and it is rarely the form. More often it is the hand-offs: a file waiting in a tray, a query that needs a phone call, a payment that has to be matched by hand. The online design should remove those waits, not reproduce them.

Identity, eligibility and payment

Three things decide whether a citizen can finish online.

• Identity: the portal must establish who the applicant is, securely, without a visit. Access control and audit trails are designed in from the start and aligned to the data protection rules the institution operates under.
• Eligibility: where possible, the service should check entitlement against registries the institution already has, instead of asking the citizen to prove it with paper.
• Payment: fees should be payable online and reconciled automatically against the application, so revenue is collected digitally with a full audit trail.

If any one of the three still requires an office, the journey is not complete.

Do not ask twice

Citizens routinely give the same information to several institutions. Each one stores it separately and asks again next time. Integration between the portal and existing registries, databases and records systems removes that duplication. Data is fetched securely from where it already lives, and the institution that owns it stays responsible for it.

This is usually harder than building the portal. Systems differ, data quality varies and agreements between institutions take time. It is also where most of the benefit lies, so it deserves early attention rather than a later phase.

Design the back office as carefully as the front

Staff who process requests need a workflow as thoughtful as the one the citizen sees: a queue, clear statuses, the ability to request more information, rules for escalation and a record of every action. Case management turns an inbox full of applications into work that can be assigned, tracked and measured.

Digitized records matter here too. If a decision depends on a paper file, scanning and indexing that archive is part of the project, not an optional extra.

A public service is only as digital as its slowest paper step.

Make it work for everyone

Public services are for the whole population, so accessibility is a requirement, not a refinement. Design for mobile phones first, since many citizens will use nothing else. Use plain language, support assistive technology and keep pages light for slower connections. Provide an assisted route for people who cannot or prefer not to use the portal. Offering that alternative is part of a good digital service, not a failure of it.

Measure completion, not launches

The measure that matters is the share of citizens who start a service and finish it. Track where people drop out, ask why, and fix those points first. Track how long each case takes from submission to decision, and where it waits.

A good first project is a single, high-volume service done thoroughly. It proves the pattern, builds trust inside the institution and gives you a foundation to extend.