gtmjosh
Define the Decision
Chapters
  1. 01 · Turn a Vague Request Into a Decision
  2. 02 · Name the Owner and Business Purpose
  3. 03 · Define the Allowed Outcomes
  4. 04 · Choose the Required Evidence
  5. 05 · Separate Hard Rules From Interpretation
  6. 06 · Add Unknown and Review Outcomes
  7. 07 · Decide What May Happen Next
  8. 08 · Capstone: Complete the Decision Card
Guide overview →

12 min · Interactive exercise

Chapter 7 of 80 complete

Decide What May Happen Next

Map each outcome to what the system may do about it, gated on risk rather than confidence.

GTM Lab's decision now works. It returns one of three outcomes, holds the uncertain ones, and records why.

Then the conversion automation, which has existed for two years and predates all of this, picks up Priya's record four seconds after the form submission and converts it. The decision is still running. By the time the answer arrives, the record has already moved, already been assigned, and already triggered a welcome email. The decision was correct and completely irrelevant. Nothing consumed it in time.

Deciding and acting are two different things

A Decision Card that stops at the answer is half a card. The other half says what the system is permitted to do with each answer, and the two must be written separately, because a good answer and permission to act on it are different questions. For each outcome, state what happens automatically, what happens only after a human confirms, and what must never happen.

Two rows are worth defending in particular: unknown and review. An unknown record must not get the handling of the outcome it superficially resembles, or unknown quietly becomes an outcome.

Risk tier, not confidence

The instinct is to gate automation on how sure the decision is. Confidence is the wrong variable to gate on by itself, and it is worth understanding why before the next guide introduces systems that produce confidence scores. Gate on how hard the action is to reverse.

Assigning a record to a seller is reversible in a click; the worst case is a wasted ten minutes. Enrolling someone in a marketing sequence is reversible but leaves a trace, because they received real emails. Disqualifying a record is reversible in principle and rarely in practice, because nobody goes looking through disqualified records. Sending an outbound sales email to somebody who asked not to be contacted is not reversible at all.

Rank the actions by that, and let automation eligibility follow the ranking. A high-confidence answer does not earn the right to take an irreversible action, and a low-confidence answer can safely take a trivially reversible one. This is also the honest answer to “should we let it run unsupervised?” The question is not how good the decision is. It is what the worst plausible mistake costs and whether you would find out.

The gate: nothing acts before the decision returns

The opening failure is fixed by a rule, and it belongs on the card rather than in the workflow:

A record that has triggered this decision is not eligible for conversion, assignment, or any sales sequence until the decision has returned an outcome.

That is the gate. It is what makes the decision load-bearing rather than advisory, and without it a fast automation will eventually race past every screen you build. The gate needs the escape hatch from Chapter 6 attached to it, or it becomes its own failure mode: if the decision never returns, the gate holds the record forever. Gate plus timeout plus defined default, together, or neither.

Every outcome is heard from; only one interrupts

The last piece is alerting, and there is a specific shape worth copying. Every outcome produces some signal. Nothing is silently swallowed, because a category that generates no evidence is a category nobody can audit, and not a prospect is exactly where a quiet, growing mistake would hide.

But only route to a seller interrupts a seller. The others go somewhere quieter, to the people who would want to spot a pattern: marketing operations gets the nurture and not-a-prospect volumes, the decision owner gets the unknowns and reviews. The distinction is between being recorded and demanding attention. Systems that alert on everything get muted, and a muted alert is worse than no alert, because everyone believes it is still working.

Carry this into your business

List the actions one of your automated decisions can take and sort them by how hard each is to undo. If anything near the irreversible end runs automatically, you have found the thing to fix first, regardless of how accurate the decision is.

GTM Lab

Saved locally
Decision Card · 0 of 8 sections started

Saved locally to your browser.

Decide what the system may do

The conversion automation picked up Priya four seconds after submission, while the decision was still running. The answer arrived correct and completely irrelevant.

Fixture: stranded-record

Submission whose decision never returned

FIXTURE-STRANDED-RECORD
Decision status
Triggered, never returned
Time waiting
Past the stated interval
Record state
Held by the execution gate
Anything failing
No, which is why nothing alerted
Resets every run.
Unknown and review are not answers about the record. What may the system do automatically for them?
What should decide whether an action is allowed to run automatically?
How do you stop the conversion automation acting before the decision returns?
Which outcomes should interrupt a human?
Chapter 7 of 80 complete