Service Blueprinting
Service Blueprinting
Connect the user journey to frontstage interactions, backstage work and supporting processes.
What Is a Blueprint?
A service blueprint connects the user’s experience to the people, processes and systems needed to deliver it. Building on the future-state journey from Module 7, examine what happens in front of the user and behind the scenes.
This approach applies to public-facing services and services between government agencies.
Learning outcomes
- Distinguish a service blueprint from a user journey map.
- Identify user actions, frontstage interactions, backstage activities and support processes.
- Explain the lines of interaction, visibility and internal interaction.
- Identify handovers, dependencies and delivery risks.
- Create a blueprint for a selected scenario.
| Tool | Main focus | Example question |
|---|---|---|
| User journey map | User actions and experience | Why is the requesting officer uncertain about progress? |
| Service blueprint | How the service delivers that experience | Which team updates the status, using what information? |
The blueprint adds delivery detail: what users see, what happens backstage, which processes support delivery and where information and responsibility move between teams.
Essential Terms
Select a card to reveal a definition.
Blueprint Layers
Arrange journey stages across columns and delivery layers across rows. Expand each layer below.
Frontstage can involve people or technology. The distinction between backstage work and support processes depends on the service scope; agree the meaning of each row before mapping.
The Blueprint Lines
Three lines separate different kinds of activity.
| Line | What it separates | Why it matters |
|---|---|---|
| Line of interaction | User actions and frontstage interactions | Shows where the user interacts with the service |
| Line of visibility | Frontstage interactions and backstage activities | Shows what the user can and cannot see |
| Line of internal interaction | Backstage activities and support processes | Shows reliance on internal support |
An officer may be reviewing a request while the portal still says “Submitted”. Identify how that review should trigger a meaningful user-facing update.
Connect Actions and Handovers
For each user action, connect the service response to the work needed to produce it.
| Layer | Example: submit a data request |
|---|---|
| Service evidence | Submitted form, reference number and confirmation |
| User action | Upload request and documents |
| Frontstage interaction | Confirm receipt and explain the next step |
| Backstage activity | Record request, check completeness and assign owner |
| Support process | Maintain portal, permissions and records |
Connect the work
- What triggers the next activity?
- Who is responsible?
- What information is required and where is it recorded?
- What happens if the step cannot be completed?
- What does the user see?
Map significant handovers
Handovers include portal routing, referrals for approval, inter-agency verification, enquiry escalation and transfer to the output preparation team.
| Handover detail | Guiding question |
|---|---|
| Sender and receiver | Who passes the work and who accepts it? |
| Information | What must be transferred? |
| Acceptance condition | How does the receiver know it is ready? |
| Ownership | Who remains responsible while it waits? |
| Exception route | What happens if information is incomplete or no response arrives? |
| User update | What should the user be told? |
Prevent requests from becoming stuck between teams. Show meaningful connections rather than simply listing departments.
Risks and Validation
Investigate where delivery could break down. Label uncertain causes as assumptions and validate them with the teams doing the work.
Blueprint Explorer
Explore a proposed inter-agency blueprint, a public-facing example and a handover checklist. Validate proposed capabilities with delivery teams.
Practical Activity
60 minutes · Small groups · Use the future-state journey from Module 7.
- Set scope. Confirm user, goal, starting point and outcome.
- Add stages. Place journey stages across the top.
- Map layers. Add evidence, user actions, frontstage, backstage and support.
- Mark lines. Identify interaction, visibility and internal interaction.
- Connect work. Show key dependencies and handovers.
- Identify risks. Select three points where delivery could fail.
- Validate assumptions. Identify staff or teams who can confirm missing information.
| Worksheet row | Record for each stage |
|---|---|
| Service evidence | Items the user encounters |
| User actions | What the user does |
| Frontstage interactions | Visible staff actions and system responses |
| Backstage activities | Direct delivery work hidden from the user |
| Support processes | Internal services enabling delivery |
| Ownership and handovers | Responsible role, transferred information and acceptance conditions |
| Risks and evidence gaps | Failures, assumptions and teams to consult |
Group presentation
Present the scenario and outcome; one connection between experience and backstage work; two significant handovers; three delivery risks; and one dependency needing validation.
Connect the user journey to delivery work. Make responsibilities, dependencies and handovers visible across channels and organisational boundaries.
A list of departments does not explain service delivery. Show how work is triggered, transferred and reflected in the user’s experience.
Knowledge Check
Select one answer per question to see feedback.