Meridian Field Services: instructional example, not project evidence
One spine, two maps. The current state is evidence; the future state is measurable requirements. Per stage: what changes, the capability that delivers it (a label, not a blueprint), and the expected shift. Every delta traces to a pain; every target traces to a committed number. A to-be map that is the as-is with nicer emotions fails review.
Pair scope: PER-001 Dana[1] · a priority job arrives mid-morning · assigned inside a minute. JM-01 current, research-first (six interviews, two floor observations, June 2026 [6]); JM-02 future, pair JM-01, same four-stage spine, horizon: pilot through hub rollout, March 2027. Owner: D. Kaur; JM-01 validated July 10, 2026.
| Intake call | Find technician | Assign & confirm | Paper trail | |
|---|---|---|---|---|
| actions | Capture fault; promise a window | Radio poll; whiteboard check | Radio confirm; rekey into the scheduler | Log the choice from memory if challenged |
| thoughts | "Which crew is even close?" | "I'm guessing on positions" | "Did the rekey take?" | "Hope nobody asks why" |
| emotion (basis) | Strained (observed, both observations) | Low point (observed) | Relief with residue (inferred, basis stated) | Exposed (interviews 4, 6) |
| touchpoints | Phone · legacy scheduler | Radio · whiteboard | Radio · scheduler | Paper log |
| moment of truth | none | Customer on hold while Dana guesses, where windows are lost and the idle cost accrues (problem evidence[2]) | none | none |
| Intake call | Find technician | Assign & confirm | Paper trail | |
|---|---|---|---|---|
| what Dana does | The job lands on the board as the call ends | Reads three suggestions with visible reasons | One tap accepts, or a coded override | Nothing: the log wrote itself |
| delta: what changes · capability | No rekeying · board intake (feature inventory[3]); traces to pain 1 | Guessing becomes verifying · recommendations with reasons (FR-010, FR-011[4]); traces to pain 2 | Two systems become one action · acceptance + override capture (US-2, US-3[5]) | Memory becomes record · override log (US-3[5]); traces to pain 3 |
| expected shift | Strained → steady | The low point becomes the strong point: the customer stays on the line; the moment of truth inverts | Relief without residue | Exposed → covered |
| metric: one definition, baseline → target (owner P. Novak) | Job-visible latency: none (phone-relayed) → ≤5 s p95 (quality scenario[7]) | Time-to-assign: 8 to 15 min observed → <1 min (committed[3]) | Override rate: n/a → tracked, stable band (telemetry[5]) | Idle-time share: BRD baseline → ≤10% by Mar 31, 2027 (the committed number[2]) |
JM-01 current: the dip at "find technician" is the moment of truth failing.
JM-02 future, same stages: the dip becomes the plateau; the targets in the matrix say by how much and by when. Both arcs render from committed source.
Ordered is not linear. A branch, a rework loop and a cross-persona handoff all fit the pair discipline; each declares the mode it chose rather than being flattened into a straight line. The simple pair above and this one are the two ends of the range an intaker has to cover.
Pair scope: PER-001 Dana[1] · a callback raises a job's priority while a technician is already rolling to another · re-dispatch without breaking the committed window on either job. JM-06 current, research-first (four interviews plus one floor observation, June 2026 [6]); JM-07 future, pair JM-06, same five-stage spine, horizon: March 2027. Owner: D. Kaur.
| Callback lands | Assess in-flight state | Choose response | Secure acceptance | Settle both jobs | |
|---|---|---|---|---|---|
| actions (JM-06) | Take the callback; re-rank by hand | Radio the technician; guess an ETA | Weigh three options on the whiteboard | Radio the reassignment; absorb a decline | Rekey both jobs; call the bumped customer |
| thoughts | "What do I have to break?" | "Where is he actually?" | "Whichever I pick, someone waits" | "Now I start over" | "Hope nobody asks why" |
| emotion (basis) | Strained (observed) | Anxious (observed) | Torn (interviews 1, 4) | Low point: the decline loop bites (observed) | Exposed (interviews 4, 6) |
| touchpoints | Phone · legacy scheduler | Radio | Whiteboard | Radio | Scheduler · phone · paper log |
| delta: what changes · capability (JM-07) | No reconstruction from memory · board intake (feature inventory[3]); traces to pain 1 | Guessing becomes reading · position feed (FR-010[4]); traces to pain 2 | The branch stays; guessing between branches becomes comparing them · branch cost comparison (FR-011[4]); traces to pain 2 | The loop shrinks; a decline now carries a reason that feeds the next suggestion · acceptance + reason capture (US-2[5]) | Memory becomes record · override log + customer notice (US-3[5]); traces to pain 3 |
| metric: baseline → target (owner P. Novak) | Time-to-redispatch: 12 to 25 min observed → <3 min (experience constraints[3]) | Decline-and-retry rate: ~1 in 3 (interviews 1, 4) → ≤1 in 10; the loop is waste, so it is measured as waste | Bumped-window rate: BRD problem evidence → ≤2% by 31 Mar 2027 (success criteria[2]) | ||
| Outcome | Condition that selects it | Moment of truth (differs per outcome) | Delta in JM-07 |
|---|---|---|---|
| Reassign | The rolling job has not started | The first customer's window breaks, and Dana makes that call herself | The board prices the broken window before she chooses |
| Finish first | The rolling job is nearly done | The priority caller is told "within the hour"; the escalation bought nothing | Remaining-time is on screen, so "nearly done" stops being a guess |
| Split the crew | A two-technician job | Both clocks run while an exception waits for approval | Approval is requested in-flow with the cost attached → JM-09 (handoff, not a branch) |
JM-06 current: the low point is "secure acceptance", where the decline loop bites. The arc renders the dominant path: mermaid's journey notation has no way to say "one of these three", so the branch stays in the matrix where it is legible.
JM-07 future, same five stages: the loop's low point lifts. Same axis as JM-06 because the spine never changed: the branch is rows, the loop is an edge.
Maps without governance are cemeteries. The portfolio says which maps exist and why, who owns each, and how personas' journeys hand off to each other, so improving a shared touchpoint shows its cascade.
| Map | Persona × scenario | State | Pair | Owner | Status | Review |
|---|---|---|---|---|---|---|
| JM-01 | Dana × priority job | current | JM-02 | D. Kaur | validated | quarterly |
| JM-02 | Dana × priority job | future | JM-01 | D. Kaur | targets committed | quarterly; re-measure at cutover |
| JM-03 | Marcus × assignment day | current | JM-04 | D. Kaur | validated (4 ride-alongs) | quarterly |
| JM-04 | Marcus × assignment day | future | JM-03 | D. Kaur | targets committed | quarterly |
| JM-05 | Dana × feed-loss recovery | future | none (scoping note: the current analog, a radio blackout, differs structurally) | D. Kaur | assumptions open | per drill |
| JM-06 | Dana × escalation mid-flight | current | JM-07 | D. Kaur | validated | quarterly |
| JM-07 | Dana × escalation mid-flight | future | JM-06 | D. Kaur | targets committed | quarterly; re-measure at cutover |
| JM-08 | Priya × exception approval | current | JM-09 | D. Kaur | validated (2 interviews) | twice yearly |
| JM-09 | Priya × exception approval | future | JM-08 | D. Kaur | targets committed | twice yearly |
Wrong-tool omissions, recorded: Priya's weekly exception review has no inherent order (she enters it by exception type, by age, or wherever she left off) → the screen inventory owns it. Her in-flight approval is a different scenario and maps as JM-08/09: one persona can own both an ordered scenario and an orderless one, so the omission is recorded per scenario, never per persona. Warehouse flows are out of scope (PRD[3]). Portfolio review: with the monthly stakeholder refresh; post-cutover, JM-01/03/06/08 archive as baselines and the pairs re-measure apples to apples.
Omitted with rationale: dispatchers are trained staff on a managed rollout; no self-serve first-run exists. The cutover training plan owns the first-session experience (Pilot cutover plan[9]); activation is the pilot readiness gate, not a product journey. Recorded in the portfolio and in adaptation event #1.
The highest-stakes failure carries the map. The FRD's defined behavior is referenced, never re-specified; this map narrates how the failure feels and where trust is won or lost.
| Notice | Continue | Recover | |
|---|---|---|---|
| what happens | The board flags stale positions honestly | Assignment flow proceeds without proximity (degradation[4]) | Positions return; the flag clears |
| emotion (basis) | Alert, not alarmed (interview 2: "just tell me it's old") | Steady if informed ⚠ inferred; validation at the first feed drill | Restored |
| moment of truth | The honest flag: trust is won by the flag, lost by silent wrongness | none | none |
| recovery metric | Zero blocked assignments during loss; baseline n/a (new capability), target 0, owner K. Yamada (feed-loss scenario[7]) | ||
Opportunities: the staleness flag's copy → open question below · recovery telemetry on the pilot dashboard → US-3 Done addition[5].
| Question | Owner | Answer by | Blocks |
|---|---|---|---|
| Validate the "steady if informed" inference at the pilot's first feed drill | D. Kaur | Oct 16, 2026 | The staleness-flag copy only (ERR catalog copy[4]) |
| JM-02 assumption checks: feed availability, adoption, union scope | S. Grewal · M. Chen · N. Duval | Nov 2026 · pilot wks 1 to 4 · Aug 8 | None blocks design use of the pair |