01 / UNDERSTAND
What is a service blueprint?
A service blueprint connects a customer’s actions with the work that makes a service possible. It distinguishes what the customer encounters from what happens behind the scenes, including the supporting processes and dependencies. Use it for one scenario at a time, with a clear start and end. A current state blueprint describes delivery as it works today; a future state blueprint describes a proposal. Label the difference.
Why use a service blueprint?
A late confirmation can look like a communication problem while its cause sits in scheduling. The blueprint lets people who own different parts of the service examine the same event. It supports a decision about the handoff, not just the screen where a symptom appears. Its usefulness depends on the connections being checked with the people doing the work.
When to use a service blueprint
USE IT WHEN
An experience crosses teams, channels or operational systems.
You need to understand the delivery conditions behind a known customer problem.
A proposed improvement changes responsibilities or internal handoffs.
When to choose another method
Use Customer Journey Map first if the experience itself is poorly understood.
Use Stakeholder Map to identify actors before describing their work in sequence.
Use Usability Testing for a focused interface problem without a delivery dependency.
What you’ll need
Choose a scenario and gather customer evidence alongside accounts of the operational process. Include people who do the frontstage and backstage work. Bring relevant forms, messages and system records, with sensitive details removed. Agree whether the exercise describes the current service or a proposal. Keep disputed steps visible until someone can verify them.
How to read the lines. The line of interaction marks exchanges between the customer and the service. The line of visibility separates what the customer can see from backstage work. The line of internal interaction separates customer-facing delivery roles from supporting activities. Use these boundaries to explain who does what; arrows show dependencies between actions.
What goes into a service blueprint?
Keep the elements that help answer your question and support a decision.
The steps a person takes to reach the scenario’s goal.
The messages, objects and channels someone encounters. Here, evidence means service artefacts; keep research sources separately so the two meanings are clear.
Interactions visible to the customer.
Work supporting those interactions outside the customer’s view.
Systems and activities that enable delivery.
What each step requires, from whom, and what happens if it is missing.
02 / PUT IT INTO PRACTICE
How to create a service blueprint
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Bound the journey
Choose one scenario, start and end.
Map booking a repair through receiving a confirmed appointment.
02
Place customer actions
Use a researched sequence as the horizontal spine.
Request, select a slot, receive confirmation and prepare for the visit.
03
Add visible delivery
Describe what the service presents or does at each step.
Show available slots and send a booking acknowledgement.
04
Add hidden work
Record the work and supporting systems behind each interaction.
A scheduler verifies contractor capacity before assigning the visit.
05
Connect dependencies
Connect the lanes with dependencies: who supplies what to whom, what enables the next action and what happens when an input is missing. Check these connections with the people doing the work.
An acknowledgement must not imply that capacity is already confirmed.
06
Choose a change
Verify the suspected failure and give the next action an owner.
Compare pending and confirmed states with staff and tenants.
Example: confirming a repair appointment
Illustrative scenario, not research findings. A tenant selects a repair slot and receives a message that looks like a confirmation. The hypothetical backstage process still requires a contractor to accept the job. When that does not happen, staff must call the tenant to rearrange.
The blueprint separates the visible message from the acceptance step. The team proposes a clear pending state followed by a confirmation once capacity is committed. Before choosing it, they check whether the acceptance delay can be shortened and whether a pending slot would leave tenants unable to plan. The diagram exposes a design question; it does not prove the cause of missed appointments.
03 / BELOW THE SURFACE
Below the surface: improving one step can move the problem
Trace where uncertainty goes. A pending message is more accurate, but it can transfer the burden of uncertainty to the tenant. A faster acknowledgement may improve an internal response measure without making an appointment more dependable.
01 / EVIDENCE
What is supported?
Which source or observation supports the current interpretation?
02 / LIMIT
What remains uncertain?
Which assumption would change the decision if it were wrong?
03 / ACTION
What happens next?
Who will investigate or test the next step, and when?
Compare options across the whole scenario: what can the tenant rely on, what must staff resolve, and when does a commitment become real? Record who bears the delay in each option. This is an editorial test of the proposed change, not a universal service metric. Test the message and the operating arrangement together before treating the blueprint as a solution.
Service Blueprint template
Use the first page for the practical work and the second to challenge the reasoning before choosing a next step. The canvas follows this guide and keeps evidence, assumptions and decisions visible.
The two page PDF contains 35 editable fields. Open it in a PDF reader that supports forms and save a working copy.
Practical tips
Use verbs for actions and label the owner of a handoff.
Keep current and proposed processes separate.
Show an exception path when it changes the customer outcome.
Common mistakes
Filling backstage rows from the design team’s assumptions.
Making every column appear equally certain.
Optimising one team’s response time while increasing customer uncertainty.
What you’ll get
A delivery map with dependencies and a next action. Keep the supporting evidence and unresolved questions with the output. Assign an owner to the next action and revisit the result when the underlying situation changes. The method supports judgement; the completed canvas is not proof that the proposed choice will work.
Sources and references
Sarah Gibbons, Nielsen Norman Group. Service Blueprints: Definition. Reference for the delivery layers, separating lines and supporting service artefacts.
This guide is an original practical synthesis. The repair appointment example and the discussion of who bears uncertainty are Design Iceberg editorial examples, not research findings reported by the source.