Anuar submitted an application online, saw a green tick and closed the page. He thought he was done. A few days later it turned out the application had only been received: it would still be reviewed, and a response would follow. The confirmation screen reported one stage, and Anuar read it as a promise that the whole service was delivered.
Marketing a public service explains the path from a need to an outcome. That is why the team measures submission, channel choice and what happens after submission with different metrics. For an appointment-booking service, a good outcome is a successful booking, the time it took, the errors along the way and satisfaction. Creating an account is only an intermediate step.
Example stages of a public service
On-screen confirmation
Message about the receipt stage
- Further processing
- Review and decision
Service outcome
A separate stage after review and response
Application receipt confirmation reports one stage of the path.
Name the operation being measured
Every process has its own boundaries. For a form, the result is a submitted application. For a booking, a chosen and confirmed time. For a payment, a payment that went through. Someone who opened an information page has not started the operation; for now they are only reading.
In the GOV.UK Service Manual, completion rate is completed digital transactions relative to those started. For an application, submission can count as completion, whatever the decision turns out to be. That is the British manual's method, and the team agrees the events for its own service with the service owner and the delivery staff.
A metric's name should repeat the boundary you chose. "Completed submission" is about the form. "Received a response to the application" is about the next stage. Call both of them "success" and the report can no longer show where applications get stuck or who should fix it.
Link repeat attempts to one case under a rule agreed in advance. Otherwise someone who came back several times to upload a document turns into several operations started. Keep technical tests out of user cases. And before comparing percentages, write down what counts as one operation and when its observation ends.
Separate three calculations
Take a service whose application can be filed on eGov or at a TsON public service centre. All figures and costs below are made up for the example. Of 1,000 eGov cases that started the process, 600 completed submission within a sufficient observation period. Repeat attempts are linked and technical tests excluded. Over a comparable period, TsON centres accepted another 400 unique applications, none of them duplicating the digital ones.
| Question | Calculation | Value |
|---|---|---|
| What share of those who started finished digital submission? | 600 / 1,000 | 60% |
| What share of accepted applications arrived digitally? | 600 / (600 + 400) | 60% |
| What share of digital applications reached a response? | Later processing data is needed | Not yet known |
Both shares come to 60% by coincidence: their denominators differ. The first holds digital starts, the second accepted applications across all channels. The digital take-up method uses completed digital transactions and completed transactions across all channels over the same period. In our example the common boundary across channels is an accepted submission.
Say that by the report date people had received a final response for 480 of the 600 digital applications, while 120 were still being processed. The share with a response is 480 / 600 = 80%. A response can be a refusal with an explanation, so 80% is the share of responses, and the approval rate is a metric of its own. To talk about delays you need each application's age and the deadline that applies to it.
For journey analysis, events are linked within the same cases. A calendar report shows another side of the work: how many applications came in during the month and how many responses went out. Some of those responses may concern applications from earlier months. So monthly responses divided by monthly starts do not give one group's conversion rate until the cases are linked.
Explain the budget without inventing savings
Say an information campaign for this service cost 240,000 ₸. Divided by all 600 digital submissions, that is 400 ₸; divided by the 480 responses received, 500 ₸. These figures show spending against a chosen volume of the service. They do not show what an extra submission brought by the campaign cost: some people would have come to eGov without any ads.
To estimate the added result, you need a suitable comparison and an account of everything that changed at the same time. Seasonal demand, the queue at TsON, how the form worked and new guidance could all move application numbers in the same month. In the report, keep the observed volume and the conclusion about the ad effect on separate lines.
Time savings are also measured across the whole journey: preparation, filling in, waiting, corrections and help. Someone may fill in the form in a couple of minutes after spending half a day looking for the right certificate. And even hours saved that you have measured need to be tied to a change in how work is done before anyone announces budget savings.
Investigate obstacles with the user
If a noticeable share of cases stops at file upload, the events show where to look. Watching people go through the form and reading support requests explain why. The person may not have understood the document's name, may not have had the file in the right format, or could not find an explanation of the error on their phone.
A user's age, language and address will not tell you how confident they are with a phone. Look at what happened at the step and what help the person looked for. Judge a change to the form both by how many people got through the upload and by the quality of the applications after it: if incomplete documents start going through faster, the work simply moves to the delivery staff.
Build the guidance around the person's task: who the service is for, what to prepare, where to start, what it costs and how long it takes, what happens after submission. Get the conditions from the service owner. Invent a deadline to make an ad persuasive, and people will wait for something the delivery team never promised.
"Application received. Check its status in the applications section" works if the system really accepted the application and the status really shows there. "Service delivered" is a different state of the process. Agree these words with the product team and support so everyone explains the same path to the person.
Preserve access to help
Someone may start alone on eGov, go to a TsON consultant for help and finish online. Keep three cases apart in your records: finished alone, finished online with help, served at a TsON. Help counts towards the digital share under an agreed rule, but the flag showing that a staff member helped is kept.
Language versions are checked in full: instructions, fields, errors and the final status. For accessibility, the journey is also tested with a keyboard and with assistive technology. A translated heading does not help if the error text is still unclear.
If an office visit is needed after submission, people should know in advance. If you remove in-person help to make the online share look good, the people who need it are the ones who suffer. Next to the channel share, keep successful completions, time, errors and feedback about the help received.
After a one-off life event, a person may never need the service again. So retention is measured where the need recurs. For a one-off application, it matters more to bring the journey to a clear outcome than to get the person to open the app again next week.
Exercise: explain a higher digital share
In the next period, digital submissions are again 600, while other channels receive 200. Calculate the new share, describe the change in words and list the information missing for a campaign decision. Then, for your own service, write down where the operation starts and what ends it, how you count help and which quality metric you will use.
The new digital share is 600 / (600 + 200) = 75%, up from 60%. Other channels got fewer applications. It is easy to sell this rise as a campaign success, although not a single additional person came online: submissions stayed the same. Demand, access to help at TsON or a change in record-keeping could have caused the shift, and one calculation cannot pick the cause. You need starts, responses received, turnaround times and the reasons people abandoned the form.
For an appointment-booking service, a strong problem statement ties a successful booking to the time it took, the errors and satisfaction. Growth in accounts created says nothing about whether the person booked. With that report, the team improves access to the service and explains where the money went without substituting intermediate steps for the goal.