Service Blueprints
Part of Service blueprinting
Mapping the backstage work behind a customer experience
Trace hidden service actions from a customer moment through their inputs, handoffs and customer-facing outcome.
Start with a customer action or visible service response, then trace what happens out of sight to deliver it. Record the sequence, inputs and outputs. A job title beside a journey stage does not explain the work behind it.
Pick a moment with an observable outcome
Choose a bounded task, such as sending a customer a revised invoice. Work backwards from what the customer receives: what produced the document, who checked the change and what information did each step require? This is a hypothetical example; the real sequence depends on the service.
Keep the customer moment at the top of the map. Add the visible action, such as an agent acknowledging the request, then place hidden actions below the line of visibility.
A front-line employee may also perform backstage work, such as entering details into a case system after a call. Classify the action by whether the customer sees it, rather than by the employee’s job title.
Mapping Backstage Work Behind a Customer Experience
- Customer-facing momentRevised invoice sent to customer
- Visible actionAgent acknowledges request
- Backstage step 1Check charge recorded on account
- Backstage step 2Verify invoice reference and customer query
- Backstage step 3Approve correction or provide explanation
- Backstage step 4Update document system with revised invoice
- Final outcomeCorrect document delivered to customer
Trace each hidden step to its output
For each backstage action, ask the person who performs it:
- What starts your work, and how do you learn about it?
- What information, permission or decision do you need first?
- What do you check or change, and what record or tool do you use, if any?
- What do you pass on, to whom, and how do they know it is ready?
- What happens when an input is missing or the usual route fails?
Show an enabling process or resource where it matters, such as an approval step, case queue or document system. Label the activity and the resource separately.
Show a dependency where one activity needs an output from another. Mark an exception step with its condition rather than drawing it as part of every case.
| Map entry | Hypothetical invoice example | What to verify |
|---|---|---|
| Backstage action | Check the charge recorded on the account | Which record is used and who can access it? |
| Input | Customer’s query and invoice reference | Does the receiving team get both? |
| Output | A decision to correct or explain the charge | Where is that decision recorded or passed on? |
| Customer-facing result | Revised invoice or explanation | Does it reach the customer and answer the query? |
These entries are prompts for investigation, not findings from an invoice service.
Frontstage vs Backstage Actions in Service Delivery
- Frontstage (visible)
- Agent acknowledges customer request
- Backstage (hidden)
- Check account records for billing error
- Frontstage (visible)
- Email sent with revised invoice
- Backstage (hidden)
- Update case system with approval decision
Key Steps in Tracing Backstage Work
- Identify the observable customer momente.g., sending a revised invoice
- Work backwards from the outputTrace inputs, decisions, and systems used
- Ask staff about triggers and dependenciesWhat starts the work? What’s needed first?
- Map handoffs and tools usedRecord who receives what and how they know it’s ready
- Note exceptions and gapsMark unknowns like ‘approval not confirmed’
Check the sequence against cases
Use a relevant case, suitable records and conversations with the staff involved, subject to authorised access. Ask someone to walk through an ordinary case and an exception.
Compare the described procedure with what happened. A formal process may say a queue receives a complete request while staff routinely have to seek missing details elsewhere.
Label gaps honestly. If the team cannot tell when an approval reaches the document system, write “unknown” and assign a check. Software capability alone does not verify that a step happens in the service.
The mapped sequence should connect the customer moment to the hidden actions and back to the customer-facing result. If it ends at “finance completed task”, continue far enough to learn whether the correct document was delivered.
Key Elements of a Service Blueprint
- Customer-facing actions
- Visible steps like email delivery or call acknowledgement
- Backstage actions
- Hidden tasks such as system updates or approvals
- Support processes
- Systems like case queues or document management
- Dependencies
- One step requiring output from another
- Exception handling
- Conditions where normal flow fails
