Date:
Author:
in2o Team
001
The whole journey, including the parts you don’t own
Most service improvement projects begin where the organization’s system meets the user, because that is the part the organization controls. But a beneficiary experiences one journey, not a set of handoffs — and the steps that cause the most damage are usually the ones between departments, where nobody is accountable for the wait.
Mapping the journey end to end — including the step handled by another entity, the document that comes from a third party, the phone call that is logged nowhere — almost always relocates the real problem. It is rarely where the budget was pointed.
002
What happens backstage decides what appears on screen
A service is a system with a front and a back. What the beneficiary sees is the last few centimetres of a chain that includes a policy, a form, an approval threshold, a staff member’s discretion, and a system that may or may not talk to another one.
When the front is redesigned and the back is not, the result is a faster route to the same bottleneck. Working backstage first — simplifying the rule before automating the form, removing the approval before speeding it up — is less visible and considerably more effective.
003
Prototype the service, not just the interface
A prototype does not have to be software. A service can be tested with a printed form, a staffed desk, a scripted phone call, or a small set of real cases run manually for two weeks.
The point is to find where the design breaks under real conditions before the cost of change rises. Once a service is built into a system, every assumption inside it becomes expensive to revisit. Testing the model early is the cheapest insurance a transformation programme can buy.
004
Instrument the experience from day one
An experience that is not measured drifts. Decide before launch what you will watch: the completion rate, the point where people abandon, the volume of calls asking the same question, the share of cases that need a second submission.
These are not satisfaction scores. Satisfaction tells you how people felt; operational signals tell you where the service is failing them. Collect both, and design the improvements from the second.
