Transformation fails at the customer's door: how to design change people feel

Transformation succeeds when two things change on an ordinary working day: how front-line people do their jobs, and what the customer experiences at the moment they deal with you. Most programmes change the structure, the systems and the slide deck, and stop before those two places. The fix is to design the change from the customer's moment backwards, map the system that produces that moment, and let the teams who do the work own the roadmap and the measures.

This is the pillar of our Transformation series. It maps the whole topic and links to the deeper pieces on each part.

Why transformation stops before it reaches anyone

Picture a typical programme. A new operating model is approved. Departments are renamed. A platform is bought and configured. Dashboards go green. Eighteen months later, a customer calls with the same problem they had before, gets passed between the same three teams, and waits the same number of days. The staff member who answers the phone still uses a workaround because the new system does not handle the cases she sees every week.

Nothing in that story is a failure of effort. It is a failure of where the effort was aimed. Programmes are usually designed from the top of the organisation down: strategy, structure, technology, process, people. The customer appears at the end, as a satisfaction target. By the time the change reaches the front line it has been translated so many times that nobody can say what should feel different on Tuesday morning.

Three patterns show up again and again:

• The change is organised by department, but the customer moves across departments. Each unit improves its own part. The handovers between them, where most of the pain sits, belong to nobody.
• Activity is measured instead of outcome. Training sessions delivered, systems launched and policies published are counted. Whether a single customer waits less is not.
• The people who do the work are informed, not involved. They receive the new process at a briefing. They know exactly why it will not work in the hard cases, and nobody asked them.

We look at the second and third patterns in depth in why transformation programmes produce reports and nobody changes how they work.

The four layers of a transformation people feel

It helps to hold transformation as four layers, from the outside in. Change has to be designed in all four, and in that order of attention.

1. What the customer feels. The moments where a customer, citizen or employee meets your service: the form, the call, the counter, the message, the wait. This is the only layer anyone outside the organisation experiences.
2. How people work. The front-stage and back-stage actions that produce each moment: who does what, with which information, in what sequence, and with how much discretion.
3. The system underneath. Policies, approval rules, IT systems, data, incentives, budgets and reporting lines. This layer decides what people are allowed and able to do.
4. How the change is run. The roadmap, ownership, governance and measures that steer the programme over months and years.

Most programmes start at layer four and spend their energy on layer three. The customer layer is treated as a result that will follow. It rarely does, because nobody has designed the link between a new policy and a different moment at the counter.

Customer-experience work starts from the opposite end. If your organisation is still building that habit, read customer-centric is a practice, not a slogan: where to start alongside this piece. Transformation is where that practice has to scale across the whole organisation.

How to design change people feel: seven steps

These steps work for organisational and digital transformation alike. They are not a replacement for programme management. They are what you put inside it so that it lands.

1. Choose journeys, not departments

Pick three to five customer journeys that matter most to the organisation's purpose and that cross several units: "getting a permit", "making a claim", "joining as a new employee", "changing a payment plan". Organise the first wave of transformation around those journeys. Each journey gets a small cross-functional team with a named owner who has the authority to change things across department lines.

Choose journeys where you already hear repeated complaints, where demand is high, or where a strategic goal is at stake. Avoid starting with the journey that is politically safest; it teaches the organisation that transformation is cosmetic.

2. Go and see before you design anything

Before any workshop, the journey team experiences the service as a customer would and watches it being delivered. A service safari puts team members through the journey themselves. Contextual observation means sitting with front-line staff while they work, noting every workaround, spreadsheet and phone call that the official process does not mention.

This step changes what the programme believes. Senior people routinely discover that the process they approved is not the process that runs.

3. Map the experience and the work behind it

Draw the current journey with an experience map: stages, actions, thoughts, feelings and pain points from the customer's side. Then draw the service blueprint underneath it, the tool G. Lynn Shostack introduced in the 1980s, which shows front-stage actions, back-stage actions and support processes, separated by the line of visibility.

The blueprint is where transformation becomes concrete. You can point to the exact handover where a case waits four days, or the step where staff re-enter data because two systems do not talk. If you are unsure which of the two maps you need first, see journey map or service blueprint.

4. Map the system before you change it

The blueprint shows the work. It does not show why the work is the way it is. For that you need a system map of the rules, incentives, data flows and decisions that hold the current pattern in place, and a stakeholder map of who gains, who loses and who must sign off.

Add a force field analysis, Kurt Lewin's tool for listing the forces pushing for and against a change. It often reveals that the strongest restraining force is a single approval rule or a reporting metric, not resistance from people. The full how-to is in mapping the system before you change it.

5. Design the new moments and the new work together

Now design the future journey: which moments change, what the customer should feel at each, and what each person behind the line of visibility will do differently. Design layer one and layer two in the same session, with front-line staff in the room. A new customer promise without a new way of working behind it is a slogan.

Test the new moments before you build anything. A role-play of the new counter conversation, run with real staff and a few real customers, exposes gaps in an afternoon that a system build would expose in six months. For the full range of cheap tests, see testing an experience before you build it.

6. Build a roadmap the teams own

Turn the designed changes into a roadmap organised by journey and by outcome, not by system release. Each item says which moment it improves, which team owns it and what will be retired when it lands. Use a RACI for the cross-department decisions, so that handovers have an owner.

Ownership is the point. A roadmap written by a programme office and handed to teams is a schedule. A roadmap the journey teams wrote, and revise every quarter, is a commitment. How to set this up is covered in running a transformation roadmap that teams own.

7. Measure what people feel, and retire what they no longer need

Build a KPI tree that connects the strategic goal to journey outcomes (time to resolve, repeat contacts, cases completed first time, effort) and down to the operational measures teams can move. Report those, not the count of workshops or go-lives. The method is in measuring transformation by outcomes, not activity.

Then keep a stop-doing list. Every new process should switch off an old form, report, approval or system. Transformation that only adds is how organisations end up with the new way and the old way running side by side, and staff doing both.

Where digital transformation fits

Digital transformation is the most common version of this problem, and the most expensive when it goes wrong. A new platform replicates the old process on a screen, or forces a process the front line cannot use, and the customer sees a nicer interface on the same delay.

Treat every digital initiative as a service redesign that happens to involve technology. Start from the journey and the blueprint, decide which moments and handovers should change, and only then specify the system. The argument is made in full in digital transformation is a service design problem.

If you need to know how ready the organisation is to run this kind of work, an innovation maturity assessment gives you a baseline. If the transformation agenda itself is unclear, start with building an innovation strategy in a few workshops.

Illustrative example: a utility's new billing system

Illustrative. A regional water utility in a mid-sized European country is two years into a transformation programme. The centrepiece is a new billing and customer platform. It has gone live on schedule. Complaints about bills have not fallen, and call handling times have risen.

The programme director asks for a different approach on one journey: "my bill looks wrong". A team of six is formed: two call-centre advisers, a billing analyst, a field technician, an IT product owner and a customer-service manager as journey owner.

They spend a week on a service safari and sitting with advisers. They find that advisers cannot see meter-reading history in the new platform, so they raise a ticket to billing for every query. Billing works the tickets in batches. The customer is promised a callback in five days and often gets a letter instead.

The blueprint shows three handovers where cases wait. The system map shows why: a data-protection rule had been interpreted to restrict meter data to the billing team, and billing's own target counts tickets closed, not queries resolved at first contact.

The team designs a new moment: the adviser explains the bill on the first call. Behind it, advisers get read-only access to meter history, agreed with the data-protection officer, and a short script for the three most common causes. They role-play it with ten volunteer customers before any configuration change. The billing target moves to queries resolved first time. The callback letter is added to the stop-doing list.

The roadmap item is owned by the call-centre team, not IT. The measure reported to the board is the share of bill queries resolved on the first contact, tracked monthly.

Do's and don'ts

Do

• Start with a small number of cross-department journeys and give each a single owner with real authority.
• Put front-line staff in every design session, not only in the briefing afterwards.
• Watch the work before you redesign it. The official process and the real one are rarely the same.
• Map rules, incentives and data flows; that is usually where the change is blocked.
• Test new moments with role-play or a manual pilot before configuring systems.
• Run a premortem on each roadmap item: imagine it has failed in a year, and list why.
• Retire something every time you launch something.
• Hold a retrospective with each journey team every quarter and change the roadmap based on it.

Don't

• Don't measure success by go-lives, training hours or the number of processes documented.
• Don't redesign the organisation chart first and hope the customer experience follows.
• Don't let the programme office write the roadmap alone.
• Don't digitise a process you have not looked at; you will automate the waiting.
• Don't run customer-experience work as a separate stream beside the transformation. It is the transformation's test of whether anything changed.
• Don't announce a new customer promise before the work behind it has changed.

Questions people ask

Why do most transformations fail? Rarely for lack of effort or money. They fail because the change is designed and measured at the level of structure and systems, and never designed down to the specific moments customers and staff experience. The handovers between departments, where most delay and frustration sit, belong to nobody, so they stay the same.

What is the difference between transformation and change management? Change management is usually about helping people adopt a change that has already been decided. Transformation, done well, involves those people in deciding what changes in the first place. The methods here make that possible: staff help observe, map, design and test the new way of working, so adoption is not a separate problem to solve later.

How do you know a transformation is working? Look at the customer and the front line, not the programme. Are journeys faster or easier on measures customers would recognise? Are repeat contacts falling? Have staff stopped using workarounds? Has anything old been switched off? If the answer to all four is no, the programme is busy, not working.

Where to go next

Start with one journey. Use a service safari to see it as a customer does, a service blueprint to see the work behind it, a system map to see what holds it in place, and a KPI tree to decide how you will know it changed. All 75 method guides are in the guides library.