Decision Card template for GTM systems

"Can we use AI to qualify our inbound?" contains no decision. It does not say what the possible answers are, who is accountable when one of them is wrong, what has to be true before an answer is allowed, what happens when the information is missing, or what the system may do once it has decided.

A Decision Card is the artifact that answers those before anything is built. It is one page, it covers exactly one decision, and its test is blunt: could two people implement this separately, without talking, and produce the same behavior?

The nine fields

One card, one decision

Most requests contain three decisions that look like one because they happen in the same ten seconds. Whether to route this person to a seller. What the first response should say. Whether this company is worth pursuing as an account.

Bundling them feels efficient and is the most common way a decision system becomes impossible to change. Six months later somebody wants to adjust a routing threshold and discovers the follow-up copy is wired to the same rule.

The fields people get wrong

Moment. Not "when it runs" but "when the answer has to exist by". If a conversion step can fire before the decision returns, the moment is what tells you a gate is needed. See risk tiers and automation eligibility.

Owner. The person whose judgment the definition encodes and who has authority to change it. Not the builder, not the operator. An owner who cannot change the rules has been assigned blame. See decision ownership and override authority.

Outcomes. Closed and mutually exclusive, and containing at least one honest non-answer. See outcome sets and unknown states.

A worked skeleton

decision: inbound-routing-v1
trigger: A person submits the demo request form
subject: The person record the submission creates or updates
question: Should we route this person to a seller now?
moment: Before the record converts
owner: Sales leader (can change the criteria)
reviewers: [marketing-operations, revenue-operations]  # consulted, do not decide
outcomes:
  - route-to-seller
  - keep-and-nurture        # real interest, not a fit: the middle category
  - not-a-prospect
  - unknown                 # evidence missing, decision ran correctly
  - review                  # evidence present, rules do not resolve it
evidence:
  required: [company-identity, stated-need]
  supporting: [company-size, industry]
  prohibited: [inferred-seniority-from-title-alone]
estimation:
  permitted: true
  must-record-basis: true
  may-write-to-observed-field: false
rules:
  - {order: 1, kind: hard, rule: matched-company-is-a-competitor, fails-to: not-a-prospect, stops: true}
  - {order: 2, kind: interpretive, rule: request-is-for-someone-this-product-serves, fails-to: not-a-prospect}
  - {order: 3, kind: hard, rule: company-size-above-threshold, fails-to: keep-and-nurture}
unknown-handling:
  timeout: 4 business hours
  default-outcome: review
  marks-as-defaulted: true
actions:
  route-to-seller:  {automatic: [assign-owner, notify], needs-human: [first-outreach], reversibility: reversible}
  not-a-prospect:   {automatic: [suppress-from-outbound], forbidden: [delete-record], reversibility: hard-to-reverse}

Separating hard rules from judgment

A hard rule is checkable and returns the same answer every time. An interpretive rule is a judgment where two competent people could differ.

Both belong on the card, labelled, in evaluation order. The order matters: a cheap numeric check placed before a qualitative disqualifier means a record that fails the qualitative test never reaches it. See deterministic rules versus AI judgment.

Where the card stops

The card says what the system may do, not how the work gets done. Turning an outcome into steps, owners, exits, and an SLA is a workflow specification, which is a separate artifact. See the GTM workflow specification template.

The interactive walkthrough that builds one of these section by section is Define the Decision Before You Automate It.