Digital transformation is a service design problem, not a technology one

Digital transformation goes wrong when it is run as a technology programme: pick a platform, move the forms online, count the systems launched. The customer still meets the same handoffs, the same documents and the same waiting, only now on a screen. Treat it as a service design problem instead. Redesign what the person is trying to get done, end to end, front stage and back stage, and only then decide what the technology needs to do.

The belief, stated fairly

The belief goes like this: our services are slow because our systems are old. Replace the systems, put the services online, and the experience will improve by itself.

It is not a foolish belief. Old systems do slow things down. Paper does get lost. Many services really are better online, and some can only scale that way. Technology spend is also easy to plan, approve and report on. It has vendors, milestones and a launch date. A leadership team can see it happen.

So the instinct to start with technology is understandable. The trouble is what it leaves out.

Why it fails in practice

It digitises the process, not the outcome

The first move in most programmes is to take the existing form and put it online. Every field, every attachment, every signature step survives the move. The customer who used to queue at a counter now uploads the same seven documents to a portal, then waits for the same three departments to approve in sequence. The service is digital. It is not better.

Services cross departments; programmes don't

A customer experiences one service: "renew my licence", "open an account", "register my child at school". Inside the organisation that service runs through several departments, each with its own system, budget and targets. Technology programmes are usually scoped department by department, so each part is modernised and the joins between them, where most of the delay lives, are left alone.

Melvin Conway observed in 1968 that organisations tend to produce designs that mirror their own communication structures. Digital services prove him right daily. If three departments do not talk to each other, the portal will have three sections that do not talk to each other either.

Nobody designs the back stage

The screen the customer sees is the front stage. Behind it sit the people, policies, approvals and systems that actually deliver the outcome. G. Lynn Shostack first described the service blueprint in 1982 and brought it to a wide business audience in a 1984 Harvard Business Review article, precisely to make this hidden part visible. Most transformation programmes design the front stage in detail and leave the back stage as it was. The result is a polished app on top of a process that still needs a manager's signature on paper.

Success is measured as delivery, not change

"Systems launched", "services online" and "percentage digitised" are activity measures. They can all go up while the time to get a result, the number of repeat contacts and the drop-out rate stay flat. When the scorecard rewards launches, teams launch. (Measuring the right thing is covered in Measuring transformation by outcomes, not activity.)

What works instead

Treat the service, not the system, as the unit of transformation. In practice that means five habits.

1. Name the outcome the person wants. Not "submit application" but "be allowed to open my shop". Write it in the customer's words. This sets the boundary of the work, and it is almost always wider than one department.
2. Map the whole service as it runs today. Use an experience map to see it from the customer's side, then a service blueprint to see the back stage: who touches the case, what they check, what they wait for. Walk the service yourself; don't map it from the procedure manual.
3. Question every step before you digitise it. For each document, approval and field, ask: why is this here, who uses it, and what happens if we remove it? Policy and process changes are usually the cheapest and largest improvements, and they cost no code.
4. Test the new service before you build the system. Run the redesigned journey by hand for a few weeks with a small group, a concierge test, or put a simple front end on top of people doing the work manually, a Wizard of Oz test. You learn what the technology actually needs to do, which is usually less than the specification said.
5. Give one person the whole service. Appoint a service owner with authority across the departments involved, and measure the service by what the customer gets: time to outcome, steps, repeat contacts, drop-outs.

Technology then becomes what it should be: the way the redesigned service is delivered at scale, not the redesign itself.

An example

Illustrative. A city council in a mid-sized European city ran a three-year programme to "put business licensing online". The new portal launched on time. Applications still took around the same number of weeks, and calls to the contact centre rose, because applicants could not tell which of four departments was holding their file.

A small team was asked to look again. They blueprinted a single journey, a café owner applying to open, and found eleven handoffs between planning, environmental health, fire safety and licensing, each of them waiting for the previous one to finish. Three of the documents requested were already held by another department. Two approvals were sequential only by habit.

They ran a manual pilot for one district: one case officer owning each application from start to finish, the departments reviewing in parallel, and the duplicate documents dropped. The portal stayed, but its job changed: it now showed the applicant one owner and one status. The pilot told the council exactly which integrations were worth building and which were not needed at all.

Do's and don'ts

Do

• Start with one high-volume service, not the whole organisation.
• Put the people who deliver the service in the room, not only those who manage it.
• Blueprint the back stage before writing any technical requirement.
• Treat policy and procedure as design material, not fixed constraints.
• Test the new journey by hand before committing to build.

Don't

• Move a paper form online field for field.
• Scope the work by department or by system.
• Report "services digitised" as success.
• Let the vendor's product shape decide how the service works.
• Hand the redesign to IT alone, or to service design alone. It needs both, with the business owner leading.

Questions people ask

Is service design just customer experience with a different name? No. Customer experience work often focuses on what the customer sees and feels. Service design covers that and the back stage: the staff, rules, systems and handoffs that produce the experience. For transformation, the back stage is where most of the change has to happen. If you are choosing between the two maps, see Journey map or service blueprint?

Do we still need a technology roadmap? Yes, but it should follow the service redesign, not lead it. Once you know how the service should work, the roadmap describes what the systems must do to support it. Many organisations find the list gets shorter.

Where do we start if everything needs fixing? Pick the service with the most volume and the most complaints, map it end to end, and fix the joins between departments first. One service done properly teaches the organisation more than ten half-done. Before you redraw anything, it helps to map the system before you change it.

Where to go next

This piece sits under the hub's main article, Transformation fails at the customer's door. For the hands-on work, start with the service blueprint and experience map, use a system map to see which departments and rules shape the service, and a touchpoint matrix to see every channel the customer crosses.