Add Unknown and Review Outcomes

A request arrives with a free email address, a company name of “n/a,” and a two-word message.

The decision runs. Required evidence is missing and cannot be honestly estimated. So the implementation returns the safest-sounding answer available, which is not a prospect, and the record is disqualified.

A month later somebody notices that a meaningful share of disqualifications carry no evidence at all. They were not judged. They were defaulted, and the outcome set had no way to say so.

“We do not know” is an answer, not a failure

An outcome set that cannot express uncertainty forces every uncertain case into a confident answer, and the confident answer will be whichever one felt safest to whoever built it. This is worth being precise about, because three different situations get collapsed into one and they need different handling.

Unknown means the required evidence is not there. The decision ran correctly and cannot reach a normal outcome. The record is not disqualified and not routed; it is held, visibly, as undecided. Review means the evidence is present but the rules do not resolve it, or they resolve it in a way that is too consequential to act on unsupervised. A person decides. Error means the decision did not run. The service was down, the call timed out, something threw. This is not an outcome about the record at all, and treating it as one is how a system outage becomes a population of disqualified prospects.

The distinction between unknown and error matters most in reporting. Unknowns tell you your evidence requirements are too strict or your data collection has a gap. Errors tell you your system is broken. Merged into one bucket, they hide each other.

A blank is more honest than a number

There is a stronger version of this worth naming, because it generalizes past outcome sets. When a decision produces a score rather than a category, the temptation on an out-of-scope record is to return zero. Zero is not “not applicable.” Zero is the worst possible score, and every report, sort, and alert downstream will read it that way. A record that should not be scored yet needs to read as blank, and blank has to be a state the system distinguishes from both a low score and a missing calculation. The same instinct applies to categories: unknown must not be a synonym for the least attractive outcome.

Nothing gets stranded

There is one more state to handle, and it is the one that turns a good decision system into a support ticket: the decision never returns at all. The record sits in unknown forever. Nothing is wrong with it. Nothing alerts, because nothing failed. It is simply waiting for an answer that is not coming, and it will wait until a human happens to look.

The card needs a time-based escape hatch: after a stated interval with no answer, the record takes a defined default outcome, that outcome is marked as having been defaulted rather than decided, and somebody is told. Which default is a real choice with a real tradeoff, and it depends on which error is more expensive for this decision. GTM Lab defaults to review rather than to not a prospect, because a seller spending ten minutes on a request that turns out to be junk costs less than silently disqualifying a buyer.

Name the edge cases before they happen

The last section of this part of the card is a short list of specific situations, decided in advance, in writing. Internal test submissions are judged on their merits as though the test flag were not there, because otherwise the team's own testing quietly pollutes the record of how the decision performs. Partnership enquiries are keep and nurture when generic, and route to a seller only when they name a specific end client, because at that point there is a deal behind them. Records with no matched company at all are parked so that no downstream automation can pick them up and hand them to a seller by a route nobody intended.

Each of these will otherwise be decided by whoever hits it first, at speed, on a Friday.

Carry this into your business

Look at a decision your team runs and count how many of its outcomes are the pessimistic one. If that bucket is much larger than everyone expects, some of it is probably not a judgment at all. It is missing evidence and outages wearing the same label.