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
15 min · Interactive exercise
Capstone: Turn Qualification Into Follow-Through
Run four records through the whole specification, validate it, and approve version 1.0.
Each section was written while looking only at that section, which is how specifications get built and also how they end up contradicting themselves. This chapter finds out whether these seven do.
Three parts. First, four records go through the assembled specification. One is the clean path and proves the thing works. The other three are the three ways a working workflow quietly stops working: a reply nobody planned for, an owner who is not looking at their queue, and one human arriving twice under two record types. Each of those records fails visibly against a specification that skipped a section, which is the only way to find out whether a section is doing anything.
Second, eleven validation checks run by stable ID and report pass or fail with a reason. They deliberately test the seams. Does the completion definition measure the outcome Chapter 1 wrote, or does it measure steps running? Does every step that Chapter 3 marked as waiting on a person have a stall owner in Chapter 6? Does Chapter 5's re-entry rule contradict Chapter 2's excluded set? Every one of those is a contradiction between two chapters that were each correct when you wrote them.
Third, approval, which is gated on every check passing.
What approval is not
It is worth being clear about what you are signing. A specification does not make anything run, and it does not handle the edge cases you did not think of.
What it does is make the behavior arguable. When the workflow does something unexpected, the specification says which rule produced that behavior, and someone can disagree with the rule rather than with the workflow. And the edge cases you did not think of will now show up as a gap in a written document rather than as a surprise in production.
That is the part you cannot buy from a tool, and it is the part that survives changing tools.
GTM Lab
Saved locallyWorkflow Specification
sample-workflow-specification · v1 · draft
Run the four-record set
One record proves the specification works. The other three prove it survives the three ways a working workflow quietly stops working: a reply nobody planned for, an owner who is not looking, and one human arriving twice.
- Priya Shah · the clean pathChapters 1 to 3: the outcome, the trigger, and the steps with their owners.
Triggers on the decision, runs through five steps under two roles, and reaches a booked conversation. - Derek Chen · replies on day twoChapter 5: the exit set.
The reply ends the cadence and the owner takes over. With only the default exit, four more scheduled touches land on a live thread and the record is marked successful. - Leah Fenwick · the owner is not lookingChapter 6: the stall state.
Waiting on owner is named, the threshold is crossed, and the manager hears about it. Without a stall owner this record simply disappears. - One human, arriving twiceChapter 7: the duplicate rule.
The two records collapse to the most progressed one and the second trigger is recorded on it, rather than starting a second instance.
Run all 11 validation checks
The checks test the seams between sections, since every section was written while looking only at that section. Each runs by its stable ID and reports pass or fail with a reason.