A Pilot Is Not Yet a Public Service

The pilot worked. Twenty participants used the new service, feedback was enthusiastic and the presentation ended with a photograph of the team. A minister or executive called it the future. Funding was announced for expansion.

This is the moment when optimism meets a different kind of work.

A pilot is designed to learn under limited conditions. Participants may be recruited specifically, staff may receive extra training and the project team remains close enough to solve problems personally. Exceptions can be handled in a chat. Data can be cleaned by hand. The service has an end date, so unresolved questions can be placed in a later phase.

A public service has no such protective boundary. People arrive without fitting the recruitment criteria. They use old devices, speak different languages, miss letters, share addresses and have needs that cross organisational departments. Demand changes with policy, seasons and events. A failure can affect income, care, housing or legal rights.

Scaling is therefore not the multiplication of the pilot. It is a change in the nature of the promise.

The first reality test is operational ownership. Who answers when a person cannot complete the process? Who monitors failures outside office hours? Which team corrects bad data? A pilot often relies on the goodwill of its creators, but goodwill is not a support model. Responsibilities need funding, tools, authority and a path for escalation.

The second test is exception handling. Demonstrations favour the happy path because it shows the concept clearly. Real services are defined by what happens off that path. A person may lack the expected identity document, disagree with a record or need someone else to act on their behalf. If the digital route cannot accommodate them, the service must provide an accessible alternative without turning difference into delay or suspicion.

Integration creates another challenge. The pilot may operate with a small copied dataset. A live service connects to records whose definitions developed over decades. Updates arrive late. Identifiers conflict. Upstream systems have maintenance windows. A technically elegant feature can become unreliable because the surrounding information was never designed for its assumptions.

Procurement and policy shape the result too. A prototype team can change a component in a day. A contracted service may require approval, supplier coordination and security review. Policy can mandate a process the interface cannot simplify. Transformation that ignores these constraints produces a modern surface over unchanged institutional complexity.

None of this means pilots are deceptive. They are useful instruments when their claims match what they test. A pilot can show that people value an idea, that a workflow is understandable or that a technology performs under a stated load. It cannot prove nationwide operability if it relies on manual intervention hidden from the evaluation.

A responsible pilot report should therefore include the scaffolding. How much staff time was required? Which participants were absent? What work happened outside the software? Which exceptions were deferred? What would fail first at ten times the demand? This information is not an admission of weakness. It is the evidence needed for the next decision.

The report should follow participants beyond the successful transaction as well. Did the new route create later calls, corrections or uncertainty? Did staff maintain parallel records to feel safe? Short evaluations often count completion and miss the work required to make that completion trustworthy. A service is the whole consequence, not the moment a screen declares success.

Sometimes the answer should be to stop. An experiment may create a pleasant experience for most users while making essential cases harder. Its operating cost may consume funds needed elsewhere. The underlying policy may need reform before a new interface can help. Ending a pilot can preserve better possibilities if it releases attention and makes the lesson available.

When an idea does deserve to continue, expansion should proceed through capabilities as well as numbers. Build support, governance, accessibility research, incident response and internal skill. Test in places where conditions differ, not only where sponsorship is strongest. Give frontline staff a meaningful role in redesign.

Better futures are not built from pilots alone. They emerge when institutions can absorb learning, carry responsibility and sustain useful change after the original excitement moves elsewhere. The ribbon-cutting moment is only the beginning. Reality starts the following morning, when an ordinary person needs the service to work.