Explaining decisions and designing review queues
How to show the evidence and rule behind a GTM recommendation, route ambiguous records to a useful review queue, and keep human judgment auditable.
On this page
A person reviewing a recommendation should be able to answer one question quickly: “What would I need to disagree with?” That requires a short explanation tied to the record, not a transcript of a model call.
The review view
| Section | Show | Why it is there |
|---|---|---|
| Result | Outcome, state, and version | Names exactly what happened |
| Deciding rule | The rule or evidence condition that determined it | Gives the reviewer a place to challenge |
| Evidence | Source, observed time, and kind | Separates fact from inference |
| Limits | Missing, prohibited, or conflicting evidence | Prevents false certainty |
| Next step | Allowed action, owner, and deadline | Makes review operational |
Do not make a reviewer reconstruct this from field history. Store the explanation beside the recommendation as a versioned result.
Queue design follows the failure
Use separate queues when the owner or remedy differs.
| Queue | Entry condition | Owner | First action |
|---|---|---|---|
| Missing evidence | Required input is absent | Data owner | Capture or repair the input |
| Rules gap | Inputs are present, outcomes do not resolve | Decision owner | Add a rule or approve an exception |
| Failed run | The decision did not complete | Operator | Retry safely and inspect the error |
| High consequence | The result would change an external or durable state | Business approver | Preview and approve the action |
One “AI review” queue is easy to build and hard to operate. It hides whether the system needs better data, a better contract, or a healthier job.
A compact explanation object
{
"outcome": "review",
"state": "needs-review",
"version": "routing-v1.4",
"deciding_rule": "stated-need-is-ambiguous",
"evidence": [{"field": "form_message", "kind": "observed", "source": "form", "observed_at": "2026-08-23"}],
"limits": ["company_employee_count missing"],
"next": {"queue": "rules-gap", "owner": "marketing-ops", "due_at": "2026-08-25"}
}The object is useful in a CRM property set, a custom object, or an external store. Keep the authoritative business fields separate from generated explanation text.
Review the queue as a system
Each review row needs a stable record link, an age, a reason code, an owner, and a permitted action. At review time, store the final decision separately from the recommendation. At operating review time, group outcomes by queue and reason code. A queue with many new-evidence items needs a trigger change. A queue with many rules-gap items needs contract work.
Give every queue a service contract
A queue is a workflow, even when the interface makes it look like a list. Define its entry condition, priority rule, owner, response target, allowed actions, exit states, and escalation path. Otherwise the system has only moved ambiguity from the model into a view.
| Queue field | Example |
|---|---|
| Entry | Required company match exists, but two authoritative sources disagree |
| Priority | Renewal within 90 days, then oldest first |
| Owner | Revenue Operations data steward |
| Response target | One business day |
| Allowed actions | Choose source, request evidence, defer with due date |
| Exit | Resolved, returned for evidence, accepted exception |
| Escalation | Decision owner after two business days |
Do not use “reviewed” as the only completion value. It says that somebody opened the row, not what they decided or whether the underlying record is now safe to use.
Write explanations for disagreement
An explanation is successful when a reviewer can disagree with one identifiable part. Prefer:
Keep and nurture. The company-size rule decided the outcome: 40 employees, observed from the enrichment provider nine days ago, below the approved threshold of 50. The submitted message was reviewed but did not change the hard rule.
Avoid:
Based on a holistic review of the available signals, this lead appears better suited for nurture at this time.
The second sounds polished but gives the reviewer no rule, source, observation time, or counterfactual. It cannot be tested and it encourages free-text overrides.
Test the review experience
Before launch, ask a reviewer to process examples with missing evidence, conflicting evidence, a clear rules gap, a failed run, and a high-consequence action. Observe whether the reviewer can identify the deciding rule, reach the source record, choose only permitted actions, and preserve a reason without asking the builder for help.
Then measure queue age, entries by reason, final outcomes, overrides by direction, and repeated records. A queue that keeps receiving the same case is not providing human judgment; it is compensating for a rule or data defect that should be fixed upstream.
Related: Evidence requirements and confidence, Decision ownership and override authority, and Override authority.
Related guides
FAQ
- What should a decision explanation contain?
- Show the outcome, version, deciding rule, evidence used, evidence that was unavailable or prohibited, confidence band, and the next allowed action. A list of every input is less useful than the one rule that changed the result.
- What belongs in a human review queue?
- A record belongs when the evidence is present and the rules do not resolve it, when a hard failure stopped the run, or when the consequence exceeds the permitted automation tier. Do not send every low-confidence record to the same queue.
Get the next guide
New guides and the occasional note on GTM tooling. Don't worry, I won't drop you into a three-month nurture.