A service blueprint connects the customer’s journey to the people, systems, and backstage work needed to deliver it. Build one around a specific service outcome, then trace each handoff across the same stages. The useful result is a clear owner and repair for a failure the customer experiences, not simply a list of departments.
Choose the journey and the promise
A bike workshop lets customers request a repair appointment online. A mechanic must check the repair type and bay availability before confirming. The customer’s goal is to know when to bring the bike and what has actually been agreed. The workshop’s goal is to avoid unconfirmed arrivals and requests lost between the website and the service desk.
Limit this blueprint to requesting and confirming an appointment. Repair diagnosis, parts ordering, payment, and bike collection belong to later journeys. Name the starting condition, end state, and exception: a customer submits a request; the workshop confirms or proposes another time; a failed notification must not leave either side believing the other has been informed.
Read the lanes as relationships, not separate lists
NN/g’s service-blueprint example maps a retailer’s customer journey to visible and invisible service work. The important distinction is visibility: a customer sees a message, but may not see the inventory check or staff decision that makes the message true. Put those actions in aligned columns so a missing connection is visible.
For this example, use five lanes: customer actions, frontstage interactions, backstage actions, support processes, and evidence. The visibility boundary separates customer-facing interactions from backstage work. A customer action connects to a frontstage response across the interaction boundary; backstage work depends on support processes across the internal-interaction boundary.
| Lane | Request | Staff review | Confirmation | Notification failure |
|---|---|---|---|---|
| Customer action | Choose repair type and preferred time; submit | Wait for an update; check request status | Read confirmed time or accept an alternative | Check status or contact the desk |
| Frontstage | Request received; not confirmed; display reference | Status page says Under review | Display the agreed time and what to bring | Status page remains available; desk supplies the same current status |
| Backstage | Desk queue receives request with repair type and time | Mechanic checks scope and bay; desk owns response | Desk records confirmed time or proposed alternative | Desk checks failed delivery and follows the contact procedure |
| Support process | Persist request and enqueue staff task | Calendar/bay data and service-duration rules | Persist decision, then enqueue notification | Delivery-status reporting and staff exception queue |
| Evidence | Reference BIK-104 and request details | Timestamped request status | Confirmation or offer with exact date/time | Recorded delivery failure and resolution note |
Find the break in the original service
Consider this original handoff: the website says You are booked immediately after a request is saved. Staff receive an email, but nobody owns a queue of unanswered requests. If that email fails, the customer may arrive while the mechanic has never agreed to the slot. A prettier confirmation screen cannot fix the mismatch.
The blueprint exposes two separate defects. The visible promise gets ahead of the backstage decision, and the backstage handoff relies on a notification with no durable work queue. Fixing only the wording leaves requests at risk of being missed; adding a queue while retaining You are booked leaves the customer misinformed.
| Part | Before | Proposed repair |
|---|---|---|
| Immediate response | You are booked | Request received — your appointment is not confirmed yet |
| Staff work | An email is the only record the desk acts on | A persisted request appears in an owned review queue; email is a notice |
| Ownership | Anyone at the desk may respond | Assigned desk role checks outstanding requests and escalates unanswered ones |
| Confirmation | Submission is treated as acceptance | Only a recorded staff decision produces confirmation |
| Delivery failure | No visible follow-up | Status page retains the result; failed delivery creates a staff task |
Specify owners, triggers, and recovery
Assign an owner to each handoff. For this worked service, the desk reviews requests during opening hours and checks the outstanding queue at the start and end of each shift. The service must publish its actual response expectation; do not invent a one-hour promise if staffing cannot support it.
The mechanic supplies availability and scope decisions, while the desk owns communication. If a different time is offered, it remains an offer until the customer accepts and the workshop records the final slot. For this example the offer expires at the end of the next opening day; display that deadline and require a fresh availability check after expiry.
| Trigger | Owner | Required output | Failure / escalation |
|---|---|---|---|
| Request saved | Service desk | Visible task with reference, contact route, repair type and preferred time | Missing task is a system incident; reconcile saved requests with the queue |
| Availability checked | Mechanic to desk | Accept requested slot or propose a named alternative | Unclear repair scope returns to desk for clarification |
| Decision recorded | Desk and notification service | Status page reflects decision; notification job created | Failed delivery becomes a desk task; do not mark customer informed merely because a job exists |
| Alternative accepted before expiry | Desk | Recheck availability and record final confirmed time | If no longer available, explain and offer another option |
| Outstanding request at shift end | Desk lead | Named next owner and follow-up action | Escalate missing decisions rather than silently leaving the queue |
Test the service with a tabletop walkthrough
Bring the desk role, mechanic role, and someone representing the system together. Use one request reference and move it through the blueprint. Each person must show the input they received and the output the next role can actually use. A verbal We would handle it is not a completed handoff.
Walk through normal confirmation, an unavailable preferred time, a failed outbound message, and a duplicate customer submission. The system needs a way to recognize or reconcile duplicates; the blueprint should record the required behavior without pretending to specify the entire technical implementation.
| Scenario | What must be observable |
|---|---|
| Request saved; staff have not reviewed | Customer sees pending status; desk sees the same reference in the queue |
| Mechanic accepts the slot | Recorded confirmation and customer-facing status show the same time |
| Preferred time unavailable | Customer sees an offer rather than a false confirmation; expiry is explicit |
| Notification fails | The decision remains on the status page; a named desk owner sees a delivery task |
| Customer retries submission | Staff can identify the related attempts; no silent double booking |
| Shift changes with unresolved requests | Ownership and next action remain visible to the next shift |
Copy the blueprint and use it to assign work
For another service, copy the columns Stage 1, Stage 2, Stage 3, Exception; then add the rows Customer action, Frontstage interaction, Backstage action, Support process, Evidence. Fill one complete vertical slice first. Draw the visibility boundary and connect every promise to the action and record that make it true.
Add a repair record beneath the map: failure; affected customer task; broken handoff; accountable role; proposed process or interface change; acceptance check; evidence from the walkthrough. Keep observation and proposed future behavior separate so collaborators know what already exists.
The output of this example is a specific version-one scope: request receipt, a staff queue, explicit review status, a recorded decision, a status page, and delivery-failure follow-up. That is more useful than a diagram ending with Improve communication. Revisit the blueprint after the real service runs and compare failure records with the predicted weak points.