Customer & product
Service Blueprint
A process map of a single service that lines up the customer's actions with everything the organisation does to deliver them, above and below the line of visibility, so that failure points, waits and disconnects between frontstage and backstage can be seen and fixed.
Also known as Service blueprinting, Service map. First set out by G. Lynn Shostack in 1984; the primary source is cited in full below.
- Format
- Mapping
- Level
- Product · Team
- Best for
- Understand customers · Plan execution
- Decision stage
- Diagnose · Plan
- Difficulty
- Intermediate
- Time to apply
- Half a day for a workshop first pass; one to two weeks with observation and data.
Plate · The model
The components
Physical evidence
The tangibles the customer encounters at each step: premises, signage, messages, documents, the appearance of staff and equipment. Customers read these as proxies for quality they cannot see, so evidence deserves deliberate design rather than accident.
Signals of strength
Every customer action has its evidence identified · Evidence is consistent across channels and branches · Moments of highest anxiety have the strongest reassurance · Someone owns each piece of evidence
Customer actions
The steps the customer takes in the service: choosing, booking, arriving, waiting, handing over, paying, collecting. This row is the spine of the blueprint and the standard against which every other row is judged.
Signals of strength
Drawn from observed behaviour, not the process manual · Includes the waits and workarounds customers actually perform · Specific to a named scenario and segment · Effort demanded of the customer is visible and questioned
Frontstage staff actions
What contact employees do in view of the customer, in person or on the phone: the greetings, explanations, handovers and recoveries that constitute the visible service.
Signals of strength
Each customer action meets a defined frontstage response · Service recovery steps exist for known failure points · Frontstage staff are not performing hidden admin mid-encounter · Scripts and standards match what the evidence row promises
Backstage staff actions
Work done by employees out of the customer's sight that directly enables the visible steps: preparing, checking, pricing, scheduling. Invisible to customers, and often the true source of the delays they experience.
Signals of strength
Every frontstage promise traces to a backstage action that fulfils it · Handovers between backstage roles are explicit · Queues and batching backstage are visible on the map · Backstage load is matched to frontstage demand patterns
Support processes
The systems, infrastructure and internal services beneath the line of internal interaction: IT platforms, third-party feeds, procurement, payroll of the operation itself. Steps in the rows above stand or fall on these.
Signals of strength
Each critical step names the systems it depends on · Third-party dependencies are marked as such · Known system weaknesses are mapped to the customer pain they cause · Support owners have seen the blueprint and accepted their row
When it earns its keep
- You are designing a new service and want to engineer the delivery system before the first customer meets it, rather than debugging it live.
- Customers keep hitting the same failure and the cause is invisible to them, and possibly to you, because it sits backstage or in a support system.
- Several departments each own a fragment of one customer experience and nobody holds the whole picture, so handovers are where the service breaks.
- You are about to automate or digitise part of a service and need to know exactly which human actions the technology is replacing and what depends on them.
And when it doesn't
- You only need the customer's perception of the experience. A customer journey map is lighter and does that job; the blueprint's extra rows earn their keep only when you intend to change the operation.
- The process has no customer in it, such as a back-office month-end close. Value stream mapping or a SIPOC serves better where there is no line of visibility to draw.
- The service problem is capability or culture rather than process. A blueprint will show you where staff struggle; it will not tell you why they are undertrained or demoralised.
- You cannot get frontline and back-office staff into the exercise. A blueprint drawn solely at head office documents the service as imagined, which is usually the problem being investigated.
How to run it
Before starting, gather the inputs the analysis depends on:
- A defined service, scenario and customer segment, because 'the customer' does different things in a breakdown visit and a routine booking.
- Evidence of what customers actually do, from observation, journey research or complaint data, rather than the process manual's assumption.
- Frontline staff and back-office staff in the room, since they hold the real process including the workarounds.
- Knowledge of the supporting systems and third parties each step depends on.
- An agreed level of granularity, so the map stays readable and comparable across branches or channels.
- 1
Choose the service and the scenario
Blueprint one service for one segment in one concrete scenario. A blueprint of 'our customer experience' in general is a mural; a blueprint of 'an MOT with unexpected repair work, booked online' is a diagnostic instrument.
- 2
Map the customer's actions first
Lay out the steps the customer takes from start to finish. This row anchors everything: Bitner, Ostrom and Morgan are insistent that the blueprint is built outward from the customer's experience, and every other row exists only to support this one.
- 3
Add the frontstage and the physical evidence
Above the line of visibility, record the staff actions the customer sees and the tangibles they encounter at each step: the premises, the confirmation text, the paperwork, the state of the waiting room. Evidence is what customers use to judge quality they cannot observe directly, so gaps in this row are quietly expensive.
- 4
Map the backstage and the support processes
Below the line of visibility, record what contact staff do out of sight and, beneath the line of internal interaction, the systems and internal services the whole thing rests on. This is where most failures originate and where most improvement budgets should be aimed.
- 5
Draw the lines and inspect the map
The modern formulation uses three horizontal lines: the line of interaction between customer and organisation, the line of visibility between frontstage and backstage, and the line of internal interaction between contact activities and support processes. Read down each column for steps where the rows disagree, and along each row for overloads, waits and single points of failure.
- 6
Act on what the map shows
Mark failure points and wait points, decide which to fix, and assign owners across the departmental boundaries the map has just made visible. A blueprint that ends as a poster has documented the service; the point was to change it.
Reading the result
A single shared picture of one service: the customer's path, the visible and invisible work that delivers it, the three lines that structure responsibility, and a marked set of failure points, wait points and disconnects with owners assigned.
- Read down each column: at any customer step, the rows below should form an unbroken chain of support. A promise in the evidence row with nothing beneath it is a failure waiting for volume.
- The line of visibility is the diagnostic frontier. Customer pain that appears above the line is very often caused below it, and fixes aimed only at the frontstage treat symptoms.
- Long horizontal gaps in the customer row are waits. Ask what is happening backstage during each one, and whether the customer can at least see progress.
A worked example
A vehicle MOT and servicing chain blueprints the MOT-with-repairs visit
A chain of fourteen MOT and servicing centres in the north of England has rising complaints clustered on one journey: an MOT that uncovers repair work. Customers report afternoons of silence, surprise charges and disputed authorisations. Branch managers blame customers' phones; head office suspects the process. The operations director blueprints the journey for a customer who books online and waits locally.
- Physical evidence
- Booking confirmation text, branch signage, the waiting area, the quote, the DVSA pass certificate. The map exposes a hole: the mid-visit authorisation for extra work is a phone call with no written trace, so the customer's only evidence of what they agreed to is memory. Most billing disputes trace to this missing artefact.
- Customer actions
- Book online, drop off keys, wait or leave, take a call authorising repairs, return, pay, collect. Observation shows a step the manual omits: customers ring the branch mid-afternoon to chase progress, and that inbound chasing consumes the service adviser's time precisely when quotes need preparing.
- Frontstage staff actions
- The adviser greets, takes keys, sets expectations, makes the authorisation call, takes payment, explains the certificate. The expectation-setting step is improvised per adviser: some promise a call by noon that the backstage cannot reliably deliver, which manufactures the afternoon of silence customers complain about.
- Backstage staff actions
- The tester conducts the MOT and logs the result on the DVSA system, a technician specifies the repair, the adviser prices parts and prepares the quote. The blueprint shows completed test results waiting up to three hours before the authorisation call, because quote preparation is batched after lunch. The customer's longest wait is a backstage queue, invisible from the front desk.
- Support processes
- The DVSA MOT testing service, the booking platform, the parts supplier's stock feed and the payment system. The stock feed shows items in stock at the regional hub that are not in the branch, so advisers promise same-day repairs that slip to next day. A support-layer data fault surfaces two rows up as a broken frontstage promise.
The read. The complaints are generated below the line of visibility: a batching queue in quote preparation and a misleading stock feed, compounded above the line by an evidence gap at authorisation. The fixes assigned were a photo-and-price message the customer approves in writing, quote preparation moved to a rolling basis, and a stock-feed correction owned by IT. None of these would have emerged from the customer journey map alone, which is the point of the blueprint: the journey shows where it hurts, the blueprint shows what to operate on.
Pitfalls
- Blueprinting the service as designed rather than as performed. The manual's version is the hypothesis; observation and frontline testimony are the data.
- Going too granular on the first pass, producing a wall-sized artefact nobody can read. Map at one level, then zoom into the failure points that matter.
- Skipping the physical evidence row because it feels trivial. Evidence is how customers judge invisible quality, and its absence at anxious moments is a design fault.
- Drawing the blueprint without back-office and support staff, which guarantees the bottom two rows are fiction.
- Filing the finished blueprint as documentation. It is a working drawing; if no failure point gets an owner and a fix, the exercise changed nothing.
What the critics say
Blueprinting lacks formal rigour as a process notation. Comparisons with BPMN find blueprints have no defined semantics for branching, exceptions or concurrency, so complex services with many variant paths are represented ambiguously, and different teams can draw materially different blueprints of the same service.
Milton, S. K. and Johnson, L. W. (2012) 'Service blueprinting and BPMN: a comparison', Managing Service Quality, 22(6), pp. 606-621.
The technique frames one service in one organisation, which understates the multi-service, multi-channel systems customers actually traverse. Multilevel service design was proposed precisely because blueprinting operates at the service-encounter level and needs complementary methods for the value constellation above it.
Patrício, L., Fisk, R. P., Falcão e Cunha, J. and Constantine, L. (2011) 'Multilevel Service Design: From Customer Value Constellation to Service Experience Blueprinting', Journal of Service Research, 14(2), pp. 180-200.
The blueprint is operationally biased: it captures actions, dependencies and timing well, and emotion, meaning and relationship poorly. A service can pass blueprint inspection at every step and still feel cold, which is why journey mapping and experience research remain necessary companions rather than rivals.
Sources and further reading
- Shostack, G. L. (1984) 'Designing Services That Deliver', Harvard Business Review, 62(1), January-February 1984, pp. 133-139. ↗
- Shostack, G. L. (1982) 'How to Design a Service', European Journal of Marketing, 16(1), pp. 49-63.
- Bitner, M. J., Ostrom, A. L. and Morgan, F. N. (2008) 'Service Blueprinting: A Practical Technique for Service Innovation', California Management Review, 50(3), pp. 66-94. ↗