The Digital Government Outlook 2026, published by the OECD on 15 June, discusses how the adoption of artificial intelligence (AI) in government is developing, while gaps in implementation and impact measurement persist. It highlights the role of data, digital infrastructure and skills. I read these findings as a way into a question that matters for every service project: what do we track after the system goes live?
Use and impact are complementary questions
The number of logins or registered applications tells us that the service is being used, but on its own it does not explain what has improved for the service user. So I would add indicators for task completion, repeat enquiries, applications returned for missing items, and the time staff spend correcting data or searching for it.
Indicators also need clear definitions. Does an application's processing time start when the form is opened or when submission is complete? Does the clock stop while waiting for documents? How are exceptional cases treated? Documenting the answers makes results comparable and stops interpretations from diverging between departments or across time periods.
Feedback complements the numbers
The numbers may show that a particular stage takes a long time, and then a short interview with a user reveals that the cause is an unclear name for a required document. That is why I prefer to collect feedback tied to a specific task and to link it to operational data. The useful question is what the person was trying to get done and where they needed help.
With AI tools, it is possible to track how much correction a draft needs and which types of error keep recurring. If the system saves writing time but adds checking time, both should show up in the evaluation. Cases the system could not handle also deserve separate analysis, to understand the limits of its use.
An improvement cycle that can be sustained
- Define a clear task and, where data is available, a baseline before the change.
- Agree on a few indicators that the team can interpret.
- Collect feedback from staff and service users and link it to the task.
- Try a specific improvement, then compare the results and document what remains unresolved.
Training, as I see it, belongs in this cycle. Staff need to understand which cases the system can handle, and how to correct an error or escalate an exception, not just where the buttons are. It also helps when recurring questions from training go back to the design team so that the interface and the procedure can be clarified.
What I am looking for is accountability that continues after launch: a service owner who knows what is happening, a team that reviews the evidence, and improvements that can be traced to a specific user need.