Journey Maps and Service Blueprints from Product Data

This module takes the evidence discipline built in Modules 1 to 4 — packets, citations, observation kept separate from inference — and applies it to two artifacts with a bad reputation for decay: journey maps and service blueprints. Both are usually produced in workshops, from memory, and both get quoted in decks long after anyone could check them. The promise here is narrower and more useful: a map built from what the product actually records, with the gaps marked, that can be regenerated when the data changes.

Set expectations about scope. The module covers two related workflows: journey mapping from product data, and extending that journey into a service blueprint using research repositories, runbooks, and ops documentation. Both are Advanced workflows in the school's library, and both follow the same shape — per-source evidence agents, a synthesis step, a challenge step, and a human review session that is part of the workflow rather than an afterthought.

If participants have lived through a journey-mapping workshop that produced a beautiful poster nobody trusts, invite that experience into the room early. The contrast between the workshop poster and the evidence-linked map is the emotional core of the module, and it lands harder when people supply their own examples.

The opening claim is deliberately blunt because the pattern is so common. Workshop-built maps are not worthless — they surface assumptions and align teams — but they are routinely treated as evidence when they are actually a record of what the people in the room believed that day. The emotions row is the usual casualty: it gets filled in because an empty cell looks unfinished, and the invented emotion then outlives everyone's memory of having invented it.

The fix is not more workshops or better facilitation. It is provenance: the same rule that governed synthesis in Module 3, applied to a different artifact. Every stage, pain point, and emotion on the map should be traceable to something a user actually did or said — a funnel drop, a ticket, a session note, an interview quote. Maps built this way are visibly less symmetrical than the workshop version, with empty cells and unverified flags, and that asymmetry is the feature, not the flaw.

Name the reason teams skip provenance: volume. The evidence for one journey is scattered across an analytics export, a few thousand tickets, session-recording notes, and a research repository. Reading and extracting all of it by hand is weeks of work, which is exactly the kind of work agents do well — while interpretation of what the journey means stays with people. That division of labour is the rest of the module.

This table is the intellectual core of the input stage. Analytics tells you what happened and how often, but nothing about why; worse, anything that is not instrumented reads as calm, which is silence masquerading as satisfaction. Tickets tell you what hurt enough to make someone write, which over-represents anger and completely misses the people who quietly gave up. Session notes show real behaviour in context but for a handful of users. Interviews give you language, motivation, and emotion — filtered through memory and the human tendency to be polite to a researcher.

The practical consequence is that the workflow keeps sources separate during extraction, precisely so the synthesis step can say which kind of evidence supports each claim. Emotion claims need interview or verbatim support; volume claims need analytics; behaviour-in-context claims need session notes. A claim that draws on all three is strong. A claim resting on one source should carry that fact visibly.

Before any agent runs, two human decisions matter. First, define the journey's edges in one paragraph — signup to activation is a different map from first marketing touch to renewal, and an undefined edge is the first place a map starts inventing. Second, anonymise the exports before anything reaches the workflow: the agents should see behaviour and language, not identities. Both of these are designer judgement, not agent work.

Walk the orchestration shape, because it is the same pattern participants saw in synthesis and will see again in the blueprint workflow. The run is a Claude Code dynamic workflow: an orchestration script holds the source files and extracted evidence in its own variables, so thousands of tickets and a long event export never enter the main conversation context — only the structured extractions and the final map do. Ticket extraction alone often fans out into dozens of batches, which is why the concurrency matters here.

Three agent roles carry the discipline. Evidence agents are per-source and refuse to interpret beyond their own source: analytics gives behaviour and volume, not feelings; tickets give reported pain, not prevalence. Every extracted item carries a citation back to a file row, ticket ID, or note ID, and quotes must be verbatim. The synthesis agent assembles stages, actions, thoughts, emotions, pain points, and opportunities, and is required to attach evidence IDs to every cell and to quantify where the analytics allows it. The challenge agent then audits the draft and marks anything thin, single-source, or contradicted as UNVERIFIED, listing it in a gaps file alongside the manifest's known gaps.

Two rules in the prompt do most of the protective work: do not infer emotions from analytics alone, and do not fill empty cells for symmetry. Both are exactly the moves an agent under pressure to look complete will otherwise make. The manifest's known-gaps line — for example, mobile web not instrumented — is what stops the absence of data being read as the absence of problems.

Walk the diagram left to right and name who owns each column. The left column is human work: deciding which exports represent the journey, anonymising them, and writing the manifest with its known gaps. The second column is the evidence agents — one per source or batch — extracting moments into a shared schema with verbatim quotes and citations, then merging everything into a single evidence ledger with stable IDs.

The third column is synthesis. The journey card shows what the map carries: stages, actions, friction, emotion, pain points ranked by combined evidence strength, quantified wherever the analytics allows, with empty stages left visibly empty. The blueprint card underneath previews the second half of the module: once the customer-facing journey exists, the same evidence approach extends it downward into front-stage, back-stage, systems, and policy layers drawn from runbooks and ops documentation.

The right column is where trust is earned. The challenge gate is agent-run but exists to serve the human review: it marks thin, single-source, and contradicted claims as unverified rather than letting the map silently fill itself in. The owner review is the human decision point — accept or dispute each claim, assign owners to the top pain points, date the map, and record which exports produced it so staleness is visible later. If a team adopts only one element from this module, it should be that gate-plus-review pairing.

This slide is the honesty clause of the module, and it deserves unhurried treatment because it is where evidence-based mapping most often gets oversold. The map can only describe the users who showed up in the data. People who bounced before creating an account, or who churned silently, generate nothing — and a map that does not say so will be read as if they do not exist. The same applies to uninstrumented flows: in one of the case studies behind this module, the apparent calm of a workspace-creation stage was partly an artifact of an uninstrumented mobile web flow, and only the manifest's known-gaps line stopped that calm being celebrated.

Causation is the second standing limit. A funnel drop co-located with a pile of tickets tells you where to investigate; it does not tell you why people leave, and turning that correlation into a confident causal story is exactly the laundering Module 4 warned about. Emotion is the third: the workflow's rule is that emotion claims need interview or verbatim support, because reading feelings off event data is invention wearing a chart.

Finally, remind people what the unhappy-minority skew means for the emotion row specifically. In the returns-journey case later in this module, the team labelled the emotion row explicitly as the journey of the unhappy minority, because nothing in tickets or reviews represents customers who returned an item smoothly and said nothing. That label is a small thing that keeps a stakeholder from misreading the whole artifact.

These pairs come from the school's journey-mapping workflow and the traced runs behind it. The pattern in the good column is consistent: a specific stage, a quantity the analytics actually supports, the source identifiers in brackets, and — in two of the three — an explicit statement of what the data does not cover. The bad column is not wrong so much as unfalsifiable: users feel overwhelmed during setup could be true of any product in any year, which is exactly why it survives unchallenged in decks.

The third row deserves a comment because it shows the workflow doing something a workshop cannot. The sales narrative and the usage analytics genuinely disagreed about what drives renewal, and the synthesis did not average them into something nobody had observed. It carried both strands, showed which evidence each rested on — fourteen escalated accounts versus all two hundred and twenty — and flagged the divergence as the map's central open question. Locating a contradiction precisely is often more valuable than resolving it prematurely.

The practical habit to take away: after every run, pick a handful of cells across different stages and check the citations by hand before the map goes anywhere near a stakeholder. If a citation does not hold, treat the surrounding synthesis as suspect. This is the same spot-check discipline from earlier modules, and it takes minutes, not hours.

The move from journey to blueprint is a change of question. The journey map asks what users experience; the blueprint asks what the organisation does — front-stage and back-stage — to produce that experience, and where the handoffs sit. Most organisations already hold the answer in scattered form: the research repository has the customer's side, the support queue has the failure modes, the ops runbooks describe back-stage steps nobody outside operations has read, and the rest lives in the heads of the people who run the service. The traditional blueprinting workshop ignores all of it and starts from a blank wall, which is why the people who know the back-stage best spend day one transcribing things that are already written down.

The agentic version flips the order. Per-source evidence agents extract moments from each staged file, then one lane agent per blueprint layer drafts customer actions, front-stage, back-stage, support processes, and evidence, pulling only from the extracted moments and citing source files for every step. Back-stage steps must name which front-stage moment they support and any handoff across the line of internal interaction, because that is where most service failures live. Keeping the blueprint as a structured file rather than a drawing means every step can carry citations and the rendered grid can be regenerated when the data changes.

The rule that protects the output is the same as the journey rule, stated for a different temptation: never invent a process step to make the grid look complete. An agent under pressure to fill cells will reach for how services like this usually work, and those plausible invented steps are exactly the ones a workshop participant will not think to challenge. A gap in the blueprint is information; an invented step is a liability someone will repeat in a steering committee.

This is the step that turns a plausible draft into something the organisation can act on, and it is the step most tempting to skip because the draft already looks finished. Resist that. Runbooks drift from practice, tickets over-represent failure, and stakeholder notes carry their authors' vantage points. The validation session — with frontline staff, operations, and the teams behind the line of visibility — is what confirms which documented steps still match reality and which exist only on paper.

The structure of the session matters as much as holding it. Walking the grid lane by lane wastes the room's scarce time on things the evidence already supports. Structure it around the gaps file and the flagged conflicts instead: the cells marked unverified, the steps where two sources describe the same moment differently, the back-stage steps that appear in a runbook but never in anything customer-facing. In one of the case studies behind this module, a B2B onboarding blueprint surfaced nine steps where sales, implementation, and support documents disagreed about owners and timelines — and the validation workshop took ninety minutes instead of the planned half day, because the argument was already on the wall with citations.

Close the session with decisions, not vibes. Every unverified cell gets one of three outcomes: gather more evidence, schedule research, or accept the uncertainty explicitly and in writing. The top pain points get owners. The map gets a date and a record of which exports produced it, so its staleness is visible later. That last administrative-sounding step is what makes the next slide possible.

The economic argument for this whole approach lands on this slide. A workshop poster decays because updating it requires re-convening the workshop, so it never gets updated; it just gets quoted with decreasing accuracy. A generated map decays at the same rate, but updating it costs a re-run against fresh exports — the saved workflow, the same schema, the same agents, new data. That difference in update cost is what turns the journey map from a one-off artifact into a living one.

The mechanics are mundane and worth stating. Once the prompt and agent definitions are stable, the run gets saved as a project-level workflow command so the team shares it, and the agent definitions and evidence schema live in version control alongside the map and its ledger. Keeping the ledger next to the map permanently changes how the artifact behaves in meetings: when someone challenges a claim four months later, the answer is a lookup, not a contest of recollections.

The re-run also closes a loop the original poster never could: measurement. In the returns case study coming up next, the team shipped proactive status emails and the following quarter's re-run picked up a thirty-one percent drop in where-is-my-refund tickets from the fresh export. That number fed straight back into the prioritisation conversation. Date every version, record which exports produced it, and treat a map without a date the way you would treat an undated screenshot of a dashboard — as decoration.

This trace comes from the school's journey-mapping workflow and is worth walking slowly because it shows the method working under awkward conditions: almost no product analytics. The returns flow ran partly through a third-party logistics portal the team could not instrument, so the evidence was a year's worth of support tickets, product reviews that mentioned returns, and the carrier's status export. The per-source agents handled the volume — ticket extraction alone fanned out into twenty-four batches — which is precisely the reading work no researcher was ever going to do by hand.

The synthesis put the journey's worst moment somewhere the team had not been focusing: not the return request, but the silence after drop-off. Forty-four percent of return-related tickets were where-is-my-refund messages sent while the parcel was still in transit, and the median gap between drop-off and refund confirmation was eleven days, of which only four were actual processing. Reviews told the same story in harsher language, and the challenge agent confirmed the claim was multi-source and strong — which is what gave the team confidence to act on it.

Notice what the challenge agent flagged on the other side: nothing in tickets or reviews represents customers who returned an item smoothly and said nothing, so the emotion row was explicitly labelled as the journey of the unhappy minority. And notice where the humans were: defining the journey's edges, deciding that proactive status emails were the right response, and reading the next quarter's re-run — a thirty-one percent drop in those tickets — as evidence the fix worked. The agents located the problem. The team designed the answer.

The exercise is deliberately a paper exercise, the same way the Module 1 exercise of this course's companion was: no agents, no exports, just an honest inventory. Most participants discover two things in the first ten minutes. First, the organisation has more relevant evidence than they expected — tickets, old research, runbooks — scattered across tools nobody has connected. Second, the journey's edges are fuzzier than they assumed, and two colleagues asked to define the same journey will give different start and end points. Both discoveries are the point.

Steer people towards a journey that is contested or expensive: one where teams disagree about where users struggle, where a leadership group is about to fund work based on an assumed journey, or where the existing map is old enough that nobody trusts it. The exercise is much less useful on a journey everyone already agrees about.

The known-gaps line is the part to push hardest on, because it is the part teams skip. Uninstrumented surfaces, users who never generate data, the silent majority who had a fine experience — writing these down before any run is what stops the eventual map being read as more complete than it is. And the last bullet seeds the validation habit: if the participant cannot name the frontline people who would check the back-stage lanes, that is a gap in itself.

Recap by connecting the bullets rather than repeating them. Provenance is the through-line: the same evidence discipline that governed packets, teardowns, and synthesis earlier in the course, applied to two artifacts that traditionally escape it. The source table explains why extraction stays per-source; the three-agent pattern explains how the volume gets handled without the discipline collapsing; the challenge gate and the validation session are the two places weak evidence gets caught — one automated, one human. And regeneration is what makes the whole thing worth doing more than once.

Be explicit that this module produced an artifact full of ranked pain points, owners, and evidence — and that none of it has changed the product yet. That is deliberate framing for Module 6, From Insight to Brief, which covers the step most research decks skip: converting findings into design briefs that carry their evidence with them, prioritising by decision impact rather than by how interesting a finding is, and tracking what actually shipped because of the research.

If participants did the exercise, ask them to bring the inventory page to Module 6. The pain points they expect to find in their own journey are exactly the raw material for the brief-writing exercise there, and the contrast between a ranked pain point and a brief that an agent or a team could act on is the gap that module closes.