The Decision Queue for a Busy Owner

Why this matters

Every shop has a queue of decisions waiting on the owner. In most shops it is invisible: it lives in six people's heads, in unanswered texts, and in the corner of a job that is quietly stalled while a tech works on something else. Invisible queues cannot be measured, cannot be prioritized, and get served by volume - whoever asks loudest and most often gets decided first, which is a ranking with no relationship to what the shop needs.

Making the queue visible is worth doing on its own. But the real payoff is what becomes obvious once you can see it: most of what is waiting on you does not need you, and you could not have known that while it was scattered across six heads.

The queue you cannot see is the expensive one

An invisible queue costs you in three ways that a visible one does not.

You cannot see depth or age. You know you are behind. You do not know whether five things are waiting or thirty, or whether the oldest has been sitting three days or three weeks. Both numbers change what you should do, and neither is available.

Askers escalate by repeating. With no queue, the only tool an asker has is to ask again, so your load rises with the delay. A twenty-item invisible queue does not generate twenty asks, it generates sixty, because two thirds of them are second and third attempts.

Nothing can be triaged. When a decision reaches you as a text at 4:40, you have no way of knowing whether it is the most urgent thing waiting. You answer it because it is in front of you. That is not prioritization, it is proximity.

One list, one intake, visible to the people who put things in it. The visibility to the askers matters as much as the visibility to you: an asker who can see their item on a list with a class and a date stops asking again.

What a queue item has to carry

Four fields. An item that does not carry all four goes back, and this is not bureaucracy - a partial item costs you the time to reconstruct the context, which is the largest part of handling it.

1. What is being decided, in one sentence, phrased as a question with a yes or no or a choice between named options. "Thoughts on the Miller job?" is not a decision item.
2. Who is blocked and on what. Named person, named work. If nobody is blocked, the item is not a decision, it is a topic, and topics belong in a different conversation.
3. What happens if this waits until a stated date. Forces the asker to actually establish urgency instead of asserting it. Most items turn out to cost nothing by waiting until the next decision block, and the asker discovers that while filling in the field.
4. The asker's recommendation. This is the load-bearing field and the one shops leave out.

The recommendation field changes the economics of the whole queue. An open question requires you to load the context, generate the options, and pick one. A recommendation requires you to check the reasoning and either approve or amend it. It is a fraction of the handling time, and it does something a fast answer never does: it makes the asker practice judgment on real cases while a backstop still exists. A shop where nobody ever recommends anything is a shop where nobody is learning to decide.

Expect the first two weeks of recommendations to be thin. That is not evidence the field does not work, it is evidence nobody has been asked to do it before.

The four service classes

Class the item at intake, by the asker, and let them be wrong at first.

Class 1 is deliberately narrow. Stopped means stopped, not waiting on a nice-to-have, and a live hazard is not a class at all - a suspected gas odor, water reaching live electrical, or an injury is handled the moment it is reported, with occupants out of the structure, no switches touched, no phone used inside, and the call made from outside. That never enters a queue.

Class 4 is the one that changes the shop. It inverts the default: instead of work waiting for your approval, work proceeds unless you object within a stated window. Set the window - 48 hours is a workable default for anything not time-critical - and hold it, because a class 4 item you answer on day four has taught everyone the window is fictional.

The uncomfortable part of class 4 is that some things will proceed that you would have decided differently. That is the design, not a defect. The question is whether the cost of those is smaller than the cost of everything waiting on you, and in most shops it is not close.

A queue that grew, and what was actually in it

A shop with six techs put a decision list on a whiteboard in the office. Week one it held 6 items and everyone was pleased with themselves. Eight weeks later it held 31 items and the oldest was 26 days old, which was worse than the invisible queue it replaced, because now everybody could see the owner was the reason nothing moved.

The diagnosis took ten minutes once he actually read the board. Every item on it was effectively class 3. There were no classes, so nothing had a deadline, nothing had a default, and the owner had been treating his weekly block as an obligation to review all 31 items in order, which he never finished, so the oldest items aged forever at the bottom.

He classed the 31 items:

Class 1 came back at zero, which makes sense: something genuinely blocking right now never made it to a whiteboard, it reached him by phone.

The 19 class 4 items went back to their askers with one instruction: state what you are going to do, and do it in 48 hours unless I say otherwise. He objected to 2 of the 19, about 11%. The other 17 proceeded without him, several of them decisions that had been sitting for over two weeks blocking real work.

That is the finding, and it is the reason to build the queue even if you never formalize the rest of it. Sixty-one percent of what was waiting on him did not need him, and the only way to learn that was to see the whole set at once. Item by item, over eight weeks, every one of those 19 had looked like something he should probably weigh in on.

Queue behavior afterward: depth settled between 4 and 7 items and the oldest item never passed 6 days across the following eight weeks. Depth stabilized not because he got faster but because class 4 items leave the queue whether he touches them or not, which is what stops a queue growing without bound.

The objection rate is your calibration signal

The number to watch on class 4 is not how many items you approve. It is how often you object.

Over a rolling sample of 20 class 4 items:

• Fewer than 2 objections in 20, under 10%: the class is too conservative. Those decisions do not need a default and an objection window, they need to leave the queue entirely and simply be that person's call. You are adding ceremony to decisions you never overturn.
• More than 5 objections in 20, over 25%: the defaults are being set without the context that would make them right. The fix is not to pull the decisions back. It is to write down the rule you keep applying when you object, because if you can object consistently there is a rule in your head that nobody else has been given.
• Between 2 and 5 in 20: working as intended.

In the shop above, 2 objections out of 19 is about 11%, which sits just above the 10% loosen-it line. Just above, not clearly inside the band - and the right response to a number sitting on a boundary in its first sample is to watch the next 20, not to restructure. A rule you override the first time it is close is not a rule, and a rule you act on before it has a full sample is not a measurement.

Converting repeats into rules

The queue's second job is to show you which decisions keep coming back. Any decision that recurs is a rule you have not written down.

The conversion rule: any decision type appearing 3 or more times in a rolling 4-week window gets converted into a written rule rather than answered a fourth time. Unit of analysis is occurrences of the same decision type per shop per 4-week window, counted from the queue itself rather than from memory. Step size: convert one decision type per week at most, because several new rules issued together all get tested at their edges in the same fortnight, every edge case escalates to you anyway, and you conclude that written rules do not work.

In the shop above, over the four weeks after reclassifying, "approve a part purchase above the standing limit" appeared 5 times. Five is at or above 3, so it converted: a written limit, a named exception path above it, and a monthly review of what went through. Over the next four weeks that decision type appeared in the queue zero times.

Note what the rule actually replaced. It was not the purchases. The purchases still happened. It replaced 5 occasions in 4 weeks of somebody stopping, writing an item, waiting, and him loading the context - which is the real cost of a decision that could have been a sentence on a card.

What the queue does not fix

It does not fix a bad decision block. If the block where class 3 items get worked keeps dying, the queue simply becomes a well-organized record of things that are not happening. Fix the block first; a sibling article covers how.

It does not fix decision quality. Where in your day you make heavy calls, and what happens to your judgment by late afternoon, is a separate problem with its own article. The queue affects what reaches you and when. It has nothing to say about whether you are sharp when it arrives, and an owner working the queue at the end of a long day gets a well-ordered set of decisions made badly.

It does not fix the owner who reopens things. A class 4 item that proceeds, and which you then relitigate afterward, costs more than if it had waited for you, and it teaches the shop that the objection window is theater. Objecting inside the window is the system working. Objecting after it closed is you overruling your own design, and after twice, nobody will trust a default again.

It does not survive a second intake. If items can also reach you by text, they will, because texting is easier than writing four fields. A queue with a bypass is not a queue. Redirect the text - "put it on the list with your recommendation and I will have it by tomorrow" - and mean it every single time for about a month, which is roughly how long it takes for the redirect to stop being needed.

References

• See related: Why the Owner Becomes the Bottleneck
• See related: Decision Fatigue: Why Late-Day Calls Go Wrong
• See related: Delegating the Decision, Not Just the Task
• See related: How to Protect Planning Time When the Phone Keeps Ringing
• Trade-standard practice for approval workflow design in small service businesses