Service blueprint: connect the customer journey to the work behind it

A service blueprint connects what a customer does and encounters with the work that makes those encounters possible. Use it when a service promise depends on several people, systems or suppliers, and a journey map leaves you asking, “What has to happen behind this moment?” The useful output is a visible dependency you can investigate or redesign, with an owner and a next action.

Start with one customer scenario. “Everything our organisation does” is too broad. “A commuter brings a bicycle with a damaged wheel, approves a repair and collects it” gives the map a beginning, an end and a service promise to examine. A blueprint can describe today’s process or a proposed future process; label which one you are drawing.

Connect the visible encounter to the hidden work

Blueprinting has a long history: G. Lynn Shostack published Designing Services That Deliver in January 1984. A later Arizona State University account of the approach explains its customer-centred starting point and the connection between service encounters and internal work. This is a mapping technique, rather than a promise that drawing the map will improve performance.

Nielsen Norman Group’s description identifies customer actions, frontstage actions, backstage actions, support processes and service evidence. Frontstage includes visible digital interactions; backstage means activity hidden from the customer. One employee can perform both kinds of work.

Its boundaries clarify the relationships: the line of interaction separates customer actions from direct service encounters; the line of visibility separates visible and hidden activity; the line of internal interaction separates contact work from supporting functions. Service evidence means encountered objects or artefacts, such as a receipt or screen. It does not mean research proving a claim.

For the bicycle example, use these working questions:

Layer	Question to ask	Example entry
Customer actions	What does the person do to obtain the repair?	Describes the fault and approves the quoted work
Frontstage	What does the person encounter?	Adviser explains the price and collection estimate
Backstage	What hidden work enables that encounter?	Mechanic checks wheel damage and compatibility
Support processes	What enables the people doing that work?	Supplier confirms stock; the purchasing system records the order
Service evidence	What object or message shapes the encounter?	Repair ticket, estimate and collection notification

Use journey mapping first if you need to understand the customer’s sequence, expectations or difficulties. Add the blueprint when you need to connect those moments to delivery. An internal workflow may begin with “create job”; this scenario begins with the customer’s need for a usable bicycle.

Gather enough information to map a real scenario

Bring people who know the customer encounter and people who know its dependencies. In this example, that means an adviser, a mechanic, someone who orders parts and someone who can change the booking rules. Use stakeholder mapping to find missing knowledge and decision authority before inviting a larger group.

Avoid filling the customer row entirely from staff expectations. The Government Digital Service experience-mapping guidance recommends building a map from research and distinguishing different experiences where needed. A useful preparation pack might contain anonymised repair tickets, customer accounts, a short walk-through of the stock check and an example collection message. Choose material relevant to the scenario rather than everything available.

Use customer interviews to understand why collection timing matters. Use observation to see what staff actually do when a required part is unavailable. These answer different questions: a customer can describe the consequences of a late repair, while a counter walk-through can reveal when a provisional date becomes a promise.

Give each important entry a simple status:

• Observed: supported by a specific record or witnessed action.
• Reported: described by a customer, employee or supplier; record who and when.
• Assumed: plausible but not checked.
• Proposed: part of a future design.

These labels are an original working convention for this guide. They stop a remembered exceptional event, a normal process and a preferred future process from quietly merging into one confident-looking diagram. Keep identifying customer details out of a shared workshop map.

Build a compact first version

Allow about an hour for a first mapping session once the preparation exists. That is a suggested starting allocation, not a researched optimum. Longer or more complex services may need several sessions. Keep the initial map small enough that the people doing the work can challenge each column.

1. State the scenario and scope. Name the customer goal, starting event, ending event and process version. For this example, exclude a new-bike purchase and repairs discovered after collection.
2. Place customer actions across the page. Use short verbs: brings, describes, approves, waits, collects. Record exceptions separately before they overwhelm the main path.
3. Add the encounters. Put the quote conversation, approval message and collection notification beside the relevant customer actions.
4. Trace enabling work backwards. Ask what must be known or completed before each promise can be made. Add parts checks, repair capacity and supplier confirmation where they matter.
5. Connect the dependencies. Draw an arrow only when one action supplies something another action needs. Label the needed thing in your working map: confirmed stock, agreed price or completed inspection.
6. Mark uncertainty and choose a handoff to examine. Finish with a question, an owner and a date. A tidy map without a next action has not resolved the service problem.

During the session, ask the mechanic to explain a counter assumption and ask the adviser to explain a workshop assumption. For example: “Does stock available mean the part fits this wheel?” and “Does an estimated completion date get presented as a guarantee?” This exchange is often where the map becomes useful.

Worked example: a bicycle repair promise

The following business, events and proposed changes are hypothetical. They illustrate how to reason with a blueprint, rather than report a successful intervention.

The shop’s fictional problem is that customers sometimes arrive for collection while their bicycle is still waiting for a replacement component. An initial explanation blames slow suppliers. The map below instead makes several possible explanations visible. No explanation has yet been established as the cause.

Blueprint layer	Intake and estimate	Approval and preparation	Repair and collection
Customer action	Brings bicycle; explains need to commute	Approves price; plans transport around estimate	Arrives after receiving collection message
Frontstage action	Adviser gives price range and provisional date	Adviser sends agreed quote and describes remaining uncertainty	Adviser sends ready message and hands over bicycle
Backstage action	Mechanic checks damage and identifies compatible part	Mechanic confirms required part; adviser checks available repair slot	Mechanic completes repair and final checks; updates job status
Support process	Parts catalogue provides compatibility information	Supplier confirms availability; purchasing records expected arrival	Job system makes completed status available to the adviser
Service evidence	Repair ticket and written estimate	Approval message and updated estimate	Ready message, invoice and repaired bicycle

Read a column vertically to see the dependencies around an encounter. Read a row horizontally to see whose actions change over time. A parts check performed after a definite collection promise creates a different risk from the same check performed before it.

The table is a compact teaching version. On a workshop board, add arrows between cells and place the three boundaries between the relevant action layers. Keep the evidence artefacts alongside the encounters they shape; their position does not make them proof that the process works.

The initial blueprint raises three questions. Does the mechanic confirm compatibility before the adviser quotes a date? Is the supplier’s availability confirmed or merely shown in a catalogue? What event triggers the collection message? Put uncertain answers on an assumption map rather than resolving them through the loudest person’s recollection.

Find the handoff that breaks the promise

Suppose a follow-up walk-through in the fictional example finds that “part ordered” and “repair complete” look similar in the job list. The adviser occasionally reads the former as a reason to contact the customer. This is an illustrative finding added to the scenario; it is not an observed result from an actual shop.

The team can now describe a narrower problem: the collection message lacks a reliable completion signal. Faster suppliers may still matter, but they do not directly resolve this particular handoff.

Use a handoff record like this:

Field	Entry for the fictional repair
Customer promise affected	A ready message means the bicycle can be collected
Sending role	Mechanic responsible for the job
Receiving role	Adviser who contacts the customer
Information required	Repair finished, required checks completed, bicycle available
Current uncertainty	Job list makes an order event look like a completion event
Proposed change	Separate completion status; require mechanic confirmation before notification
Exception route	Adviser contacts mechanic directly when status is unclear
Next observation	Check which event preceded each ready message in a bounded pilot

This record is an original worksheet, not a universal blueprint notation. Its purpose is to turn an arrow into something that people can verify. Name a role able to own the change; “the team” is too vague when a message is sent incorrectly tomorrow.

Avoid solving every highlighted issue at once. Use concept development to work up a coherent change if several touchpoints need redesign. For a small status change, sketch the proposed screen and message rules, then ask both roles to walk through a normal repair and an unavailable-part exception.

Test the delivery change and keep the map usable

A future-state blueprint is a proposal. Use concept testing to check whether customers understand the provisional estimate and ready message. Use a bounded experiment design to examine whether the operational handoff behaves as intended.

For example, the fictional shop might track the next ten eligible repairs for which a replacement part is needed. It records the confirmation event, ready-message time, collection outcome and any staff workaround. Ten is an illustrative workload choice, not a statistically justified sample size. Without a suitable comparison and design, fewer problems would not establish that the new status rule caused the difference.

Review what happened to the whole promise. A rule that prevents early messages could still leave customers uninformed about delays. Check whether the adviser can provide an honest update when the part is late, and whether the mechanic’s extra recording task creates another bottleneck. Decide in advance who will suspend the pilot if a status becomes unreliable.

If a system change is required, the software-rollout playbook can help turn the proposed workflow into a supported adoption plan. Check change readiness when the repair team lacks time, access or authority to maintain the new rule. An improved diagram cannot supply those conditions.

Keep the blueprint’s scenario, owner and revision date visible. Update the relevant part when a supplier rule, message trigger or responsibility changes. Separate the current map from the proposed map so a new colleague can see which process is actually operating.

What the blueprint cannot establish

Bitner, Ostrom and Morgan’s 2008 article presents blueprinting as a customer-grounded approach to service innovation, with case examples. The accessible publisher abstract supports that description; it does not establish a general causal effect on complaints, revenue or repair performance.

A blueprint also cannot tell you which customer scenario is most common, prove that a depicted cause explains a failure, or guarantee that staff will follow a redesigned process. Those questions require suitable research, operational evidence and follow-through.

Before acting, ask whether the map represents the people affected, whether its uncertain entries are visible, and whether the proposed change protects the complete customer promise. The practical next step is one verified dependency and one bounded change, with a person responsible for learning what happens.