Support Overrides Without Erasing History

A GTM Lab reviewer disagrees with a classification. The system said keep and nurture; she knows the company, knows they are mid-acquisition and about to be much larger, and routes it to a seller. She is right, and the deal closes.

Six months later the team wants to know whether the qualification decision is any good. They pull every classification and compare it to what happened. This record shows “route to a seller,” which matches the outcome, so it counts as a correct answer.

The system got it wrong. A human corrected it. The measurement says the system was right, and every override in the population is doing the same thing, quietly inflating the accuracy of the thing the review process exists to catch.

The recommendation and the decision are two different facts

An override that replaces the recommendation destroys the only record of a disagreement, and disagreements are the highest-value data a decision system produces. Store both, always, as separate fields. Recommendation is what the system said, and it is never modified by a human. Ever. Decision is what is true after human review, and it may equal the recommendation or differ from it.

Everything downstream reads the decision. Everything measuring the system reads the recommendation. Neither can corrupt the other, and the gap between them is the thing worth watching: an override rate climbing in one segment is the clearest early signal you will get that a rule has drifted.

An override carries a reason, from a list

A free-text override reason is better than nothing and much worse than a short list. Free text cannot be counted. Twenty reviewers write forty phrasings of the same three reasons, and nobody can answer “why do we override this decision most often,” which is the question that improves the rules.

GTM Lab uses a small fixed list with an optional note: evidence on the record was wrong or stale; evidence the system could not see; the rule is wrong for this case; the rule is wrong generally. The last two look similar and are the important split. “Wrong for this case” is an exception. “Wrong generally” is a bug report from the person best placed to file one, and it should route to the decision owner rather than dying in a field.

Two retention policies, deliberately different

There is a distinction here worth being explicit about, because getting it wrong loses history silently. The current rationale is replaced on every run. It describes the latest answer, and stale rationale beside a fresh answer is actively misleading, so it should not survive. The history is append-only and never loses anything: every run, what it concluded, what the human decided, what changed since last time, and why.

Conflating them is how a review trail disappears: a system that overwrites its explanation each run has no memory, and the third time a record is reviewed nobody can see that it was already reviewed twice. The history entry is more readable when it marks what moved. Show every component every time, and flag only the ones that changed since the previous run.

Define What Your CRM Data Means built a conflict record with the same instinct: an approved decision, its reviewers, and what it replaced. This is that pattern applied per record rather than per definition.

Carry this into your business

Check whether an automated decision your team overrides keeps what it originally said. Most do not, which means their accuracy figures have been counting human corrections as machine successes for as long as anybody has been quoting them.