Approval bottlenecks: where the process really stops
Internal processes take a long time because work spends more time waiting for a decision than being executed. Approval bottlenecks rarely show up in a report: they live in the gap between one step and the next. To remove them, measure how long each item sits in the decision queue, redesign your approval thresholds, and make the exception rather than the rule travel up to the manager.
Why does the process take so long when everyone is busy?
Because cycle time and working time are different things. A purchase request that takes nine days to approve may have consumed forty minutes of real work. The rest is queue: the request waiting in the inbox of someone who was in a meeting, traveling, or simply carrying too many priorities.
Coordination numbers give the problem its scale. The Anatomy of Work Global Index 2023 from Asana, covering 9,615 professionals across six countries, shows that 58% of the working day goes to coordination: chasing status, answering messages about work, waiting for replies. Those same professionals estimate that better processes would give each of them 4.9 hours a week back.
The common reflex in the face of numbers like these is to automate the task. But the task is not the bottleneck. If an invoice is entered in two minutes and then waits three days for the manager's approval, automating the entry saves seconds and leaves the three days untouched.
What does the decision queue cost?
It costs hours from the people who decide, in measurable volume. In McKinsey's global research on decision making, covering more than 1,200 managers, respondents report spending an average of 37% of their working time making decisions. And 61% say most of that time is used ineffectively. Fewer than half agree that their own organization decides quickly.
The same study shows where structure weighs. In organizations with one to three hierarchical layers, 61% of respondents say decisions come out fast. At seven layers or more, that drops to 38%. Each additional level of approval is one more queue, and queues do not add up: they multiply, because each wait pushes the next one back.
There is also a cost that never reaches a spreadsheet. When every request travels up to the same person, the manager becomes the most contested resource in the operation and spends the day dispatching low-risk items. The decision that deserved attention gets the same hurried stamp as the other thirty that afternoon. The queue degrades both ends: it delays the trivial and trivialises the important.
How do you find the approval bottleneck in your operation?
By measuring waiting, not activity. The method fits in a week and needs no new tooling. Pick a process the operation experiences as slow — a purchase request, a commercial discount, a hire, a payment release. For every item passing through that process during the week, record two moments per approval step: when the item entered someone's queue and when that person gave a verdict.
With the data in hand, split total time into two columns: time when someone worked on the item, and time when the item waited. The result usually surprises anyone who has never measured it. Waiting dominates, and it concentrates in very few points, almost always one or two people through whom everything passes.
A hypothetical example at realistic scale helps. A mid-sized manufacturer measures its purchase requisition flow for two weeks. Average cycle time is nine working days. Broken down, the number tells a different story: forty minutes of real work between quotation and entry, and the rest waiting, concentrated in two signatures. The plant manager's takes a day. The finance director's, who approves every requisition above a threshold set years ago, takes up to six. The bottleneck is not the purchasing process. It is an approval threshold designed a decade earlier, when that amount was significant and the company ran a fifth of today's volume.
The pattern repeats because thresholds are rarely revisited. The company grows, item volume grows, and the limit that defined what deserves leadership's attention stays frozen. The result is a funnel that narrows every year without anyone having decided to narrow it.
How do you design thresholds that free the flow?
By pushing the decision down to the right level and letting it travel up only by exception. The McKinsey research cited above carries the central figure: organizations where decisions happen at the appropriate level — which in practice means delegating further down — are 6.8 times more likely to sit in the top-performing group for decision speed and quality.
The design has four components. First, thresholds by value and risk, revisited annually: what is routine and low-impact gets resolved at the edge, with a clear rule and a written limit. Second, approval by exception: the manager does not see the hundred requests that follow the rule, they see the four that break it. Third, a deadline with automatic escalation: an approval that does not come out in 24 or 48 hours travels up on its own to a defined substitute, because a queue without a deadline is an infinite queue. Fourth, an audit trail: every decision recorded with author, date and rationale, which protects both the person who delegated and the person who decided.
None of those four components is a tool. They are design decisions, which is why we keep telling clients that you do not have a technology problem, you have an architecture problem. Buying workflow software to automate the wrong threshold only produces waiting with notifications attached.
After the redesign, the system comes in, and it comes in well: routing each item by the rule, applying deadlines, escalating what went stale and recording the trail with no manual effort. That was the order in Repap On's document management system: first the design of the corporate document flow, then the platform that runs it. And it is what has kept UniTrust's brokerage system in production since 2022: the approval rules for policies and commissions live in the system and evolve with the operation, instead of living in one person's inbox.
Frequently asked questions
I can't see how to measure the result. What do I show leadership?
Cycle time before and after, on the same process. If a purchase request took nine days and now takes two, the gain is objective and nobody argues with the ruler. Complement it with manager time freed: hours per week that approval-by-exception returned to higher-value work. Two simple numbers, and both come out of the timestamps you already collected in the diagnostic.
Will the implementation take too much of the team's time?
The diagnostic takes a week of recording timestamps on a single process, with no new tooling. Redesigning thresholds is a management decision, made in one or two meetings with the people who operate and the people who approve. What consumes time is automating before redesigning, because then rework is guaranteed. In the right order, the change moves one flow at a time.
What if I change the thresholds and the bottleneck doesn't disappear?
It will migrate, and that is expected. With approval unblocked, the slow point becomes something else — perhaps data entry, perhaps delivery. Bottlenecks are not eliminated in one pass, they are chased in cycles: measure, unblock, measure again. What the redesign changes is where the waiting sits: it stops concentrating in decisions that never needed to travel up. And continuous measurement makes the next bottleneck appear as a number before it appears as a complaint.
The next step
If your operation feels like everything takes too long and nobody can say exactly where, the Operational Architecture Diagnostic is a 30-minute conversation to identify where your decision architecture is blocking the flow: book the conversation.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic