A blueprint ties frontstage experience to backstage process
Aliases: service blueprint layers · line of visibility · line of interaction
What it is
The locker door opens. The customer does not see who changed stock after the cut-off, or who revoked the door permission after timeout. A service blueprint draws frontstage actions and backstage process on one timeline, split by a line of visibility: above it, encounters the customer can have; below it, internal steps and systems that make those encounters possible. It is not a second copy of the journey. It supplies what the backstage was doing at the moment a journey step happened.
Why it happens
When experience breaks in front, the cause has often already finished below the line: stock sync lag, permission not pushed, a ticket still on another shift. Frontstage-only pictures read the break as user error or bad UI. Wiring the backstage in shows the trigger. The visibility line forces the admission that some failures cannot be self-rescued from the screen, because the decision does not live on that screen. Time runs horizontally; layers run vertically (customer acts, onstage staff, backstage staff, systems). Alignment across a column is the claim: if an opening depends on a stock write-back, those two cells must sit one above the other.
Studying it
Pin a fully observed service event’s frontstage timeline, then collect internal steps and system logs for the same window from each group, and test alignment. Mark unalignable cells unknown; do not fill them with “there should be a step.” Compare journey-only with journey-plus-aligned-backstage on attribution of the same failure. Outcomes: share of backstage steps that can be aligned, and failures that cannot be explained from the frontstage alone.
Where it stops holding
A mostly self-serve digital product with almost no internal procedure yields a thin system layer; a state diagram of the interface may earn more. Where internal work is classified or safety-critical, below-the-line drawing stops at the allowed grain; completeness is not a license to probe. A blueprint is also not an org chart: people in one cell may report to different departments. What is connected is activity, not reporting lines.
Applying it
- Pin the frontstage timeline first. Each executing team fills what it was doing at that moment; the experience group does not ghost-write the backstage.
- Align at least one supporting activity or system event under every consequential frontstage act. If it will not align, mark unknown; do not invent.
- Use the visibility line as a test: does the step the customer complains about have its decision below the line? If yes, shipping UI will not save it; change process or system.
- Acceptance: take a fresh field event and ask the blueprint which backstage cell should have been live. If it cannot say, the sheet is still a frontstage journey.