Service Blueprint from Research Data

Most organizations already know how their service works. The knowledge is just scattered: the research repository holds the customer's side, the support queue holds the failure modes, the ops runbooks hold the backstage steps nobody outside operations has read, and the rest lives in the heads of people who run the service every day. A blueprinting project usually begins by ignoring all of it and booking a two-day workshop with a blank wall.

That workshop format has a predictable cost. The people who know the backstage best spend the first day reconstructing things that are already written down somewhere, and the second day runs out before anyone gets to the interesting questions — where handoffs fail, where the evidence contradicts itself, and which steps exist only in one person's memory.

This workflow flips the order. Agents read what the organization already has and assemble a draft blueprint with every step linked to its sources, plus an explicit list of where the evidence is thin or contradictory. The workshop then spends its time validating, correcting, and filling gaps — work only the people who run the service can do — instead of transcribing.

Use it when the service already exists, has been running long enough to generate research, tickets, and process documentation, and a redesign or digitization project needs a shared picture of how it actually works today. It suits end-to-end journeys that cross teams: claims, onboarding, appointment booking, returns, account recovery.

Do not use it for a service that does not exist yet — there is nothing to assemble — or as a substitute for talking to the people who run the service. The draft is workshop preparation, not the deliverable. If the validation workshop never happens, you have a plausible document that nobody has confirmed, which is worse than no blueprint at all.

• An existing service with research, tickets, runbooks, or process docs spread across tools.
• A redesign or digital intake project that needs the current state mapped before changing it.
• Cross-team journeys where no single person can describe the whole backstage.
• Workshop preparation when stakeholder time is scarce and expensive.

The quality of the draft is bounded by what you feed it. Spend the first hour exporting and staging sources into one folder, each in plain text or CSV: the relevant studies from the research repository, a sample of support tickets for the journey (a few hundred is plenty), the ops runbooks and SOPs that describe backstage steps, internal process documentation, and any stakeholder interview notes from earlier discovery work.

Anonymize as you go. Replace customer names and identifiers, and strip anything the source teams would not want quoted in a workshop. Label each file with its source system and date, because the blueprint will cite files by name and a citation to an unlabeled export is not much of a citation.

Resist the urge to be exhaustive. One representative runbook per backstage team beats ten near-duplicates, and a stratified sample of tickets beats the full queue. The agents will read whatever you stage; staging is where you exercise judgment about what is representative.

service-blueprint/
  evidence/
    research/
      claims-diary-study-2025.md        # from the research repository
      claimant-interviews-summary.md
    tickets/
      claims-tickets-sample.csv         # 300 tickets, anonymized, with category and free text
    runbooks/
      claims-intake-runbook.md          # ops runbook, backstage steps
      assessor-allocation-sop.md
    process-docs/
      claims-handling-policy-excerpt.md
    stakeholder-notes/
      ops-lead-interview-2026-04.md
      contact-centre-lead-notes.md
  output/
    blueprint.yaml                      # written by the workflow
    blueprint.html                      # rendered view for the workshop
    gaps.md                             # thin or contradictory evidence, by lane

This runs as a Claude Code dynamic workflow: a JavaScript script that Claude writes and runs in the background, orchestrating subagents while intermediate results stay in script variables rather than in Claude's own context. That separation is what makes it possible to read a research repository, a few hundred tickets, and a stack of runbooks in one run without the later sources being read more carelessly than the first.

The run has three stages. First, one evidence agent per source file extracts moments, steps, and handoffs in a shared format — who acts, what happens, what the customer sees, what the source actually says. Second, five lane agents each draft one blueprint layer (customer actions, frontstage, backstage, support processes, physical and digital evidence) by pulling from the extracted moments and citing sources for every step. Third, a gap agent reviews the assembled blueprint and flags lanes where evidence is thin, single-sourced, or contradictory.

Workflows can run up to 16 agents concurrently and up to 1,000 in a run, and a run is resumable, which matters when the ticket sample is large. You trigger it by including the word workflow in the prompt or via /effort ultracode. Subagent definitions live in .claude/agents/*.md, and the finished prompt can be saved to .claude/workflows/ in the project (or ~/.claude/workflows/ for personal use) as a reusable command like /blueprint.

Agree the structure before the run, not during it. A blueprint is a grid: journey phases across the top, lanes down the side, and at every intersection the steps, the handoffs, and the evidence for both. Keeping it as YAML rather than a drawing means every step can carry citations, every handoff can name the teams on either side, and the rendered view can be regenerated whenever the data changes.

The line of visibility and the line of internal interaction are part of the structure, not decoration. They are where most service failures live, so the format makes every backstage step name which frontstage moment it supports, and every handoff name what crosses the line.

service: Motor claims, lodgement to settlement
phases:
  - id: lodge
    label: Lodge the claim
  - id: assess
    label: Assessment
lanes:
  customer_actions:
    - phase: lodge
      step: Calls the claims line or starts the web form after the incident
      sources: [claims-diary-study-2025.md, claims-tickets-sample.csv]
  frontstage:
    - phase: lodge
      step: Contact centre agent captures incident details in the claims system
      sources: [contact-centre-lead-notes.md, claims-intake-runbook.md]
  backstage:
    - phase: assess
      step: Claims handler requests assessor allocation via the allocation queue
      handoff_to: assessor_team
      sources: [assessor-allocation-sop.md]
      confidence: single-source
  support_processes:
    - phase: assess
      step: Policy system overnight batch syncs cover details to the claims system
      sources: [claims-intake-runbook.md]
  evidence:
    - phase: lodge
      step: Confirmation email with claim number and what-happens-next summary
      sources: [claims-diary-study-2025.md]
gaps:
  - lane: backstage
    phase: assess
    note: Allocation criteria described differently in SOP vs ops lead interview; confirm in workshop

Point the workflow at the evidence folder and the blueprint structure, and be explicit about the two rules that protect the output: every step must cite at least one source file, and the agents must never invent a process step to make the journey look complete. A gap in the blueprint is information; a plausible invented step is a liability that someone will repeat in a steering committee.

Run this as a workflow.

Input: ./evidence contains research summaries, an anonymized ticket sample (CSV), ops runbooks, process docs, and stakeholder interview notes for the motor claims journey. ./blueprint-template.yaml defines the phases and lanes.

Stage 1 - Extraction: For each evidence file, launch one agent that reads only that file. It returns moments in a shared format: { phase_guess, actor, action, what_customer_sees, handoff, source_file, supporting_excerpt }. Excerpts must be copied verbatim from the source. If the file says nothing about a phase, return nothing for it.

Stage 2 - Lanes: Launch one agent per lane (customer actions, frontstage, backstage, support processes, evidence). Each drafts its lane across all phases using only the extracted moments, citing source files per step, and marking steps as single-source where only one file supports them. Backstage steps must name the frontstage moment they support and any handoff across the line of internal interaction.

Stage 3 - Gaps: A separate agent reviews the assembled blueprint and writes gaps.md: lanes or phases with thin evidence, steps where sources contradict each other (quote both), and steps that appear in runbooks but never in customer-facing evidence or vice versa.

Output: blueprint.yaml following the template, blueprint.html as a rendered grid with citations and gap flags visible, and gaps.md ordered by how much workshop time each gap deserves. Do not invent steps to fill empty cells; leave them empty and list them in gaps.md.

Claude writes the orchestration script itself when you trigger the workflow; the sketch below shows the shape with an agent() pseudo-API so you can see where evidence stays out of the main context and where the rules are enforced. It is illustrative, not the literal generated code.

const fs = require("node:fs")
const sources = walk("./evidence")            // every staged evidence file
const template = fs.readFileSync("./blueprint-template.yaml", "utf8")

// Stage 1: one extraction agent per source file, in parallel batches.
const moments = await Promise.all(
  sources.map((file) =>
    agent(
      "Extract service moments from one evidence file.\n" +
        "File: " + file + "\n" +
        "Return JSON: [{ phase_guess, actor, action, what_customer_sees, handoff, source_file, supporting_excerpt }]. " +
        "Excerpts must be verbatim. Report nothing for phases the file does not cover.",
      { model: "sonnet" }
    )
  )
)

// Stage 2: one lane agent per blueprint layer.
const lanes = ["customer_actions", "frontstage", "backstage", "support_processes", "evidence"]
const drafted = await Promise.all(
  lanes.map((lane) =>
    agent(
      "Draft the " + lane + " lane of the blueprint using only these moments.\n" +
        "Template:\n" + template + "\n" +
        "Cite source files per step; mark single-source steps; never invent steps.\n\n" +
        JSON.stringify(moments.flat()),
      { model: "opus" }
    )
  )
)

// Stage 3: gap agent reviews the assembled draft.
const gaps = await agent(
  "Review this assembled blueprint for thin, single-source, or contradictory evidence. " +
    "Quote contradicting sources side by side. Order gaps by workshop priority.\n\n" +
    drafted.join("\n\n"),
  { model: "opus" }
)

fs.writeFileSync("./output/blueprint.yaml", assemble(template, drafted))
fs.writeFileSync("./output/gaps.md", gaps)

The lane agents share one definition that the workflow parameterizes per lane. Keeping it in .claude/agents/ means the rules about citation and invented steps are enforced in the agent itself, not re-typed into every prompt — and the next blueprint project inherits them.

---
name: blueprint-lane-writer
description: Drafts one lane of a service blueprint from extracted evidence moments, with citations per step. Use during service blueprint workflows.
tools: Read, Write
model: opus
---

You draft exactly one lane of a service blueprint (customer actions, frontstage, backstage, support processes, or evidence) across the journey phases you are given.

Rules:
- Use only the extracted moments provided. Never add a step from general knowledge of how services usually work.
- Every step cites at least one source file. Mark steps supported by a single file as confidence: single-source.
- For backstage and support steps, name the frontstage moment the step supports and any handoff across the line of internal interaction, including the teams on each side.
- If a phase has no supporting moments for this lane, leave it empty and say so. Empty cells are workshop input, not failures.
- Where two moments from different sources describe the same step differently, include both versions and flag the conflict instead of choosing one.

Stage the evidence and anonymize it; expect this to take an hour or two and to be the most valuable hour of the project, because it forces you to find out what the organization actually has. Adapt the blueprint template's phases to the service — five to eight phases is usually right — and run the workflow. For a typical evidence set the run finishes within the half day, most of it in the extraction stage.

Read gaps.md before the blueprint. It tells you where the draft is least trustworthy and what the workshop must cover. Then spot-check citations: pick six steps across different lanes and confirm the cited files actually support them. If a citation does not hold, treat the lane as suspect and rerun its lane agent with a stricter prompt.

Book the validation workshop with the people who run the service — frontline staff, ops, the teams behind the line of visibility — and structure it around the gaps and conflicts rather than a lane-by-lane read-through. The draft's job is to make their two hours count.

An insurer mapped its motor claims journey, lodgement to settlement, before a claims-system replacement. The evidence set was two diary studies, 320 sampled tickets, four runbooks, and notes from six stakeholder interviews. Extraction produced 411 moments; the lane agents drafted a blueprint across seven phases; the gap agent flagged 14 items.

The pattern that mattered sat backstage. Customers experienced the assessment phase as silence — the diary study had participants checking the portal daily with nothing changing — while the runbooks showed the claim crossing four internal queues in that phase, with two handoffs that had no notification attached to them. Eleven of the fourteen flagged gaps were in the backstage and support lanes, and the workshop confirmed that most of the delay sat in the assessor-allocation handoff, which the SOP and the ops lead described differently.

The team's redesign brief changed as a result: instead of redesigning the portal status page first, they prioritized notification triggers on the two silent handoffs. The blueprint, with citations, became the artifact the claims-system vendor was briefed against.

A B2B SaaS company ran the workflow on its customer onboarding, from contract signature to first value. Sales, implementation, and support each had documentation describing the process, and the gap agent's most useful output was a conflict list: nine steps where the three teams' documents described different owners, different timelines, or different definitions of done for the same moment.

The most expensive conflict was the kickoff call. Sales documentation promised it within five business days of signature; the implementation runbook scheduled it after environment provisioning, which ticket data showed averaging twelve days; support tickets in the sample included 23 customers asking why nothing had happened since they signed. None of the three teams was wrong about its own process, and none had seen the other two laid out in the same grid.

The validation workshop took ninety minutes instead of the planned half day, because the argument was already on the wall with citations. The team agreed a single owner per phase and rebuilt the kickoff commitment around provisioning reality, and the blueprint YAML now lives in the implementation team's repository and gets re-rendered each quarter.

A hospital service design team mapped its outpatient appointment journey — referral, triage, scheduling, the appointment itself, and follow-up — before commissioning a digital intake project. Evidence included patient interview summaries from an earlier study, call-centre logs, the booking team's standard operating procedures, and clinic-level process documents that varied by department.

The gap agent flagged the support-process lane as the thinnest: the referral triage step was described in three department documents with three different turnaround targets, and nothing in the evidence said what patients were told to expect during that wait. The customer-actions lane showed patients calling the booking line an average of 2.4 times per appointment in the call-log sample, mostly to ask whether their referral had been received.

The workshop, run with booking staff and two clinic coordinators, confirmed the variation was real rather than a documentation artifact. The digital intake project's scope changed before procurement: referral-status visibility was promoted from a nice-to-have to the first release, and the blueprint became the shared current-state reference attached to the business case.

The test that separates a usable draft from a plausible fiction is the same as in research synthesis: traceability. Every step should survive the question of which source says so. An agent under pressure to produce a complete-looking grid will otherwise fill empty cells with how services like this usually work, and those invented steps are exactly the ones a workshop participant will not think to challenge.

The draft describes what the documentation and research say, which is not the same as what happens. Runbooks drift from practice, tickets over-represent failure, and stakeholder notes carry their authors' vantage points. Only the validation workshop — and, where it matters, observation of the service being delivered — turns the draft into a blueprint the organization can act on.

Coverage counts and ticket percentages describe the staged sample, not the service. A statement like 23 customers asked why nothing had happened is an honest description of the sample and an invitation to check operational data, not a rate. And the workflow cannot weigh the politics of a handoff: deciding which team should own a step, or whether a backstage process should exist at all, is service design work that humans do with the people affected.

Treat the rendered blueprint as a living draft with a date on it. A blueprint that is not maintained after the project decays into the same kind of confident, outdated documentation the workflow was built to interrogate.

• Cannot confirm that documented processes match practice; the workshop and observation do that.
• Cannot turn ticket samples into rates across all customers without operational data.
• Cannot resolve ownership or political questions about handoffs; it can only surface them.
• Cannot replace talking to frontline staff; it makes that conversation start further along.

Save the prompt, the YAML template, and the lane-writer agent definition in the repository, and save the prompt to .claude/workflows/ so the next service can be mapped with a /blueprint command against a fresh evidence folder. The structure stays constant; only the evidence and the phases change.

1. Stage and anonymize the evidence: research, tickets, runbooks, process docs, stakeholder notes.
2. Adapt the blueprint template: name 5-8 journey phases for this service.
3. Run the workflow: one extraction agent per source file.
4. Draft the five lanes with citations per step and single-source flags.
5. Run the gap review for thin, conflicting, or missing evidence by lane.
6. Spot-check 6 citations across lanes before sharing anything.
7. Run the validation workshop around the gaps and conflicts, not a read-through.
8. Correct the YAML, re-render, date it, and assign an owner to keep it current.