Needs you: the question queue every platform gets wrong

I build software by running fleets of AI windows, and the same failure keeps turning up in every module I ship. A feature gets most of the way through a job and then stops, because it is missing one fact that only the customer can give. Who was this meeting with. Is this a receipt or a bill I owe. Which page should this post go to. At that moment the software has exactly three options: guess, stall, or ask. Most products do the first two, and they do them badly.

There is a right answer, and it is almost boring. You put the question in one list, a "Needs you" list, and you let the person drain it. I did not invent this. I went and read how 25 of the best business platforms handle a missing fact, QuickBooks, Stripe, Zendesk, GitHub, Mailchimp and twenty more, plus about forty years of research on when a machine should interrupt a person. They converge on the same handful of moves. The academics even have a name for the pattern: a human-in-the-loop clarification queue.

Then I built one. Within a single morning it did three things that every one of those platforms had taught me not to do, and we fixed all three by the end of that day. That day is the best argument I have for why each rule below is a rule and not a preference. Here is what the good platforms agree on, and here is where we got it wrong before we got it right.

One list, and one honest count

The strongest implementations all expose a single, countable list the user works down to zero. QuickBooks puts a "Needs Attention" widget on the home screen with a live count. Zendesk gives agents a view with a count badge and a Play mode that serves the next ticket the moment you finish one. GitHub collects every condition still blocking a merge into one box on the pull request. Different products, same shape: one place, one number, and the number drops the instant you resolve something.

The number is the whole game, and it is fragile. There is a long line of clinical research on alert fatigue showing that when a queue gets noisy, people stop reading it. Ancker and colleagues found a straight dose-response: the more alerts a system fires, the lower the rate at which people accept any of them. A count you cannot trust is worse than no count, because it trains the user to ignore the one that matters. So the rule is not "show a number." The rule is "show one honest number, from one source, that clears the moment the work is done." Hold that thought. We broke it later the same day.

Ask only when you are genuinely unsure, and never for what you already have

In 1999 Eric Horvitz wrote down the principle that governs all of this. A system should act on its own only when doing so clearly beats asking; otherwise it should defer, or ask. That one line draws the border between a good guess and a bad one. If you are confident, act and stay quiet. If you are not, ask. Do not split the difference by guessing and hoping.

There is a corollary almost nobody enforces: do not ask for something you already have. It sounds obvious. It is not. Our own queue, on day one, listed a company's legal name as a missing item the user needed to fill in, when the platform had already detected that name minutes earlier. A question about a fact you already hold is the same bug as a missing fact, pointed the other way. It inflates the count with noise and tells the user you were not paying attention. An auto-detected value has to count as filled, full stop.

Up to three sourced guesses, a box to type in, and never an invention

Where a platform can make a good guess, the mature ones show a short, sourced set of candidates and let you override every one. QuickBooks suggests a category and a matching transaction and shows you the rule or history it came from. Xero puts a running "Reconcile X items" count on each account and remembers which account you coded a payee to last time, so it pre-fills it. Google's own AI design guidance says the same thing in plain words: when the system is confident, suggest; keep the suggestion overridable; hand control back.

But a single suggestion is a trap. Accountants have a name for the Xero habit of clicking the one green match on autopilot, right amount, wrong contact. So the shape that holds up is: up to three guesses, each carrying the source it came from, and a box to type your own answer, always rendered last, always there. Zero guesses is fine too; sometimes the honest answer is "I have nothing, you tell me." What is never fine is a made-up guess. A fabricated email address looks exactly like a real one, and the system will cheerfully send mail to nobody. No source, no guess.

Resolve it inline, and put the user back where they were

The fastest queues resolve the item in place and keep you moving. Xero clears the line the moment you confirm the match and drops you onto the next one. Zendesk Play mode serves the next ticket automatically. The point is flow: you answer, it clears, you are already on the next thing.

The opposite of flow is friction, and friction kills a queue. A full page reload for a one-field answer. A link that dead-ends on a screen where you cannot actually do anything. A save that leaves you stranded, staring at a page with no way back to what you were doing. Our first build full-reloaded the entire page when you clicked to answer a single question, five to seven seconds for one field, and on some items it left you stranded after you saved. Both are the same mistake: treating a quick human answer as a heavyweight round trip instead of an inline moment.

Ask once. Remember. Learn.

The answer should become a rule. QuickBooks and Xero turn a one-time categorisation into a standing bank rule. Zendesk learns which macros you dismiss and stops suggesting them. The principle is simple and the research behind it, active learning, is just as simple: only ask for information you do not already have. If the user tells you once who a recurring contact is, you never ask again. A queue that forgets is a queue that asks "who is this accountant?" every single month, and that is how you teach someone to hate your product.

Decide block versus degrade, and let most things degrade

Here is the decision most software gets wrong. When a fact is missing, does the whole feature stop, or does it keep working with one thing degraded until you answer? The platforms that get this right reserve a hard block for genuine boundaries only. Stripe lets your account run, but if you miss a verification requirement past its deadline it disables payouts, and then charges; it even warns you about items that are "eventually due" before they bite. Mailchimp refuses to send a campaign until the physical mailing address the law requires is present. Those are real walls, and they should be walls.

Everything else should degrade. A draft waits instead of sending to the wrong person. A transaction sits uncategorised while the rest of the books stay usable. A post stays unpublished, not lost. Salesforce makes this an explicit choice on every duplicate rule: Block the save, or Allow it with an Alert and let the human proceed. That toggle is the right mental model. The default should be degrade. Reserve the block for the few places where proceeding would actually break something.

Surface it at a quiet moment, and do not interrupt

When you ask matters as much as whether you ask. The design principle is progressive disclosure: collect the missing fact at the point the feature actually needs it, not as a wall of setup fields up front. The interruption research says the rest: hold the question for a low-cost moment rather than firing it mid-task. So the question lands when the user next logs in, a natural, scheduled pause, and a single daily nudge is the most the system should ever send. Never a per-item ping. A queue that interrupts is just a louder version of the problem it was meant to solve.

The anti-patterns, including the three we shipped

Across the 25 platforms the failure modes repeat, and they are worth naming. Counts that inflate or disagree. Nags that never clear and become a permanent guilt-badge. Dead-end links. Over-blocking, where so many fields are marked required that people abandon the form. And the quiet, dangerous one: acting on silence. Google Business Profile will take a suggested edit to your listing and, if you do not respond within four days, publish it for you. Treating "no answer" as "yes" is how a change goes live that nobody approved.

Then there is the one I owe you, because it is ours. We built our own "Needs you" queue, and in a single morning it committed three of these at once. It full-reloaded the page for a one-field answer. It asked for a legal name we had already detected. It stranded the user after saving. And the counts disagreed, the banner said one, the row said three, because they were reading from two different places. There was more: a card that jumped back to a question you had just skipped, an input that only checked whether an email looked like an email after a four-second wait, and a context line that referred to a call with a payments provider that did not exist. Invented context is the same sin as an invented guess.

We fixed all of it the same day. The counts now move together. The skip wraps to the end instead of bouncing back. A value we already have counts as filled. The answer resolves in place and returns you where you were. And nothing the system shows you, not a guess, not the context line, exists unless it came from a real source. Every one of those fixes was just the inverse of a rule the good platforms had already taught.