Not every request should enter the process

Look at any intake queue that has been running for a year and roughly a third of it is unreadable. Not badly written — unreadable, in the sense that nobody can tell what was being asked for. "Reporting". "Fix the onboarding". "See attached email thread." Each one had a clear meaning in somebody's head on the day it was typed, and that meaning is gone.

The usual diagnosis is that people are careless about intake. The more useful one is that nothing ever asked them not to be.

The bar is one sentence wide

A request is routable when it says what needs to change, plus at least one of who is affected or why it matters now.

That is the whole bar. Not a template, not a form, not fifteen fields — one sentence that happens to contain two things instead of one. "Finance spends two days a month reconciling exports by hand" clears it. "Reporting" does not, and neither does "we need a reporting overhaul by Q3", which has urgency and no statement of what is wrong.

Note what the bar is not asking for. Not a solution, not an estimate, not a priority, not an owner, not a business case. Those all belong further down and all of them can be worked out later by someone other than the requester. What cannot be worked out later is what the person meant.

Why "what needs to change" and not "any two of three"

It is tempting to score the three parts and let any two through. That is wrong, and it is wrong in a specific way worth naming.

Impact and urgency without a stated need is the shape of every doomed project ever run: this affects the entire sales org and we need it before the conference. Enormous pressure, no statement of what should be different afterwards. That request is not more decidable than "SSO" — it is less, because it comes with a deadline attached to a void, and the deadline will survive the discovery that nobody knows what was wanted.

So the need is mandatory and the context is one-of-two. Asymmetric on purpose.

Ask at the door, because that is where it is cheapest

Every process that lacks an intake bar has a compensating step later — a refinement meeting, a triage call, a business analyst who chases people. That step is not free and it is not equivalent.

At the moment of typing, the requester has the whole context loaded. The cost of adding the missing clause is about eight seconds. A week later, recovering the same information costs a message, a wait, a reply that answers a slightly different question, and a follow-up — call it forty minutes spread over four days, and that is when the person still remembers. Sometimes they have left.

This is the entire argument for intake quality control, and it is an argument about when, not about rigour. The same question asked at two different moments differs in cost by two orders of magnitude.

The override is the part that fails

Nearly every team that adds a bar also adds an escape hatch. Submit anyway. Mark as exception. Skip for now.

It gets used, always, and the mechanism is not weak discipline. The person facing the bar is the single person in the organisation most convinced that their request is self-evident — they can see the thing they mean. The escape hatch is offered precisely to the one user guaranteed to take it.

Once it is taken a few times, the bar has taught everyone that it is advisory, and an advisory bar is worse than none: it costs a click and filters nothing, while creating the impression that intake is handled.

The way out is not moral pressure. It is to make the bar small enough that an override is not needed. If clearing it takes one clause, there is no legitimate case for skipping it — and the illegitimate cases are the ones you were trying to catch.

"Not routable yet" is a small claim

The objection to any bar is that it blocks people. Worth being precise about what is actually being blocked.

A request below the bar is not refused, not judged, not deprioritised, and not a comment on whether the underlying thing matters. It has been told one thing: it cannot yet be routed to anyone, because there is nothing in it that says who should look at it or what they would be looking at.

That is a far smaller claim than "no", and the wording matters. "Add one detail so this reaches the right person" is help. "Request rejected: 1 of 3 quality criteria unmet" is a different product with the same logic, and people route around the second one within a fortnight.

What to do when the assistant is not there

If an AI reads the incoming text and works out which parts are present, the interesting question is what happens when it fails — the API is down, the text is in a language it handles badly, the user submits before it has run.

The wrong answer is to fall through to free capture, because now the bar exists only when the weather is good, and the requests that arrive during an outage are exactly as unreadable as before. Worse, nothing marks them, so a year later you cannot tell which records were checked.

The right answer is that the fallback is manual: ask the two questions as plain fields, and record that they were answered by a person rather than verified by a reader. Same bar, different mechanism, and an honest note about which one was used.

How DeliverySheet does it

Capture assesses what you paste for three signals — the need, who is affected, and why now — and shows what is still missing as an action ("One detail still needed to route this correctly") rather than a score. The threshold to enter the lifecycle is exactly the one argued above: a need, plus impact or trigger. Not any two of three.

There is no capture-anyway button. An earlier version had one; it let low-signal text become a routable demand, and it was removed. The gate lives in the submit handler rather than in a disabled button, deliberately — a greyed-out button cannot explain itself, and clicking below the threshold should tell you what is missing and where to add it.

When the assessment fails or has nothing to ask, two plain fields appear instead and the demand is marked as having cleared the floor manually — user-attested rather than machine-read. And what you originally pasted is never rewritten: the clarifying answers are stored alongside it, so the record still shows exactly what arrived.

The next question is what to do with a request that clears the bar but is still only a subject — why "SSO" is a topic rather than a request .