Service Blueprints
Part of Service blueprinting
Identifying dependencies between front-line and back-office teams
Use a service blueprint to trace what front-line staff need from back-office teams, how work returns and who updates the customer.
A front-line team depends on back-office work when its answer or next action relies on information, a decision or an output from another team. Trace what must pass between them, who is responsible for the return path and what the customer ultimately receives.
Start with the customer-facing need
Pick a single customer request. Record what the front-line team told the customer would happen — or what answer the customer still needs if no commitment was made.
In a hypothetical invoice query, an agent might promise an update after a charge is reviewed. The actual arrangement depends on the service.
Mark the visible interaction on the blueprint. Beneath it, list what the agent needs to answer accurately or complete the action: perhaps an account record, authority to amend a charge, a specialist decision or a way to issue a revised invoice. Separate an essential input from a preferred format for receiving it.
Name both sides of each handoff
For every transfer, record the sender, receiver, trigger, required input, expected output and owner of the next customer update. A compact register can sit beside the blueprint:
| Question | What to capture |
|---|---|
| What starts the request? | The event and reference connecting it to the customer task. |
| What must move? | The required information or decision, with its source and status. |
| What counts as complete? | The output needed by the next team and where it can be found. |
| Who tells the customer? | The team responsible for the next accurate update. |
| What if it stalls? | The route for missing input, disagreement or an overdue response. |
Link each required input to the activity it enables, then trace the output towards the customer-facing response. If several teams contribute, show their sequence and conditions rather than one box labelled “back office”. An internal approval may be necessary without being the final answer the customer needs.
Tracing Dependencies Between Front-Line and Back-Office Teams
- TriggerCustomer request (e.g., invoice query)
- Required InputAccount record, authority to amend charge, specialist decision
- Expected OutputRevised invoice or approved charge adjustment
- Owner of Next Customer UpdateFront-line agent
- Exception PathMissing reference or unresolved authority dispute
Check the dependency with cases
Ask each team what it expects to receive and what it actually receives. Compare their accounts with a relevant case and suitable records where access is authorised. Include an exception where possible: a handoff that works for standard cases may change when a reference is missing or another authority must decide.
Check what each team means by “done”. A specialist may finish when an adjustment is approved; the agent may still need a corrected document before answering the customer. Record those milestones separately. Do not infer a customer delay solely from an internal step that looks slow; check the timeline and what the customer was told.
When a dependency appears to fail, identify what needs investigation: the input, routing, decision authority, output, update ownership or exception path. Assign the next check and define the customer outcome to examine afterwards. The blueprint shows the relationship; case evidence is needed to establish whether it caused a particular failure.
