The Hidden Queue: Why Routine Decisions Should Not Wait for the Next Meeting

Operational improvement often begins with a map of work. That is useful, but it can miss the space between tasks. In many UK service and operations teams, capacity is not lost only to the task itself; it is lost while a decision waits. A credit note sits in an inbox. A rota change waits for a weekly meeting. A supplier onboarding request moves between approvers, each assuming another person is responsible. The task may take ten minutes. The elapsed time can take ten days.

The waiting cost that does not appear on a capacity plan

Decision latency is the elapsed time between a decision being needed and a decision being made. Most teams measure activity, utilisation and output. Few measure waiting. Yet waiting is where ownership becomes unclear, meetings become queues, and managers become administrators of other people's indecision.

This matters for UK organisations managing change with finite capacity. Every day a routine decision waits, work is held open. Someone chases. Someone re-explains. Someone adds the item to another agenda. The cost is rarely dramatic enough to trigger a review, but it is persistent enough to slow delivery.

The problem is usually not that managers are lazy or indecisive. It is that the process has no default speed. Without a default, a decision waits until someone creates urgency.

Start with a decision-latency audit

A decision-latency audit does not need to be a research project. Choose ten routine decisions completed in the last month. For each, record the date the decision was requested, the named decision owner, the approvals required, the dates of any meetings where it was discussed, the date it was finally closed, and the reason for each wait.

Then compare elapsed time with active time. Active time is the work actually needed to reach a decision. Elapsed time is the full calendar period from request to closure. The gap is the latency.

Group the causes into four buckets:

• Unclear ownership: no single person is accountable for the decision.
• Layered approvals: multiple people are asked to confirm what one person could decide.
• Meeting dependency: the decision cannot move until a scheduled forum meets.
• Missing information: the request was incomplete, but no one named what was missing or by when.

Most teams find that two causes account for the majority of delay. That is good news. It means the fix can be targeted rather than sweeping.

Put a default clock on routine decisions

A 72-hour default works because it converts an open-ended wait into a managed commitment. It is not a target for every decision. It is a default for routine decisions: low value, reversible, within an agreed budget, and without regulatory, safety or significant reputational implications.

For those decisions, the named owner should do one of three things within 72 working hours: approve; decline with a reason; or escalate to a pre-agreed exception route. Silence is not approval. It is an escalation trigger.

The definition matters. State the clock in working hours. State when it pauses. If the owner needs information from the requester, the clock should pause only when the request is specific and recorded. Otherwise, waiting for information becomes a hiding place.

The default also changes behaviour. A named owner cannot hide behind a committee. A committee cannot become a storage unit for decisions that one person should make. Meetings remain useful for debate, trade-offs and complex judgement. They should not be the default mechanism for routine sign-off.

Design an exception route, not a permission maze

A 72-hour default only works if exceptions are clearly defined. Typical criteria include spend above a threshold, irreversible contractual commitment, cross-functional trade-off, regulatory or safety impact, or material reputational risk.

The exception route should have a named panel or senior owner and a short service-level agreement. The purpose is not to remove judgement. It is to reserve senior judgement for decisions that need it.

Two disciplines make this work. First, exceptions should be logged with the reason they were escalated. Second, the exception list should be reviewed quarterly. If the same type of decision is escalated repeatedly, either the threshold is wrong or the capability is missing. Both are useful findings.

Make the change visible in management routines

A new default will not survive if it lives only in a policy document. Managers need a simple monthly review. Track median elapsed time for routine decisions, the percentage closed within 72 hours, and the escalation rate.

Read the numbers carefully. A rising escalation rate may show that thresholds are too tight or that owners are avoiding judgement. A falling rate may show that decisions are being made too casually. Use the data to adjust the process, not to police individuals.

The most effective routine is often a short weekly review of decisions that are waiting. Not a status meeting. A queue review. Who owns it? What is the next action? When will it be closed? If the answer is not clear, the decision should be escalated or redefined.

A small design change with disproportionate impact

Decision latency is easy to tolerate because it is invisible on most dashboards. But in service and operations teams, it consumes capacity every day. A decision-latency audit makes the waiting visible. A 72-hour default gives routine decisions a speed. An exception route protects the decisions that genuinely need senior attention.

For leaders, the message is simple: if a decision is routine, it should not wait for the next meeting. If it is not routine, say so early and escalate it properly. That is not bureaucracy. It is operational discipline.