Chapters
- 01 · Start With the Business Outcome
- 02 · Define the Trigger and Preconditions
- 03 · Map the Steps and Owners
- 04 · Design the Handoffs
- 05 · Add Exit and Suppression Rules
- 06 · Define Completion and SLA
- 07 · Prevent Duplicate Work
- 08 · Capstone: Turn Qualification Into Follow-Through
12 min · Interactive exercise
Design the Handoffs
Specify every boundary, including the one between this workflow and another that holds the same person.
A handoff is any point where the work changes hands. Between two roles, between a system and a person, or between this workflow and a different one that can hold the same human. The third kind is the one that gets missed, and it is the one that produces the strangest bugs.
Between workflows
Two workflows that can both contain the same person need a written rule about what happens at the seam. Without one you get the situation everyone has seen: somebody who asked to be called back next week is still receiving the cold outreach they were in, because nothing ever took them out of it. Two systems are both correct according to their own rules and the person on the other end is getting a company that appears not to talk to itself.
The rule that solves this is worth stating as a principle, because it is not obvious: priority is enforced by moving someone, not by writing a number.
The instinct is to add a priority field. Warm is higher priority than cold, so set priority to high and let the systems sort it out. They will not sort it out, because the cold workflow does not read that field and has no reason to. A priority nothing enforces is a note.
What works is exclusivity through movement. The person leaves the cold workflow and enters the warm one. There is exactly one active workflow holding them, and the seam is specified: already in the cold sequence means quietly finished there, and started fresh here.
Publishing the latency
The last piece of a handoff specification is how long it takes, said out loud.
Most cross-boundary handoffs run on a clock rather than on the event. A reconciliation runs on a fixed cadence, a sync runs on an interval, a queue drains when someone opens it. So the change is not instant, and the gap between the human action and the visible result is real.
Write it into the specification and tell the people affected. The good documentation for this kind of system says something like: the switch is not instant, it lands on the next cycle, and if you need something to go out the same day, plan around it. An undocumented delay gets reported as a bug, and the support cost of that, repeated across a team, comfortably exceeds the cost of writing one sentence.
GTM Lab
Saved locallyWorkflow Specification · 0 of 8 sections started
Saved locally to your browser.
Specify the seam
Two workflows hold the same person. Both are behaving exactly as designed. Write the rule that decides what happens where they meet.
Fixture: two-workflows
One person, two workflows, both correct
FIXTURE-TWO-WORKFLOWS- Workflow A
- Cold outreach, still running, still sending
- Workflow B
- Callback commitment, just started
- Priority field
- Set to high
- Systems that read the priority field
- None
- What the person receives
- Both, saying different things
Most handoffs run on a clock rather than on the event, so the change is not instant.
The latency is written into the specification and told to the people affected: it lands on the next cycle, so plan around it if you need something out the same day.
An undocumented delay gets reported as a bug. The support cost of that, repeated across a team, comfortably exceeds the cost of one sentence.