Route Ambiguous Cases for Review

GTM Lab builds a review queue. Everything uncertain goes into it, on the reasonable-sounding principle that a human should look at anything the system is not sure about. The queue receives about ninety items a day. One person owns it, alongside her actual job.

Week one, she clears it. Week two, she falls behind. Week three, she starts skimming, approving in batches by pattern rather than by case. Week five, she stops opening it, and nothing breaks, which is the worst possible outcome, because the queue is still in the architecture diagram and everybody believes uncertain cases are being reviewed.

A queue nobody can clear is worse than no queue

It is worse for one reason: it is invisible. A missing review step is a known gap. A bypassed review step is a gap everyone believes is covered, and it will be cited in the next design discussion as an existing control.

So the capacity question is not an operational detail to sort out later. It is a design constraint, and the queue has to be built backwards from it: how many items can the people who own this actually work per day, and what is worth their attention at that volume?

Narrow the triggers until the queue fits

The instinct is to route everything uncertain. The discipline is to route only what a human can actually resolve. Ask, for each candidate trigger, what a reviewer would do with it. If the answer is “look at it and mostly agree,” it should not be in the queue. If the answer is “check a specific thing the system cannot check,” it should.

GTM Lab narrows to three triggers. A conflict on the deciding field: two sources disagree about the thing the answer turned on, and a person can resolve it by checking which is right. An inferred value on the deciding field: the answer rests on an estimate rather than an observation, and a person can confirm or correct it. An irreversible action: regardless of confidence, anything ranked hard to undo stops for a person.

Notice what is not there. Merely low confidence is not a trigger on its own, because a reviewer looking at a low-confidence case with no specific thing to check has nothing to add. Volume drops from ninety a day to a handful, and each of the survivors has a question attached that the reviewer is uniquely able to answer.

Every queue needs an owner, a target, and an overflow rule

Three things, none optional. An owner who is accountable for the queue being clear, and whose manager knows it is part of their job. Not “the team.” A target stated as a time, not a size: every item reviewed within one business day. Time targets surface capacity problems; size targets hide them. An overflow rule for when the target is missed, decided in advance while everybody is calm. GTM Lab's rule: items past the target escalate to the decision owner and are counted, and the count is reviewed monthly, because a queue that overflows regularly is a triggering problem rather than a staffing problem.

The reviewer needs the same explanation the seller gets

A review interface that shows less than the explanation from Chapters 1 to 4 forces the reviewer to reconstruct the case, which is what makes reviewing slow, which is what makes queues get bypassed. The reviewer sees the outcome, the deciding rule, the counterfactual, all evidence with provenance, and specifically the item that triggered review, called out rather than left to be found. Their job should be to answer one question, not to audit the decision.

Carry this into your business

Find a review queue at your company and ask the person who owns it how long since it was empty. If the honest answer is months, the queue is not a control, and the routing rules are the thing to fix rather than the person.