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 does it

Asking for information is one action from the triage step, and it moves the demand into Waiting on info — a real status in the lifecycle rather than a flag, so it appears as its own thing in the queue instead of as an item that has gone quiet.

The modal asks for the questions, who they went to, and a follow-up date that defaults to five business days out, skipping weekends. The date can be cleared only by explicitly ticking no follow-up needed — one of the two is required, so no waiting demand can exist without a follow-up rule. The questions are written to the activity feed, and the message you send is composed for you and copied in one click, so what the record holds and what the person receives are the same words.

When the answer arrives, information received routes by history: a demand that had already completed shaping returns to being decidable, while one that was still being shaped stays where it is and finishes through the normal shaping exit. A demand cannot claim to have been shaped just because someone replied to an email.

The wait is also visible as a wait — an overdue follow-up is flagged rather than left for someone to notice. 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 .