In short
Approvals stall because they have no deadline, no default and often no single named approver. Fix all three: give each approval type a stated response window, a default that applies if the window passes, and one named person rather than a group. Then reduce the volume, because most approval queues contain decisions that should never have required approval at all. A threshold that lets 80% of requests proceed without a signature is usually worth more than any improvement in approver responsiveness.
Key takeaways
- An approval with no deadline is not a request, it is a wish. Give every type a stated window.
- Defaults do the heavy lifting: state what happens if nobody responds, and delay stops being free.
- Group approval means nobody is accountable for the delay. Name one person.
- Most approval queues are inflated by decisions that never needed approving. Raise the threshold.
- Approvals are where a fast process becomes a slow one, and they are invisible in every activity metric.
Why approvals stall, and why it is not laziness
Follow a late piece of work and you often find that most of the elapsed time was not spent working on it. It was spent waiting for someone to say yes. The instinctive explanation is that approvers are busy, which is true and unhelpful, because approvers are always going to be busy.
The structural explanation is more useful. An approval request arriving in an inbox has three properties that guarantee delay.
- It has no deadline. Nothing marks it as due, so it is compared against work that is.
- Delay costs the approver nothing. The cost lands on whoever is waiting, who is usually more junior and not in the room.
- Approving carries risk; waiting does not. A wrong yes is attributable. A slow yes is weather.
That third asymmetry is the one that keeps approval queues alive. Every incentive points towards deferral, and no amount of chasing changes an incentive.
Nobody defends a slow approval, because nobody is ever asked to. Delay has no author.
Give every approval a clock and a default
Two attributes convert an approval from an open request into a bounded one. They cost nothing to introduce and they do most of the available work.
A response window. Stated per approval type, not per request. Expense approvals get two working days. Creative sign-off gets three. Contract review gets five. The specific numbers matter far less than their existence, because a stated window creates a comparison the inbox previously lacked.
A default. What happens when the window passes. This is the part organisations flinch at and the part that does the work.
| Default | Appropriate when | Effect |
|---|---|---|
| Proceeds automatically | Low value, reversible, high volume | Silence stops blocking. Most requests never need the approver at all |
| Escalates to a named deputy | Material, but time-critical | Absence is covered without abandoning the check |
| Declines automatically | Irreversible or high consequence | Forces engagement, at the cost of some legitimate work being stopped |
The first row is the one worth arguing for. The objection is that things will slip through, and occasionally they will. The comparison is not against a perfect process, it is against the current one, in which requests sit for a week, people give up and proceed anyway without a record, or escalate socially to whoever is nearest. Automatic approval after a stated window is the same outcome with a timestamp and a rule.
- Decision default
- The stated outcome that takes effect when an approval window passes without a response. Its function is to make inaction a decision with a known consequence rather than an indefinite hold, which is the condition under which approval queues grow.
One name, not a group
Approvals addressed to a group are approvals addressed to nobody. Each recipient reasonably assumes another will handle it, and no individual is accountable for the delay because no individual was asked.
The fix is to name one approver per approval type, and to name a deputy who acts when the first is unavailable. If several perspectives are genuinely needed, keep one decider and list the others as consulted: they contribute, the named person decides. Consultation that requires unanimity is not consultation, it is a committee with extra steps.
This is the same machinery as assigning decision rights when handing work over, described in delegation without losing control. The organisational version, applied to recurring approval types, is in who owns what. Approval delay is very often an ownership problem that has been misdiagnosed as a responsiveness problem.
Reduce the volume before improving the speed
Before optimising how fast approvals are handled, ask how many should exist. Pull the last fifty approval requests of a given type and count the outcomes.
Approval rates are common on routine request types. An approval granted almost every time is not a control; it is a delay with a signature on it, and the sensible response is a threshold rather than a faster inbox.
Three moves reduce volume, in order of value:
- Raise the threshold. If everything under a certain value is approved anyway, stop requiring approval under that value. Sample the outcomes afterwards rather than checking each one in advance.
- Write the rule the approver is applying. Most approvers are running an unwritten checklist. Written down, someone closer to the work applies it, and the approver reviews exceptions only.
- Separate notification from approval. A large share of approval traffic exists because someone wants to know, not because they want to decide. Those should be notifications, which block nothing.
That last one is worth checking explicitly. Ask each approver, for each approval type, what they would do differently if they saw it after the fact rather than before. If the answer is nothing, the approval is a notification wearing a gate.
Give the approver what they need to decide
Some delay is caused by the request rather than the approver. A request that arrives without the information needed to decide produces a question, and a question restarts the clock, often at a cost of several days.
A well-formed request carries four things:
- What is being asked, in one sentence, with the number if there is one.
- What happens if it is approved, and what happens if it is not.
- The deadline and what it is tied to, so urgency is evidenced rather than asserted.
- A recommendation. The person requesting usually knows the right answer. Saying so converts the approver's task from analysis into agreement, which is dramatically faster.
Standardising this as a short template does more for approval speed in most businesses than any escalation policy, because it removes the round trip rather than accelerating it.
Measuring decision latency
Approval delay is invisible in almost every operational metric, because activity measures count work done rather than time spent waiting for permission. It needs its own number.
| Measure | How | What to watch |
|---|---|---|
| Decision latency | Time from request submitted to decision returned, by type | The spread, not the average. The tail is what breaks delivery dates |
| Approval rate | Share approved without change, by type | Anything above roughly 90% is a candidate for a threshold |
| Round trips | Requests needing a clarifying question before a decision | A request-format problem, not an approver problem |
Two or three weeks of crude data is enough. The usual finding is that one approval type accounts for most of the total waiting, which turns a vague sense that everything is slow into a single fixable thing.
It is also worth checking whether the approval queue is your actual constraint before investing here. If work waits three days for a decision and eleven days for capacity, the approval is not the problem, which is the discipline described in workflow bottlenecks. The Mayim Ops assessment separates decision delay from capacity delay for exactly this reason: they feel identical from inside the business and they have entirely different remedies.
Frequently asked questions
Why do approvals take so long?
Usually because the request has no deadline attached, no consequence for delay, and competes with everything else in an inbox that has no ordering rule. Adding a stated response window and a default that applies when it passes changes the cost of delay from zero to something, which is what actually moves the queue.
What is a default decision in an approval process?
A stated outcome that takes effect if nobody responds within the agreed window: the request proceeds, or it is declined, or it escalates. Defaults remove the situation where silence blocks work indefinitely, and they make the approver's inaction a decision rather than an absence of one.
Should approvals be done by a group or an individual?
An individual, almost always. Group approval spreads responsibility until nobody carries it, and adds the calendar problem of assembling several people. If more than one perspective is genuinely required, name one decider and list the others as people who must be consulted first.
How do you reduce the number of approvals needed?
Set thresholds so that routine cases proceed without a signature, and convert repeated judgement into written rules that someone closer to the work can apply. Most approval queues are dominated by requests that were approved every time, which means the approval was collecting information rather than making a decision.
How do you measure approval delay?
Record the time between a request being submitted and a decision being returned, by approval type, and look at the spread rather than the average. A median of a day with a tail of two weeks is a different problem from a consistent three days, and the tail is what damages delivery dates.