Workshop Exercises: Understand
Service Blueprint
Connect customer experiences to the work that delivers them
How: Map one customer scenario across visible service, backstage actions and support processes, then investigate an important handoff.
Why: Expose dependencies and uncertain handoffs so teams can choose what to investigate or improve
When: Use when a customer experience crosses teams or systems and you need a shared account of how the service is delivered
A service blueprint connects a customer’s steps with the visible service, hidden work and supporting processes needed to deliver an experience. Use it when a problem or proposed change crosses people, teams or systems.
Service blueprint layers and boundary lines
Read a blueprint left to right through one scenario, then vertically to inspect what supports each stage. The structure below follows Nielsen Norman Group’s explanation.
| Layer | What belongs here |
|---|---|
| Physical or digital evidence | Things encountered in the service, such as a booking page or ready message; this is not the same as research evidence |
| Customer actions | What the customer does to achieve their goal |
| Frontstage | Service actions the customer can see, including staff conversations and self-service responses |
| Backstage | Work supporting the experience outside the customer’s view |
| Support processes | Internal activities and systems enabling service delivery |
The line of interaction separates customer actions from direct service interactions. The line of visibility separates visible service from hidden work. The line of internal interaction distinguishes contact-related work from the supporting activity behind it. These are boundaries between kinds of activity, not extra process steps or department names.
G. Lynn Shostack described service blueprinting in Designing Services That Deliver. This workshop adapts the method for a focused team session.
A worked service blueprint example
This bicycle-repair scenario is invented for illustration. A customer books a repair, leaves the bike at the shop and later collects it. The drawing condenses the booking and collection stages; it omits drop-off and the repair itself.
Read down the collection column: the customer needs to know when to return, a staff member hands over the bike, a mechanic marks the repair ready, and a notification process sends an alert. The ready message is visible evidence of the service; the notification process runs out of sight. Those activities may happen at different times and depend on one another, so add explicit arrows and timing when mapping the full flow.
Now imagine the customer calls to ask whether the bike is ready even though the mechanic has finished. The team suspects a failed alert. That is a hypothesis, not a conclusion from the drawing.
Check the status-change time, alert log and delivery outcome, then ask the customer what they received. A queued alert, a failed delivery and an unread message imply different next actions. Assign the check to an owner before proposing a new notification feature. A blueprint locates dependencies; root cause analysis investigates explanations.
Service blueprint vs journey map vs process map
A customer journey map emphasizes the customer’s experience over time. A process map traces actions and decisions in a workflow. A blueprint adds the relationship between the customer-facing experience and the work supporting it. Use the existing Journey Mapping exercise when you first need to understand the customer path.
Choose a narrow scope, include delivery staff and retain exceptions. A polished map does not establish that every customer takes the same path or that a proposed service will work. Keep evidence references and uncertainties alongside the diagram, then revise it after research or a service change.
Instructions for running this play
- Choose one scenario. Spend 10 minutes agreeing on the customer, goal, start and end of the experience, and the decision this map should inform. Label it current state or proposed future state; keep materially different scenarios on separate maps.
- Review the evidence. Use 10 minutes to review customer research, service records and accounts from the people delivering the service. Assign source IDs and mark missing information; research collection happens before this 90-minute session.
- Map customer actions. Spend 15 minutes arranging the customer’s steps from left to right, drawing on an existing Journey Mapping output where relevant. Add the physical or digital evidence encountered at each stage, such as a booking page, message or receipt.
- Add visible service. Run 10 minutes of Silent Storming to add frontstage actions beneath the customer steps, then use 5 minutes to compare notes. Include both staff interactions and self-service responses; mark the line of interaction between customer and service actions.
- Connect hidden work. Use 20 minutes to add backstage actions below the line of visibility and support processes below the line of internal interaction. Draw arrows for dependencies, label important handoffs and waiting points, and identify who or what performs each action.
- Walk through a case. Use 10 minutes of Playback to trace one actual case through the current-state map, or a clearly hypothetical case through a proposed map. Check the exception path as well as the intended path; keep disputed steps as questions.
- Assign one next action. Spend 10 minutes choosing an important gap or handoff and the evidence needed to assess it. Record an owner and date using a Who / What / When Matrix; agree how the map will be updated after the check.
Tips to perfect this play
Master and adapt the play to fit your context and needs.
Tip: Include delivery roles
Invite people who do the work, including customer-facing staff and support teams. A manager's intended process may differ from the process people follow.
Tip: Keep states separate
Label the current state and proposed future state separately. A desirable handoff is not evidence that the handoff already works.
Tip: Make uncertainty visible
Attach source IDs to notes and mark gaps explicitly. Verify an apparent failure with relevant records or observation before assigning a cause.
Tip: Share a readable version
For remote sessions, use a shared board or spreadsheet. Afterward, record the scenario, date, owner and legend so someone outside the workshop can read the map.
Trigger Questions
- How is a blueprint different from a journey map? A journey map follows the customer's experience; a blueprint connects that experience to the visible and hidden work delivering it.
- Is frontstage the same as a front-end team? No. Frontstage means visible to the customer, including staff interactions and self-service technology; classify actions by visibility, not department name.
- Can we blueprint a service that does not exist yet? Yes. Label it as a proposed future state, mark its assumptions and test important dependencies before treating it as a working service.
Use Discovery Patterns to choose ways to understand customers and uncover gaps in the service experience.
$129 · Printed deck + digital edition
Explore Discovery Patterns- Designing Services That Deliver by G. Lynn Shostack
- Service Blueprints: Definition by Sarah Gibbons
- A Guide to Service-Blueprinting Workshops by Alita Kendrick