Ownable GTM Runbook

A tool isn't finished when it works. It's finished when someone who didn't build it can run it, watch it fail, fix it, and undo a bad write — without calling whoever wrote the workflow. This is the document that proves that's true. A section you can't fill honestly is telling you the tool isn't done, not that the section can be skipped.

One runbook per tool, living wherever the team already keeps its docs — never only in the builder's own notes.

What it does is not the same question as what it's for, answer both.

Three sentences, no more:

• What goes in: ____
• What comes out: ____
• Who looks at it, and how often: ____

Now the boundary — what it deliberately does not do carries as much information as what it does:

• Out of scope, on purpose: ____
• The thing people will eventually ask it to do, that it can't: ____

If you can't draw it in boxes and arrows, you don't understand it yet.

Plain text. Every box is a system a person can log into; every arrow is a direction data actually moves.

[Trigger]
    |
    v
[The tool — what it does to the data]
    |
    +--> [System it writes to #1]
    +--> [System it writes to #2]
    +--> [Alert, if any]

Draw the real one:

A rhythm longer than five steps means the tool needs fixing, not the doc.

Daily, or per run:

1. ---

2. ---

Weekly:

1. ---

2. ---

3. ---

If either list needs more than five lines, that's a signal about the tool's fragility, not an argument for a longer runbook.

Name what breaks it before something breaks it.

Things elsewhere in the stack that will silently break this tool, and how you'll know:

• A field, property, or column gets renamed: ____
• An API key, OAuth token, or webhook expires: ____
• Someone changes permissions on a source system: ____
• The upstream data changes shape (a new required field, a renamed status): ____

Every one of these should already have happened once, in testing, before this runbook gets handed over. If none of them has, the tool hasn't been tested — it's been demoed.

Every failure mode gets a row, or it isn't a failure mode yet, it's a surprise.

Fill this with real failures hit while building, not hypothetical ones. Three composite rows from a lead-routing tool show the shape — replace them with yours:

Symptom	Likely cause	Fix
Routed leads stop appearing in the sheet, no error anywhere	A CRM property was renamed; the field mapping now reads null	Re-map the property; re-run the last batch from the pre-write snapshot
The same alert posts twice in Slack	A retry ran without an idempotency key	Dedupe on the key; delete the second post; log that it happened
The nightly run silently skipped	OAuth token expired; the 401 was swallowed	Rotate the token; make a 401 page someone, not just log

A seat is not an owner, a name is.

Role	Name	Backup
Runs it day to day
Can change the logic
Gets called if it breaks in production

Pausing it safely beats fixing it live.

If you filled out the undo table on the Hack Design Canvas, copy it here — this is where it gets used, not where it gets rewritten.

• How to pause the whole thing, in one step: ____
• What not to do while it's paused (e.g. don't re-run the last batch, it will double-write): ____
• How to undo the last write, per system: ____
• Who gets told when it's paused: ____

The runbook isn't done until someone who didn't write it has run it.

Not "does the document exist." "Did a second person operate the tool from this page alone, once, while the person who built it watched and said nothing."

• A second person read this cold and ran the daily/per-run steps unaided.
• That person executed one "how do I change X" edit, and it worked.
• That person found and used the pause recipe, on a real or sandboxed run.
• Credentials are rotated to values the builder does not hold.
• The builder's access is removed, or downgraded to read-only.
• The named owner, from the table above, signed off in writing.

Handover isn't a document changing hands. It's a second person operating the tool while the first person sits in the room, silent.

Signed off by (owner): ____________ Date: ____________ Handed off by (builder): ____________ Date: ____________

Sheet: tab runbooks, one row per tool in production.

The runbook lives in the team's docs; this row is the index that tells you which tools have actually been handed over and which only have a document.

tool,owner_name,backup_name,handover_test_date,second_person_ran_it,pause_recipe_tested,credentials_rotated,open_failure_modes,last_reviewed

lead routing (composite),"(name)","(name)",2026-09-06,yes,yes,yes,1,2026-09-06

A tool with second_person_ran_it = no is not handed over, whatever the document says.