Service Blueprinting
When you need this method
Your delivery exists as a description in words, not as a picture. Sales, onboarding, support and engineering each know their own section, but nobody can show how the pieces connect. When a customer waits, or has to supply the same information twice, it stays unclear where in the sequence this arises and which function it depends on. The conversation then turns to people instead of to the process.
Approach
- 1Name the process or sub-process and decide which customer segment you are drawing for. The same sequence looks different for an enterprise account than for a self-serve tier.
- 2Lay out customer actions first and in chronological order. The guiding question is where the service starts and ends from the customer's point of view.
- 3Add visible employee actions above the line of visibility and connect them to the customer steps. Every crossing of the line of interaction is a moment of truth.
- 4Place invisible employee actions below the line of visibility, including preparation that never involves the customer.
- 5Place support processes below the internal line of interaction and tie them to the customer steps with vertical links. This exposes which function each customer step depends on.
- 6Write the physical evidence for each customer step into the top row, meaning everything tangible that shapes how the customer judges quality.
- 7Draw in a cross-functional team, ideally with customers present, and mark fail points, waiting times and duplicated work as you go.
- 8Derive an implementation plan per function from the finished drawing, and deepen heavily loaded sub-processes as their own sub-blueprints.
Typical application
A typical B2B SaaS in the HR space: implementation takes eleven weeks on average, four were promised, and every department considers its own part on time. In the blueprint the team draws sales, onboarding, data migration and support onto one sheet. Two places stand out. The customer supplies the same master data twice, once to sales and once to the migration team, because below the line of visibility no handover can be drawn at all. And the date for system access depends on an internal IT approval step that appears in the blueprint only after kickoff, while the customer expects it before. Neither is a question of staffing. Both are missing links between two rows.
Limits and counter-indications
A blueprint shows the intended standard path. Exceptions, service recovery after failure and the customer's emotional experience are not in it; a journey map belongs alongside it, and diverging cases need blueprints of their own. For services with very high divergence, such as consulting where every engagement runs differently, a single drawing forces a standardisation that does not exist. For pure self-serve software without human contact the line of visibility loses its meaning, because nearly everything sits behind it. Drawing on its own improves nothing: the results in the founding article are case reports from the participating firms without a control group, and the one quantitative study measures the perceived effectiveness of the technique, not its effect on customer metrics. Without a named owner a blueprint goes stale within months.
How to measure impact
For each marked fail point, measure the cycle time of the affected customer step and the number of queries sent back to the customer, before and after the change. Time to first measurable customer value serves as the counter-check.
Related methods
Tools for this
Sources
- 1.Bitner, Ostrom & Morgan: Service Blueprinting. A Practical Technique for Service Innovation, California Management Review 50(3), 2008, 66–94 (opens in a new tab) · California Management Review, University of California, Berkeley (Volltext über die Internationale Hochschule Griechenland) · 2008 · academic and scholarly literature · describes the methodFull text verified. Carries the technique in full: the five rows (physical evidence, customer actions, onstage employee actions, backstage employee actions, support processes), the three lines (interaction, visibility, internal interaction) and the drawing order in which customer actions come first and physical evidence last (Figure 1 and the section Building a Blueprint). Limit: the reported outcomes are case reports from the participating firms without a control group.
- 2.Shostack: Designing Services That Deliver, Harvard Business Review, Januar/Februar 1984, 133–139 (Reprint 84115) (opens in a new tab) · Harvard Business Review · 1984 · practitioner source · supports the underlying mechanismFull text verified. Origin of the technique and carrier of its mechanism: the line of visibility, the marking of fail points in the diagram, and the setting of a standard execution time alongside a still tolerable execution time. Argues why process design is a management responsibility rather than a matter of individual staff. Limits: the five rows and three lines of the current version are not yet present here, the author wrote as a bank executive, and the evidence consists of worked examples rather than a study.
- 3.Kostopoulos, Gounaris & Boukis: Service blueprinting effectiveness. Drivers of success, Managing Service Quality 22(6), 2012, 580–591 (opens in a new tab) · Emerald (Eintrag im Repositorium der University of Strathclyde) · 2012 · academic and scholarly literature · evidence of effectivenessAbstract and bibliographic details verified, no full text. Questionnaire-based field study across 102 hotels. Finding: blueprinting effectiveness rests on three organisational preconditions, namely market orientation, service climate and the formality of service design; process complexity and divergence strengthen these relationships. Limits: what is measured is the perceived effectiveness of the technique, not its effect on customer metrics, and the sample comes from one industry and one country context.
- 4.Kaplan: Service Blueprints. Definition, Nielsen Norman Group, 27. August 2017 (opens in a new tab) · Nielsen Norman Group · 2017-08-27 · practitioner source · provides the contextVerified. Carries the boundary on which this entry's limits rest: a blueprint belongs to exactly one customer journey, diverging cases require further blueprints, and it complements the journey map with the internal side rather than replacing it. Limit: a practitioner source with no measurement of its own, its benefit claims are experience-based.
Origin: Bitner / Ostrom / Morgan (nach Shostack)