--- name: service_blueprint description: "Build a service blueprint: map one scenario across physical evidence, customer actions, frontstage actions, backstage actions, and support processes, separated by the lines of interaction, visibility, and internal interaction, with fail points, wait points, standards, and owners marked. Use when someone asks for a service blueprint, frontstage and backstage mapping, what happens behind the scenes to deliver a journey, or why a service keeps failing at handoffs." --- # Service Blueprint ## Purpose A service blueprint shows how a service is actually delivered, not just how it feels to the customer. It takes one customer journey as the spine, then lays out the work above and below the line of visibility that makes each step happen: visible staff and system actions, hidden staff actions, and the support processes and systems behind them. Use it to find where a service breaks: handoffs nobody owns, waits nobody measures, backstage steps that the frontstage promise depends on but cannot control, and evidence that contradicts what staff say. A journey map tells you where the customer hurts. A blueprint tells you which internal step causes it and who can fix it. The method traces to G. Lynn Shostack, described in Harvard Business Review in 1984 in "Designing Services That Deliver", and was refined in later service marketing work. The five-lane form in this skill follows the Nielsen Norman Group treatment. Do not use a blueprint for a single screen flow (use a task flow), for a network of actors with no sequence (use an ecosystem map), or for the whole customer lifecycle at once. One blueprint covers one scenario for one customer segment. ## Workflow ### 1. Scope before you draw Write these down first and put them in the header of the output. If any one is missing, ask or state an explicit assumption. - Scenario: one specific job, stated in a verb phrase. Good: "patient books, attends, and pays for a first clinic appointment". Bad: "customer service" or "the onboarding experience". - Customer segment: one segment or persona. Different segments often take different paths, and merging them hides both. - State: current state (how it works now, warts included) or future state (how a planned service should work). Never mix the two in one diagram without labeling each differing cell. - Goal: the decision this blueprint has to support. Examples: cut drop-off at booking, find why refunds take so long, check whether a new offer can be staffed. - Boundaries: what starts the scenario and what counts as done. Do not map past them. - Granularity: pick a step size where each customer action is one observable thing the customer does. If a column needs a paragraph, split it. If two columns always happen together with no decision or handoff between them, merge them. Rule of thumb: 5 to 12 columns for a first blueprint. More than 15 usually means the scenario is too broad or the step size is too fine for the goal. ### 2. Gather two kinds of research A blueprint built from one kind alone will be wrong in predictable ways. - Customer research gives you the customer actions lane and the evidence. Use interviews, field observation, diary studies, support tickets, or an existing journey map. Record what customers actually do, including workarounds, skipped steps, and retries, not what the process says they should do. - Internal research gives you the frontstage, backstage, and support lanes. Use at least two methods that put you in direct contact with the work: shadow or observe staff, interview frontstage and backstage staff separately, walk the physical or digital space, read the real scripts, checklists, and system screens staff use. Warning sign: if every backstage cell sounds clean and orderly, you mapped the official procedure, not the work. Ask staff what they do when the system is down, when the previous step is late, and who they call when stuck. Those answers are the blueprint. If no research is available, still draft, but label the header "Draft from assumptions, not yet validated" and list which lanes are assumed. Never present an assumed lane as observed. ### 3. Lay out the customer actions spine List customer actions left to right, in time order, one per column. Use the customer's verbs: searches, calls, fills in, waits, pays, receives, returns. This row is the backbone. Every other lane answers, for each column: what does the customer see, what do we do in view, what do we do out of view, and what has to be true underneath for that to work. ### 4. Add frontstage actions, then test the line of visibility For each customer action, write what the organization does that the customer directly perceives: a person greeting, a call being answered, a screen responding, an automated email arriving, a driver arriving at the door. Placement test for every cell: could the customer see, hear, or otherwise directly perceive this while it happens? If yes, it belongs in frontstage. If the customer only sees the result later, the action itself is backstage and the result may be physical evidence. Common errors: - Putting "system checks eligibility" in frontstage because a progress bar shows. The check is backstage, the progress bar is evidence, and a staff member explaining the result on a call is frontstage. - Putting a phone reservation in frontstage in full. The conversation is frontstage, the agent typing into the booking system while talking is backstage work done in parallel. Split them. - Leaving automated steps out. A visible automated response is frontstage even when no person is involved. Name the system in the cell. ### 5. Add backstage actions and support processes, and keep them separate Backstage: actions by contact employees (the same people or roles who also work frontstage) that the customer cannot see. Preparing the room before the customer arrives, checking the unit, calling the supplier to confirm a lead time, writing up notes after the visit. Support processes: work by people who never interact with the customer in this scenario, plus systems, policies, and outside partners required for delivery. Payment verification, inventory updates, scheduling software, cleaning contracts, pricing rules, IT infrastructure. Do not merge these two lanes to save space. The line of internal interaction between them marks a real handoff: contact staff depend on support they do not control, and that dependency is where many failures live. If a cell needs a system and a person, name both, for example "Support: billing system flags unpaid balance; finance team reviews flags each morning". Draw dependency arrows where a cell cannot start until another finishes. One-way arrow for a one-way dependency, double-headed arrow where two sides must agree or coordinate. Every crossing between lanes is a handoff, and every handoff is a candidate failure point. ### 6. Layer physical evidence on top For each column, list the tangible or digital things the customer encounters: storefront, signage, uniform, app screen, confirmation email, invoice, packaging, the product itself. Evidence is not decoration. Check it against the promise made at that step. A premium-priced service with a photocopied form, or a "your booking is confirmed" email that lists no time or place, is a finding, not a detail. Note evidence backstage staff rely on too when it affects delivery, such as internal checklists and printed manifests. ### 7. Add time, standards, and owners below or inside cells For each step that can stall or vary, record: - Time: observed duration or wait, plus the maximum tolerable time if the team has one. Use observed numbers only. If you did not measure it, write "not measured" instead of guessing. - Standard: the script, tolerance, or quality rule for that step if one exists, for example greeting within a set time, or confirmation sent before the customer leaves. - Owner: the role responsible for the step and for recovery when it fails. "Team" is not an owner. Name a role. Employee discretion matters in services. Where staff are allowed to vary the process (upgrade, refund, rebook without approval), note the limit of that discretion in the cell. Unclear discretion limits show up later as inconsistent customer outcomes. ### 8. Mark fail points and wait points Walk the finished grid and mark: - F: Fail point. A step where things are likely to go wrong, based on evidence: frequent errors, a single person or system with no backup, a handoff with no confirmation, a step that depends on customer-supplied information that is often wrong or missing. - W: Wait point. A step where the customer waits, or where work waits for a person, approval, batch run, or delivery. Record the wait length if measured and whether the customer was told to expect it. A wait the customer was warned about harms less than the same wait unexplained. That is a judgment to discuss with the team, not a fact to assert without data. For each marked point, write a short register entry: what fails or stalls, how anyone knows it happened, what recovery exists today, and who owns the fix. A blueprint with marks but no register is a poster, not a working document. Then prioritize with the team. Rank by harm to the customer and frequency, using whatever complaint, error, or timing data exists. Keep the ranking method stated in the output so a reader can argue with it. ### 9. Read the blueprint back for findings Before handing it over, check for these patterns and report any you find: - A frontstage promise with no backstage step that makes it true. - A column with customer action and evidence, but no owner anywhere below it. - The same information entered twice in different lanes or systems. - A step performed only because a later step needs it, where the later step could be changed instead. - Backstage work that peaks at the same time as frontstage demand, so the same staff are pulled both ways. - Evidence that arrives after the moment it was meant to reassure, such as a confirmation that lands after the appointment. - A future-state blueprint with no note of which backstage or support steps are new, changed, or still missing. In a future-state blueprint, tag cells as New, Changed, or Existing so builders can scope the work. ### 10. Validate and version Walk the blueprint through with at least one person who does the frontstage work and one who does backstage or support work. Note disagreements on the blueprint instead of smoothing them over: a disagreement about how a step works is a finding. Add header version and date. Services change, systems change, and an undated blueprint gets trusted long after it stops being true. Revisit after any process, staffing, or system change that touches a lane. ## Output Contract Deliver, in this order: 1. Header block: title, scenario, customer segment, state (current or future), goal, date, version, research basis (what customer and internal research was used, or the assumptions label from step 2). 2. The blueprint grid as a Markdown table: one column per customer action step, one row per lane, in this order from top to bottom: Physical Evidence, Customer Actions, line of interaction, Frontstage Actions, line of visibility, Backstage Actions, line of internal interaction, Support Processes. Represent each line as its own row with the line name repeated across cells, so the table stays readable in plain text. Add Time / Standard / Owner as an extra row when step 7 data exists. A validator for this exact table format ships in `bin/validate_blueprint.py`. 3. Fail and wait register: a table with columns ID (F1, W1, and so on), Step, What happens, How it is detected, Current recovery, Owner, Priority. 4. Findings and next steps: the patterns found in step 9, the top fixes the team agreed to prioritize, and open questions or disagreements left unresolved. Templates for the grid and register are in `assets/blueprint-template.md`. A complete worked example (clinic first appointment) is in `references/worked-example.md`. Lane definitions, edge cases, and notation notes are in `references/anatomy-and-notation.md`. ## Operating Rules - One scenario, one segment, one blueprint. Split rather than merge. - Never invent times, standards, failure rates, or quotes. Unmeasured stays "not measured". Unobserved stays labeled as assumed. - Keep backstage and support processes as separate lanes, always. - Map how the work actually happens, not how the procedure manual says it should. Record the workaround when you find one. - Build the grid with the people who do the work when you can. A blueprint drawn alone from assumptions is a draft, and it must say so. - Mark fail and wait points from evidence (errors, complaints, observation, single points of failure), not from vibes. State the evidence in the register. - In a future-state blueprint, tag new and changed cells. A future state that looks identical in effort to the current state is hiding the build work. - Keep the diagram readable. If it needs a legend to explain your symbols beyond F, W, and dependency arrows, simplify the symbols. - Do not turn the blueprint into a solution pitch. Findings and prioritized fixes belong in the register and findings section, kept separate from the map of what is.