Chapters
- 01 · Map the Teams and Systems
- 02 · Define What Each Handoff Carries
- 03 · Track Waiting, Running, Completed, and Failed
- 04 · Handle Temporary and Permanent Failures
- 05 · Reconcile Systems That Disagree
- 06 · Notify and Escalate to the Right Owner
- 07 · Confirm the Business Outcome
- 08 · Capstone: Follow One Record End to End
16 min · Interactive exercise
Capstone: Follow One Record End to End
Trace one record across every boundary as the person on call, validate the plan, and approve version 1.0.
Every other capstone in this curriculum sits you at the drawing board. This one puts you on call, holding a record that has already gone wrong, because a cross-system plan is only ever really tested that way.
Part one is a trace. One record, followed across every system boundary on the map, showing at each crossing what was carried, what state it entered, and what happened when one of them failed. You are not the designer here. You are the person on call, following something that already happened, which is the only position from which you find out whether any of this was worth building.
One crossing in the trace failed and recovered, on purpose. Watch what it cost: nothing, and nobody was told, because the failure was classified transient and went back in the queue. That is the taxonomy and the state model doing their jobs rather than merely being configured.
Part two is thirteen validation checks, run by stable ID. Two of them read one chapter against another: whether every crossing carries all six contract elements, and whether every failure destination resolves to an owner who actually exists on the map. Neither is visible from inside the chapter that produced it.
Part three is approval, gated on every check passing.
What the plan does not promise
It does not keep the two systems in sync. No design does that, because drift is not the failure. Drift is the normal condition: both sides are being changed by people, continuously, and a plan that treats that as an exception will be surprised weekly.
What the plan buys is the ability to see how far apart the two systems are, decide what closing the gap should do, and watch it close. Without guessing at any step.
GTM Lab
Saved locallyCross-System Workflow Map and Operating Plan
sample-cross-system-operating-plan · v1 · draft
Follow one record end to end
Every other lab in this pillar put you at the drawing board. This one does not. You are the person on call, following something that already happened, and one of these crossings failed.
- The decision writes qualified to the person recordA new follow-through id, which becomes the correlation key for everything below
waiting - CRM to the enrichment providerCorrelation key, actor, idempotency rule, retry category
running - The provider times outClassified transient, returned to the queue with a retry count, no person told
running, then completed on the second attempt - CRM to the sequencing toolCorrelation key, the eligibility decision, the record owner the send derives from
completed - The reconciliation cycleA diff by category, computed and read before anything was written
converged, diff at zero - Sequencing tool to the reporting layerCorrelation key, progress, audit result
completed - The booked conversation is recordedThe business outcome, in a system on the map, countable against qualified requests
completed
Run all 13 validation checks
The checks test the seams between sections, since every section was written while looking only at that section. Two of them read one chapter against another: whether every crossing carries all six contract elements, and whether every failure destination is an owner who actually exists on the map.