Service blueprinting

Service blueprinting shows how an organisation delivers a specific customer experience. It maps customer actions alongside visible interactions, backstage work and supporting processes. Use it when a problem crosses teams or systems, or when the customer-facing step alone cannot explain what happened.

Keep the organisational view in focus

A blueprint records the organisation’s perspective on creating an experience, not only the customer’s actions, thoughts or feelings. It connects the people, processes and physical or digital evidence involved to the customer’s touchpoints and goals.

Set out the business goal the blueprint supports. Goals can include reducing duplicated work, improving the employee experience or bringing siloed processes together. The goal keeps the map focused on a decision the organisation can act on.

Choose one customer task

Start with a task and an outcome the customer can recognise. For example, a customer might request an invoice correction and need an accurate replacement. This is an illustrative scenario.

Set the start and end points before mapping. Which customer and situation does the blueprint represent? Does it cover the usual route, an exception or both? If an exception changes the work substantially, show a separate path or blueprint so its details remain visible.

If a customer journey map already describes this task, its customer actions can provide a starting row. Check that it reflects the current service. The blueprint adds the work needed to deliver each stage; it does not replace evidence about what customers experience.

Set a scope that fits the task

A touchpoint is a specific interaction between a customer and an organisation; not every customer action is one. Scope can be small (two touchpoints or fewer), medium (five touchpoints or fewer) or large (an end-to-end experience with a product or organisation).

Choose the level that suits the blueprint’s goal and the time available. A defined customer task can keep the work focused, while an end-to-end scope may suit a decision about the wider service. The same service may need separate blueprints for different scenarios.

Build the layers around the same sequence

Lay out the task from left to right. Under each customer moment, record the relevant layers:

Mark the line of visibility between activities the customer can see and those they cannot. Show where information or responsibility passes between activities. Add timing, policy constraints or case status when those details help answer the question at hand.

In the hypothetical invoice correction, the customer may submit a query and later receive a corrected invoice. Behind those moments, staff may check the original charge, authorise a change and produce a new document. These are possibilities to investigate, not steps to assume every business follows.

Customer Actions vs. Backstage Work in Service Blueprinting

Check the map against the work

Include people who perform the relevant frontstage and backstage work. Ask what they receive, do and pass on. Compare their accounts with suitable case records and customer evidence where access is authorised.

Distinguish a confirmed step, a staff account and an unanswered question. Agreement in a workshop does not verify that every case follows the agreed route. Check relevant exceptions and recent cases before treating the diagram as a current-state account.

Name roles rather than individuals. Give each activity enough detail to show its handoff and outcome; keep operating instructions elsewhere.

Bring the relevant functions together

Blueprinting suits an experience that involves multiple touchpoints, channels or departments. Include the people whose work contributes to the customer’s task, so the map connects what customers encounter with how the organisation delivers it.

Use it to make a decision

Read across a troublesome customer moment, then down the layers beneath it. If the customer receives no update, ask whether one was triggered, whether the case reached the right queue and who was meant to send the message. The diagram locates questions; it does not prove their answers.

Record a possible failure with its customer consequence, supporting evidence, uncertainty and next check. Decide whether to investigate further or propose a change. Label a proposed route clearly until it has been checked in use.

Revisit the blueprint when a rule, system or handoff changes. Check the customer’s outcome as well as the internal step: a request marked complete may still leave the customer without the corrected invoice.

Use the wider view to frame service decisions

Treat the blueprint as a decision aid rather than a complete account of the service. Its wider view can show where an internal weakness may contribute to a poor experience, but the diagram only identifies what to check; any change still needs to be tested in use.