Citizen portal and e-government

An online form bolted onto a chain that stayed manual moves the wait, it does not remove it.

Parent division: Software and systems

The problem

The difficulty of an online procedure is not the form; it is the processing behind it.

Many portals publish a form, send an acknowledgement, then drop the request into a mailbox that officers handle as before. The user has saved a journey; the administration has gained nothing, and sometimes lost, because inbound volume rose while processing capacity did not.

A procedure is worth its complete chain: submission, completeness check, assignment, processing, requests for further documents, decision, notification and archiving. Every step left manual caps the whole.

Then there is access. A share of the population submits from a phone, on a slow and metered connection, sometimes with neither printer nor scanner. A portal designed for a desktop on a fast link excludes precisely those for whom the journey costs most.

The complete chain of a procedure, schematic

01Online submission: Progressive form, saved draft, document upload from a phone.
02Completeness check: Before submission. It is what decides the first-time completeness rate.
03Assignment and processing: Work queues, deadlines, automatic reminders, reasoned decision.
04Notification and archiving: Decision notified, file archived, exercise of data subject rights provided for.
05Physical counter: Kept open, and feeding the same queue: otherwise two queues coexist and their delays drift apart.
06Request for further documents: The most frequent step and the least supported. Handled outside the portal, it destroys traceability.

Schematic. The accented path is the loop most portals leave outside the system.Typical figures. The archiving period follows the obligation applying to the act, checked procedure by procedure; the time shown is that of an online response, not of processing.

Scope

What the service covers

Procedure analysis: A survey of the real journey, the documents required and their legal basis, observed delays, grounds for rejection, and the points where files stall.
Online counter: Progressive form, saved drafts, document upload from a phone, completeness check before submission, an acknowledgement that serves as proof, and visible file status.
Processing: Assignment to departments, work queues, traced requests for further documents, deadlines and automatic reminders, reasoned decisions, signature and notification.
Identity and payment: User identification proportionate to what the procedure engages, connection to the payment methods actually used locally, and the receipt attached to the file.
Interoperability: Interfaces with registers and management systems, documented exchange rather than re-keying, data reconciliation and handling of divergences.
Operation and steering: A dashboard of volumes and delays, measurement of the first-time completeness rate, logging, archiving, and a procedure for exercising data subject rights.

Situations

The most frequent situations

Certificate or attestation request: High volume, short processing, strong expectation on turnaround. What matters is the completeness check and automating production of the document.
Authorisation or licence: Long processing, opinions from several departments, many documents. What matters is traceability of each opinion and a delay the user can read.
Periodic declaration: The same users return. Carrying over the previous file’s data reduces keying errors, which are the leading cause of rejection.
Single multi-service counter: Several procedures, one point of entry and one status view. The difficulty is the heterogeneity of the management systems downstream.

Requirements

What to require, of us as of anyone

These requirements hold whichever supplier is appointed. Written into a tender, they filter out the responses that will not hold.

Treatment of the complete chain, from submission to notification, and not of the form alone.
Real usability on a phone, on a slow connection, with page weight kept under control.
Accessibility for people with disabilities, verified by testing rather than declared.
A dated acknowledgement that serves as proof, and a file status the user can read.
A non-digital channel kept open for those who cannot submit online.
Measurement of real delays and of the first-time completeness rate, published internally.
Data hosted within the applicable legal framework, and a procedure for exercising data subject rights.

Pitfalls

Common mistakes, and what they cost

Digitising the form without revisiting the procedure: Documents required out of habit stay required. The portal reproduces existing complexity while making it more visible, and the rejection rate does not fall.
Designing for a desktop: Most submissions come from a phone. A long form, a heavy page or an upload that assumes a scanner pushes part of the public away.
Not planning for requests for further documents: It is the most frequent step and the least supported. Handled outside the portal, by phone or email, it destroys traceability and lengthens a delay nobody can be held to.
Closing the physical counter at go-live: A share of users cannot submit online. Closing it early turns progress into a break in access to the service, and concentrates the grievance on the portal.

Questions

Questions asked before consulting

Which procedure should come first?

One with high volume and short processing, whose internal chain can be handled in full. It produces a measurable result quickly, trains the teams and sets the reference for the next ones. Starting with the most complex procedure risks putting nothing into service at all.

What level of identification should be required?

A level proportionate to what is at stake. A request for information does not call for the same assurance as a binding declaration or access to personal data. Identification too heavy for the stake makes people abandon the procedure; identification too light exposes the administration.

How are users without internet access handled?

By keeping a reception channel and having an officer enter the request into the same tool. That is what lets the administration steer every file, whatever the channel, and avoids two processing queues whose delays drift apart.

Should payment be integrated?

Where the procedure carries a fee, yes, relying on the payment methods actually used locally. The delicate point is not collection but attaching the receipt to the file and reconciling the accounts, both designed alongside the counter.

How is a portal’s success measured?

By the real delay between submission and decision, the first-time completeness rate, the share of files needing further documents, and the abandonment rate mid-form. Visit counts measure nothing useful.

Where is the data hosted?

Location is a decision, not a technical detail. An administration’s data sits within a legal framework that determines where it may reside, who may reach it and how long it is kept. The answer is documented before go-live, together with the procedure allowing a person to exercise their rights.

Evidence

Where we have applied it

Government and public administration2023
Public administration — case-handling platform
Digitisation of a public-facing service, designed to remain usable on unstable connections and outside the capital.
Counters deployed
9
Months of programme
11
Reference KP-2023-005