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
Reconcile Systems That Disagree
Design a repair loop you can preview before it runs and measure after.
Compute what the audience should be. Observe what it actually is in the other system. Close the gap.
That is the entire idea and it is genuinely simple. Everything hard about it is in the word close.
Repair only safe drift
Not every difference is a repair. Some differences exist because a person did something deliberately, and a reconciliation that flattens those is worse than one that never ran.
Which brings back the sentence from the previous guide, in its cross-system form: adding is permission, removing is safety. The loop adds people only to audiences it manages. It removes people from every audience, managed or not, because a suppression that respects ownership boundaries is not a suppression.
Make the diff legible before it runs
The best interface detail in this entire subject is one line of text: a pending-change summary broken into categories. How many to add, how many to remove, how many to force out, how many are blocked by a gate, and how many are unchanged.
Anyone can look at that line and see what the next cycle is about to do before it does it. And when the diff reads all zeros with a large unchanged count, the two systems agree exactly, which is a statement you can make with confidence rather than hope.
Pair it with a dry run: compute the whole diff and write nothing. Pillar 2 previewed one decision on one record. This previews a bulk operation across an audience, which is where the expensive mistakes actually live.
The other system's semantics are now your constraints
In a real sequencing tool, removing somebody from a cadence and re-adding them does not put them back where they were. It restarts them from the first step, wiping their progress.
So “removal is permanent per audience” is not a policy your team chose. It is a constraint imposed by the other system's behavior, and if you do not model it, your correct-looking repair destroys state you did not know existed. The reconciliation that looks like it is fixing drift is actually resetting hundreds of people to step one.
Every cross-system design has at least one of these. Find yours before it finds you.
A repair loop with a defect amplifies
A reconciliation loop does not fail quietly. It runs repeatedly, and each run acts on the state the previous run left. A defect in the convergence logic therefore does not produce one wrong result. It produces a growing one, and it grows on a schedule.
The tell is that a diff never reaches zero. It keeps having work to do, cycle after cycle, which looks like healthy activity and is actually a loop chasing its own tail.
So convergence has to be measured: the diff reaching zero and staying there, with no regrowth. Not inferred from the absence of complaints, which in this failure mode arrive long after the numbers do.
GTM Lab
Saved locallyCross-System Operating Plan · 0 of 8 sections started
Saved locally to your browser.
Dry-run the repair before you trust it
The diff above was computed and nothing was written. Read it before you decide anything: one of those five numbers is wrong in a way that matters.
Fixture: dry-run-diff
A pending change, computed and not applied
FIXTURE-DRY-RUN-DIFF- Add
- A small number, all newly qualified
- Remove
- A small number, all newly disqualified
- Force out
- Far larger than either, and unexplained
- Blocked
- A handful, each with a stated gate
- Unchanged
- The overwhelming majority, as expected