Waiting on information is a state, not silence

Go back through a year of intake and count how many requests were formally refused. It will be a small number — most teams decline almost nothing explicitly.

Then count how many stopped. That number is large, and nearly all of them stopped the same way: someone asked a reasonable clarifying question, and that was the last event in the record.

Nobody decided anything. The request simply ran out of momentum in a state that had no name.

Waiting and forgotten look identical

Open a queue and find an item last touched five weeks ago. Which is it: a request waiting on a legal opinion that genuinely takes six weeks, or one where a question was asked and nobody ever chased it?

You cannot tell, and that is the whole problem. Both render as an old item with no recent activity. The one that is progressing correctly and the one that has quietly died are indistinguishable from the outside, so the reasonable response — ignore old items, they are probably dead — is exactly wrong about half the time.

Which half gets lost is not random, either. The requests that need an answer from a busy senior person, an external vendor, or a legal team are the ones most likely to expire. Those are usually the consequential ones. An intake process without a named waiting state systematically loses its most important items and looks tidy while doing it.

Four things, or it is not a state

Calling something "blocked" is not enough. A blocked flag with no structure is just the item being old with extra styling. A waiting state earns its name when it carries four things.

• The question, as actually asked. Not "waiting on clarification" — the words that were sent. Otherwise, when the answer arrives three weeks later, nobody can tell whether it answered the question or a different one, and this is the most common way a wait produces nothing.
• Who was asked. A person. "Waiting on legal" means waiting on nobody, and a request waiting on nobody waits forever.
• Who owns the wait on your side. The asker is not automatically the chaser, and if that is unassigned then chasing is volunteer work, which means it does not happen.
• A follow-up date — or an explicit decision not to have one. The load-bearing part, discussed below.

The date, or an explicit decision to go without

A follow-up date is what converts a wait into something with an end. On that date one of three things is true: the answer arrived, or you chase, or you conclude that nobody is going to answer and decide without them — which is a legitimate outcome and frequently the correct one.

All three are progress. Silence is the only branch that is not, and silence is what you get by default.

The refinement that matters: allow "no follow-up needed" as an explicit choice, not as an empty field. Some waits genuinely have no date — the request depends on a vendor's roadmap, or on next year's budget cycle. Forcing an invented date there teaches everyone that the dates are fiction, and once that is learned, the real ones stop working too.

One of the two is required. What must not be possible is a waiting request where nobody ever answered the question and then what?

Make the asking easy or it will not be specific

There is a practical failure mode underneath all of this. The question gets asked in a chat message, in different words from what the record says, and now there are two versions of the question and the record's version is the one that never gets answered.

The fix is unglamorous: whatever the system records should be the same text the requester receives, and getting from one to the other should take a single action. If composing the message is separate work, people will improvise it in the channel they are already in — and they should, because that is faster. Meet them there instead of fighting it.

Arriving is an event too

The other end is neglected. An answer arrives and the request needs to re-enter the process at the right point — which is not always where it left.

A request that was already fully described before the question was asked goes back to being decidable. One that was still being worked out is not suddenly finished just because a question was answered; it returns to being worked out, with one more thing known. Treating those the same is how items skip a step and turn up at commitment with a gap nobody noticed, because the system recorded an answer arriving as though it were a stage being completed.

How DeliverySheet holds a wait

The product deliberately has no free-floating "waiting" status any more — an early version had one, and it taught us something: an open-ended wait with a question attached is usually a learning step wearing politer clothes. So the wait is held by the two states that carry rules. When the missing information needs real work to produce, the decision step routes the demand into a time-boxed discovery — the question, who is finding out, and the timebox are recorded, and the discovery ends with an explicit decision, not a silence.

When the demand simply is not ready to move and nobody is actively finding out, it is parked with a reason — a recorded decision that can name what would revive it, as legitimate an outcome as planning the work. Either way the four things this essay argues for survive: the question, the owner, the horizon, and a state someone can check. What no demand can do is sit in a queue looking active while quietly being forgotten.

Adjacent reading: why a no needs an owner and a reason , since the honest end of a long wait is often a decline, and why the record belongs on the work itself .