Living Journey Maps: From Transcripts to Sentiment Curves

The Journey Map Rots; Ours Compiles

The standard journey map dies in three predictable ways. First, the spine is wrong. Teams organize it around internal departments rather than customer intent. Second, the emotions are fictional. People draw dramatic valleys because the story needs drama, not because the evidence supports it. Third, the map has no maintenance path. Once the workshop ends, nobody can tell which rows are real, which came from one anecdote, and which were smuggled in by an opinionated manager.

ASD counters all three failures by treating the journey map as an artifact under method control. The output kind is `journey-map`. The producing method is usually `journey-from-transcripts` or, when mental structure matters more than chronology, `mental-model-alignment`. The runtime cares about the boring details that make the artifact honest: minimum node count, evidence per node, non-empty emotion field, non-empty touchpoint field, and later a Critic verdict before anything becomes final.

That means I do not begin with diagramming software. I begin with a lens, a scope decision, and evidence rows. The lens says whose journey this is. The scope says where it starts and ends. The evidence rows say what actually happened, in whose words, through which channel, at what point in the chronology. From there the map is a projection, not a performance.

The practical shape is simple. A journey map artifact carries stages. Each stage is a node. Each node cites the evidence register. The rows can be rendered as tables or diagrams later, but the map's truth is in the data structure. This is why I can update it. If a new transcript or telemetry row lands, I do not need to restage a workshop. I need to revise the artifact and rerun the gates.

The authored journey map template makes that discipline tangible. It asks for stages, channel and touchpoint detail, quoted emotion, pain or breakdown, and evidence references. It also keeps the emotion line as data. Unless I have a proper number ledger, the emotional line is a markdown table, not a seductive chart. That restraint matters. Charts are persuasive. Tables are accountable.

# Customer Journey Map — <segment> (<current|future>)

## Stages
| Stage | Customer actions (evidence) | Channels & touchpoints | Emotion (quoted) | Pain / breakdown | Evidence refs |
|---|---|---|---|---|---|

## Emotion line (derived)
| Stage | Emotion score (1-5) | Supporting quote | Evidence ref |
|---|---|---|---|

## Moments of truth
<evidence-backed list>

The machine rules do not make the work mechanical. They simply shift my judgment to the right place. I decide the scope. I decide whether adjacent quotes belong to one stage or two. I decide which summary label respects the evidence best. The engine decides whether I have cited enough to make that judgment auditable. That division of labor is healthy.

It also keeps current and future states from contaminating each other. The most common journey-map fraud is a blended current-future poster where desired features are drawn into the current experience. ASD blocks that habit because current and future are separate artifacts. If I want to design a better journey, I can. I just cannot pretend the better journey already happened.

From Verbatim Evidence to Journey Stages

The step that matters most is stage construction. A good stage is about customer intent in time. It is not "contact centre triage" or "claims processing" because those are inside-out labels. It is "send and wait," "rebook," "return," "check in," or "ask for help." If I name stages from the organization's point of view, I have already started to misdiagnose the service.

My pipeline is narrow by design. I ingest transcripts, tickets, documents, and telemetry into the evidence register under the only three allowed kinds: `quote`, `telemetry`, and `document`. I then tag rows with provisional phase candidates, channel, touchpoint, and whether the row describes an action, a feeling, a breakdown, a workaround, or a recovery. The goal is not deep ontological elegance. The goal is enough structure to sort the chronology without flattening the voices.

Albatross Airways is a useful case because the corpus was messy enough to expose weak method. Over eight weeks the programme assembled 140 passenger interviews, 9,000 disruption tickets, 1.1 million app and site sessions, 45 staff debriefs, and 2,300 social posts. If I had tried to journey-map that corpus by manual stickies, I would have drowned in anecdotes. Instead the method treated the corpus as a searchable evidence field. Stage candidates had to emerge repeatedly across sources. Rows with insufficient support stayed parked or marked open.

The journey-from-transcripts method is explicit about the contract. It produces a `journey-map`. It assigns steps to roles. It requires acceptance rules. It does not allow a mapper to smuggle in a stage because it sounds narratively pleasing.

{
  "method": {
    "id": "journey-from-transcripts",
    "phase": "synthesis",
    "outputKind": "journey-map"
  },
  "steps": [
    {
      "role": "researcher",
      "instruction": "Extract distinct customer actions, touchpoints, and breakdowns from the evidence register."
    },
    {
      "role": "mapper",
      "instruction": "Order the actions into customer-intent stages and attach evidence-backed emotions and pains."
    },
    {
      "role": "critic",
      "instruction": "Reject any stage lacking supporting evidence or any emotion unsupported by a quoted line.",
      "gate": true
    }
  ],
  "acceptance": [
    { "rule": "min-nodes", "min": 3 },
    { "rule": "min-evidence-per-node", "min": 1 },
    { "rule": "field-non-empty", "field": "emotion" },
    { "rule": "field-non-empty", "field": "touchpoint" }
  ]
}

What that contract really does is force me to defend the stage boundary. Suppose I have five passenger quotes about checking the app, then the departures board, then asking staff because none of the channels agree. I can collapse that into a single stage if the customer goal is still the same: understand what is happening. I should not split it into three stages unless the intent changes. The map becomes better when stages reflect the customer's errand rather than my urge for more granularity.

Tagging still matters. A decent tagging schema lets me check whether a stage is over-weighted toward one source or one channel. If every quote in a stage comes from social posts and none from interviews or telemetry, I read it cautiously. If a stage has quotes but no operational trace, I know I may be seeing a perception seam rather than a measured queue. Both are useful. They are just different.

{
  "evidence_item": {
    "phase": ["pre_flight", "at_airport", "new_arrangements", "rebook", "recovery"],
    "channel": ["app", "sms", "email", "phone", "desk", "gate_board", "social", "web_form"],
    "type": ["verbatim_quote", "observed_behavior", "operational_fact", "workaround"],
    "emotion_1_5": "integer 1-5 or null",
    "pain_code": ["INFO", "REB", "CARE", "COMP", "QUEUE", "OTHER"],
    "source_lines": "required for quote verification"
  }
}

The Albatross map eventually stabilized around five stages because that is where the evidence converged: Pre-flight, At-airport, New arrangements, Rebook, and Recovery. Not six. Not twelve. Five. That structure was strong precisely because it survived workshop challenge. During validation workshops, participants turned objections into issue rows against the map. Twenty-nine fixes were merged and twelve were parked pending stronger evidence. That is what I mean by a living map. It is not endlessly mutable. It is formally repairable.

That last row is where most teams cheat. They cannot resist improving the story while mapping the current state. I get the temptation. But if I do that, I lose the diagnostic. The journey map's job is to tell the truth about what is happening now. The blueprint can carry the redesign later.

Sentiment Curves from Evidence

Emotion is the most abused row in service design. Teams either avoid it because it feels soft, or they overperform it because it makes the poster persuasive. ASD takes a more severe view. Emotion belongs in the map, but only as an evidence-backed field. If nobody said it, showed it, or wrote it in a way that clearly carries valence, the map should not pretend to know.

This is why the old freeform `emotion.yaml` block had to die. A YAML file is not a mood board. If I label something YAML, it should parse. More importantly, it should encode operational rules I can actually run. The sentiment configuration below is valid YAML and expresses the load-bearing constraints: explicit-evidence scoring, thresholds, lexicon path, minimum quotes per stage, source diversity, and calibration guards.

version: 1
scale:
  min: 1
  max: 5
labels:
  1: distressed
  2: negative
  3: neutral
  4: positive
  5: delighted
scoring:
  explicit_evidence_only: true
  null_when_absent: true
  min_quotes_per_stage: 2
  min_sources_per_stage: 2
  calibration_sample_size: 50
  stddev_floor_per_phase: 0.8
thresholds:
  negative:
    max_score: 2
  neutral:
    min_score: 3
    max_score: 3
  positive:
    min_score: 4
lexicon:
  path: research/emotion-lexicon.yml
  use_anchor_quotes: true
anchors:
  distressed:
    description: crisis language, panic, tears, giving up
    example_quote: "The children slept on our coats."
    example_source: "INT-041"
  negative:
    description: frustration, distrust, workaround forming
    example_quote: "Nobody could tell me anything, so I stopped asking."
    example_source: "INT-074"
  neutral:
    description: transactional completion with no explicit valence
    example_quote: "I filled in the form and waited."
    example_source: "INT-118"
  positive:
    description: relief, gratitude, acknowledged effort
    example_quote: "The agent actually fixed it while I watched."
    example_source: "INT-096"
  delighted:
    description: advocacy language, unprompted praise, retelling
    example_quote: "They rebooked me before I reached the terminal."
    example_source: "SOC-402"

The rule that matters most is `explicit_evidence_only: true`. I do not allow a model to infer that someone must have felt abandoned because the queue was long. Maybe they were annoyed. Maybe they were resigned. Maybe they were furious. Maybe they were emotionally flat and pragmatically focused. If the quote does not carry valence, the field should be `null`, and the phase should aggregate only rows that genuinely express emotion.

This is how I avoid the sentiment smoothie. Models love to smooth ambiguity into plausible middles. That is lethal here. The real value of the emotional line is contrast. At Albatross the phase-level means came out as 2.2 for Pre-flight, 1.4 for At-airport, 2.2 for New arrangements, 1.6 for Rebook, and 1.8 for Recovery. That shape challenged executive folklore. The cancellation itself was not the deepest wound. Silence and contradiction at the airport were.

I also insist on calibration. A human-coded sample still matters. If an agent's scoring drifts wildly from the calibration set, I do not trust the emotional curve, however elegant the chart looks. The YAML's `calibration_sample_size` and `stddev_floor_per_phase` encode that discipline. The point is not mathematical fetishism. The point is to protect the map from dramatic flattening and theatrical exaggeration alike.

The journey map template keeps the sentiment line attached to supporting quotes for exactly this reason. If a stakeholder disputes the valley, I can point to the evidence rows, not my intuition. If they still disagree, that is useful. It means we should challenge the tagging or gather more evidence. What I do not do is redraw the curve to reduce discomfort in the room.

Emotion, Pain and Gain Registers

Emotion alone is too blunt. A strong journey map carries emotion, pain, and gain registers side by side. Emotion tells me how the service feels. Pain codes tell me what kind of breakdown is recurring. Gain codes tell me what actually restores confidence or saves effort. This layered view is what turns a map from empathy theater into a design instrument.

Pain codes are especially useful when the evidence corpus is large. At Albatross, the codes made the narrative operational. `INFO` captured notification lag and contradictory status. `REB` captured self-serve rebooking failure. `CARE` surfaced care bottlenecks such as hotel or meal support. `COMP` captured compensation friction. Because those codes sat on tagged evidence rows, the journey map could say more than "people were upset." It could show which class of failure dominated each stage.

The gain side matters too. I have seen too many maps dwell on pain until they become misery collages. The service still has bright spots. Relief can be operationally specific. A passenger gets a ranked rebooking offer before reaching the desk. A patient sees an acknowledgement instead of entering a phone chain. A retail customer watches the refund clock update instead of wondering whether money disappeared. Gains should be evidence-backed as rigorously as pains. Otherwise teams end up shipping delight fiction.

Because the artifact is typed, I can carry this layered reading into later work. Pain codes inform fail points in the blueprint. Gain codes inform moments worth protecting. Emotion tells me where a design move must be especially careful. None of these registers replace judgment. They simply keep my judgment connected to the evidence field.

The review path becomes important here. A Critic veto is about more than missing evidence. It can also challenge a misleading register assignment. If I tag a stage primarily as `REB` but the supporting evidence shows passengers are actually most distressed by contradictory information before they even reach rebooking, the map needs correction. That is why a good reviewer attacks classification as well as structure.

The runtime lifecycle helps me here. A failed write persists as draft with its acceptance failures attached. I can rewrite the same artifact in place via `artifactId`, strengthen the evidence, or remove an overreaching node. That means the map can improve without losing continuity. I keep one artifact history instead of a trail of disconnected poster versions.

maps/disruption-recovery/v1.0/
├── map.md
├── rows.csv
├── phases.yaml
├── emotion.yaml
├── traceability.csv
└── CHANGELOG.md

CI checks:
- every rows.csv row has the required evidence refs
- every quoted line grep-matches the corpus store verbatim
- emotion scores follow emotion.yaml rules
- no passenger-identifiable data appears in the artifact

That versioned layout matters more than it first appears. It lets workshops generate issues against rows instead of vague comments against a poster. It lets a map owner refresh the artifact quarterly instead of commissioning a re-map. It lets downstream blueprint work cite journey row IDs directly. In short, it turns the journey map into infrastructure.

Case: Albatross Airways

Albatross Airways is the cleanest argument I know for evidence-gated journey mapping. The airline already had a disruption poster from 2023. It had been built in two days, validated by nobody, and updated never. Meanwhile disruption days kept producing industrial-scale failure demand: 380 calls per 1,000 disrupted passengers into a 340-seat contact centre, post-disruption NPS at −34, and a compensation process everyone loved to blame because it was visible, measurable, and late in the journey.

The new programme ran for eight weeks. It assembled 140 passenger interviews, 9,000 disruption tickets, 1.1 million sessions across three disruption events, 45 staff debriefs, and 2,300 social posts. The aim was modest and ruthless: build a current-state map with evidence-per-row traceability, reach at least 90% agreement in an extraction audit sample, and hand a defensible journey artifact into blueprint work without losing the passenger view.

The biggest discovery came from the emotional line. Executives assumed the cancellation itself or the compensation tail would be the nadir. The map proved otherwise. The deepest trough was At-airport at 1.4, where app, gate board, and staff contradicted each other and passengers queued for roughly 90 minutes in an information blackout. Rebook was close behind at 1.6 because the self-serve engine failed on 66% of attempts and 41% of users defaulted to the phone queue. Recovery was miserable, but it was not the first wound.

That distinction changed the design conversation immediately. Once the map showed the true order of harm, the team could stop fetishizing the compensation form as the singular problem. The critical moves shifted toward earlier, more structural seams: a faster notification layer, synchronized disruption communications, ranked rebooking offers with soft holds, and a journey-to-blueprint traceability gate so every top-tier pain had a corresponding operational response.

The map's code form also changed the workshop mechanics. Three validation workshops involved thirty-four participants across gate operations, OCC, ground handling, contact centre, claims, digital, legal, and passenger advisers. Participants did not merely comment on the map. They opened row-level issues against it. Twenty-nine were merged. Twelve were parked because the evidence did not yet clear the bar. That is a healthier meeting. It rewards specificity.

By the handoff stage, the map had become the passenger-facing truth for the programme. The blueprint work had to answer journey row IDs rather than reinvent pain categories. That traceability check caught blueprint steps that solved vendor wish-list items but answered no journey pain, and it exposed at least one Tier-1 moment with no blueprint coverage. Again: the map did not design the service. It stopped the team from designing the wrong one.

The downstream impact is why this matters. In the illustrative pilot the redesigned recovery service improved self-serve rebooking from 34% to 78%, cut disruption-day calls by 62%, reduced median EU261 resolution from 63 days to 19 days, and lifted disruption NPS from −34 to −9. I would never attribute those gains to the journey map alone. That would be nonsense. But I will say the map changed the direction of effort. It revealed the seam that actually mattered.

If you carry this method into your own work, keep the bargain clear. Let transcripts and telemetry do the grounding. Let the journey spine stay outside-in. Let the emotional line earn its shape. Let the Critic be annoying. And keep the map alive in the same repository as its repair log and traceability table. A living journey map is not one that changes constantly. It is one that can be changed honestly, without pretending the evidence said more than it did.