Use a service blueprint to locate failure points: Mark the exact moment: no acknowledgement, wrong update date, or invoice not received.; Trace four layers: visible action, backstage action, dependency, and return path.; A workshop vote or repeated suspicion cannot confirm a cause; evidence is required.
Image: Customer Experience Desk

Service Blueprints

Part of Service blueprinting

Using a service blueprint to locate failure points

Mark a customer-visible problem, trace the work beneath it and verify where a service failure may occur.

Desk Journeys · · 3 min read

To locate a possible failure point, mark a specific customer problem where it becomes visible on a service blueprint, then trace the actions and dependencies beneath it. The map shows where to investigate.

A blank or disputed step remains a question until a case, observation or suitable record clarifies what happened.

Mark the symptom precisely

Choose a defined task and problem, such as a customer who requested an invoice correction but received no usable answer. Record what the customer encountered, when it happened and the intended outcome. This is a hypothetical example.

Avoid labelling the whole journey “poor communication”. Place the symptom beside the relevant moment: no acknowledgement after submission, an update with the wrong date, or a revised invoice that never arrived. These may have different causes.

Trace down and across the map

From the marked moment, ask:

  1. Visible action:What response was the service meant to give, and what did the customer receive?
  2. Backstage action:Which hidden activity was meant to produce or trigger that response?
  3. Dependency:What information, decision or earlier step did that activity require?
  4. Return path:Who was meant to bring the result back to the customer, and how would completion be checked?

Follow the relevant connections in both directions. A missing acknowledgement could reflect a failed submission, an unmonitored queue or a message sent but not received. These are competing explanations, not findings. The blueprint cannot choose among them without evidence.

Keep an investigation record:

Field / Entry to make

Customer consequence
What the person could not do or know.
Possible failure point
The action or connection to inspect.
Supporting evidence
A relevant customer account, observation or authorised record.
Alternative explanation
Another cause still consistent with the evidence.
Next check
Evidence needed to distinguish the explanations.

Trace a failure point down and across the blueprint

  1. Visible actionWhat response was the service meant to give, and what did the customer receive?
  2. Backstage actionWhich hidden activity was meant to produce or trigger that response?
  3. DependencyWhat information, decision or earlier step did that activity require?
  4. Return pathWho was meant to bring the result back to the customer, and how would completion be checked?

Investigation record fields for a suspected failure point

  • Customer consequenceWhat the person could not do or know.
  • Possible failure pointThe action or connection to inspect.
  • Supporting evidenceA relevant customer account, observation or authorised record.
  • Alternative explanationAnother cause still consistent with the evidence.
  • Next checkEvidence needed to distinguish the explanations.

Check gaps and uncertain outcomes

Look for a step with no owner, an output that does not reach the next team, or a loop that sends work back without a decision. Check whether the map omits an exception route.

An empty cell may mean the action is missing from the service, missing from the diagram or unknown to the people who drew it.

Compare the intended route with a relevant case, subject to authorised access. Speak with people on both sides of a suspected break and check what the customer experienced. Record conflicting evidence. A workshop vote or repeated suspicion cannot confirm a cause.

If evidence supports a cause, describe the proposed change and the customer outcome it should improve. Assign the team that controls the relevant step and check a comparable task after the change.

If evidence remains thin, keep the item open for investigation. A useful failure point leads to a checkable decision.

What an empty blueprint cell can mean

Missing from the service
The action may not exist in the service itself.
Missing from the diagram
The action exists but was left off the blueprint.
Unknown to the map-makers
The people who drew the diagram may not know about the action.

From suspected failure point to checkable decision

  1. Evidence supports a causeDescribe the proposed change and the customer outcome it should improve.
  2. Assign ownershipAssign the team that controls the relevant step.
  3. Check after changeCheck a comparable task after the change.
  4. Evidence remains thinKeep the item open for investigation rather than confirming a cause.

More from Service Blueprints