Manual approval delays: measure hidden wait time first

Where time disappears

Most delay does not happen while someone is working. It happens while nobody is touching the request.

A manager might spend six minutes approving a discount, a contract term, or a release change. On the calendar, that same approval can take two days because it sits in a queue, waits for context, or lands with the wrong person first.

One approval can stall several people at once. Sales cannot send the final proposal. Finance cannot confirm margin or invoice timing. Product cannot promise scope or dates. Engineering cannot start with confidence.

That is why approval delays feel bigger than they look. The action is short. The waiting around it stretches the whole path.

The useful comparison is active work time versus calendar time. A request might need 40 minutes of real effort across four people and still take four business days to finish. Each person does a quick check, passes it on, and then the request sits still until the next handoff.

Busy teams usually miss this idle time because everyone remembers being busy. The sales lead remembers drafting the deal. Finance remembers checking the numbers. Engineering remembers reviewing the impact. Nobody sees the full gap between those moments unless someone maps the request from start to finish.

Late decisions make the problem worse. If one approver asks a follow-up question at 4:45 p.m., the answer may not come back until the next morning. That small miss pushes the next review, then the next handoff, and a simple request loses another day.

Teams often blame headcount first. Sometimes they do need more people. Often they have too many pauses, unclear owners, and decisions that arrive after the workday has already moved on.

Oleg sees this pattern often in growing companies: people work hard, but the process still moves slowly because the waiting time hides between teams. If you want to fix workflow bottlenecks, start by measuring those quiet gaps. They usually cost more than the work itself.

What a wait state looks like

A wait state starts when someone finishes their part and cannot move until another person decides. The task is ready, but progress stops. That pause is where many approval delays hide.

It helps to split one approval into two clocks. Review time is the time a person spends actually checking the request. Queue time is everything before that, when the request just sits there. If a finance lead spends 10 minutes checking a discount but opens it the next morning, the 10 minutes and the overnight wait are different problems.

Most teams notice the review. The bigger cost usually sits in the queue.

The friction around the decision matters too. A reminder in chat, a forwarded email, a missing document, or a request that comes back for edits all add delay. Nobody plans for that time, but it still slows the work.

You can spot a wait state in a few common patterns:

• a ticket moves to "pending approval" and stays there
• someone sends follow-up messages asking for an update
• the request changes owners before anyone decides
• the approver sends it back for missing details
• one absent manager pauses the whole flow

The same pattern shows up across departments, even when the work looks different. In product, a designer finishes a mockup and waits two days for approval before research or development can continue. In sales, a rep has a ready quote but cannot send it until finance approves a custom price. In finance, an analyst prepares a payment or budget request, then waits for a department head to confirm the spend. In engineering, a developer finishes code, but release waits for product approval on scope or a security check.

In each case, the task itself did not stop the work. The need for a decision did.

If you measure wait states, count the whole path: queue time, review time, reminders, handoffs, and rework after feedback. That gives you a picture you can trust. Without that split, teams often hire for a workload problem when they really have a waiting problem.

Where approvals pile up

Approvals rarely fail in one dramatic spot. They pile up in small pauses that feel normal on their own. A product manager waits for scope confirmation, then for copy, then for release approval.

None of those pauses looks serious by itself. Together, they stretch a simple task across several days. That is how approval delays grow: not through one big block, but through a chain of small waits that nobody owns.

Product teams often feel this first. A feature may be built, but someone still needs to confirm the final scope. Marketing copy may sit in draft until one person reads it. A release can miss its window because the person who signs off is in meetings all afternoon.

Sales teams feel it differently. The rep moves fast, the buyer is ready, and then the deal stops for pricing, special terms, or discount approval. The pipeline still looks active, but the customer is now waiting on an internal decision. A slow approval can cool off a warm deal faster than most teams admit.

Finance often hides delay behind routine admin work. A purchase request waits for a manager. An invoice waits for a budget check or the right cost code. A software renewal sits in someone's inbox because nobody wants to approve a spend without one more review. People call this caution. Often, it is just queue time.

Engineering has its own approval traps. A developer needs access to a system, but security has to approve it first. A change is ready, but deployment needs a review from another team. A small bug fix can sit for a day because the person with release access is busy.

The biggest pileups happen between teams, not inside one team. Product waits on copy. Sales waits on finance. Engineering waits on security. Every handoff adds another queue, and each queue has its own pace, calendar, and rules.

If you want to find workflow bottlenecks, start where work crosses team boundaries. That is where a minor pause turns into missed launches, slower deals, late payments, and tired teams.

How to map the current path

Do not start with every approval in the company. Pick one request type that happens often and causes friction. A sales discount request, a vendor payment, a product change, or an engineering exception works well because each one crosses teams and leaves a trail.

Use one real request, not a hypothetical one. Follow it from the first ask to the final yes, no, or release. If a customer request starts in the CRM, moves to chat, then lands in a ticket, trace that exact path in order.

Write down every step, even the awkward ones people skip when they describe the process in meetings. You want the real route, not the clean version.

A simple map needs five things:

• who started the request
• who touched it next
• which tool held the request
• when it entered and left each step
• what blocked it from moving forward

This matters more than most teams expect. Delays often hide inside handoffs between tools, not inside the approval itself. A manager may approve something in two minutes, but the request might sit for nine hours in email before anyone sees it.

Mark every point where someone asked for missing details. If finance asked for a budget code, or engineering asked for clearer requirements, treat that as a separate step. Those moments reset the clock. They also tell you whether the real problem is approval or weak intake.

Pull timestamps from systems people already use instead of asking them to guess. Chat messages, ticket updates, email threads, CRM activity logs, and calendar invites usually give you enough to build the path. Memory sounds tidy, but it edits out delays.

Keep the first map plain. A table in a document or spreadsheet is enough. The goal is to see the route, the pauses, and the repeat loops.

After you finish one example, map three more of the same request type. If the path changes every time, that is still a useful result. It means the company does not have one process. It has a collection of habits, and those habits create the wait states people feel every week.

How to measure it step by step

Pick a short window and use only real requests. One week works for a busy team. One month gives a cleaner sample if approvals happen less often. Do not use estimates, and do not ask people to remember what happened. Pull dates from email, chat, ticketing, CRM, or accounting records.

For each request, write down four moments:

• when someone submitted it
• when the first reviewer opened or answered it
• when someone approved or rejected it
• when the work actually finished

That simple timeline shows where approval wait states sit. A request can move fast once work starts and still spend days untouched in an inbox.

Then split the timeline into active work time and waiting time. Active work is when someone is reading, checking, editing, or completing the request. Waiting time is everything in between. If finance spends 12 minutes checking a discount request but it sits for 19 hours before anyone sees it, the delay is not slow work. It is idle time.

Use the median delay for each step, not the average. One missed message or one approver on vacation can blow up the average and make the whole process look worse than it usually is. The median tells you what happens in a normal case.

Group the results a few ways. Separate product, sales, finance, and engineering, because each team handles different requests and follows different rules. Split by request type too: pricing exceptions, feature sign-off, vendor payment, access request. Then look at the approver. One person may clear requests in two hours while another takes two days.

A small spreadsheet is enough. Once you can see median wait by team, by request type, and by approver, workflow bottlenecks stop feeling abstract. You can tell whether the delay comes from too many handoffs, one overloaded manager, or a rule that sends simple requests through the same path as high-risk ones.

A simple example across four teams

A sales rep gets a message on Monday morning from a large prospect. They want a 15% discount on a one-year contract, and they want an answer before the week ends. The rep cannot say yes alone, so the request starts moving from team to team.

Sales spends about 10 minutes writing the request, adding deal size, contract length, and the prospect's deadline. Then it sits in a queue until the product manager reads it after lunch. That first pause already costs a few hours.

Product does not just look at price. The team checks what sales plans to promise. The prospect wants single sign-on, a custom export, and onboarding support in the first month. The product manager reviews the current plan and asks one question back: can engineering deliver the custom export this quarter? That question waits until the next day because the engineer who knows the release schedule is in meetings.

Finance steps in after product gives a partial answer. Finance checks margin, payment terms, and whether the discount still makes sense if the customer asks for net-60 payment. That review takes 15 minutes. The wait before it gets reviewed takes most of a day.

Engineering then confirms delivery risk. The feature is possible, but only after a release planned five weeks out. Each delay is small on its own. Together, they stack up fast:

• Sales request waits 4 hours before product reviews it.
• Product question waits 18 hours for engineering input.
• Finance review waits 6 hours in a queue.
• Engineering answer waits overnight for release confirmation.
• Sales needs half a day to update the proposal and book the next call.

Nobody worked on this request for very long. Total hands-on time is under an hour. Elapsed time is close to four days.

That is why approval delays are easy to miss. Teams see short tasks. The prospect feels silence. Leaders may think they need automation or another hire, when the bigger problem is often the wait states between those short tasks.

Mistakes that skew the numbers

Approval delays look smaller than they are when teams measure only the clean, finished cases. If you count only requests that reached a final yes, you miss the messy part: requests that sat in draft, got sent back, expired, or were dropped because nobody wanted to chase them again. Those cases still took time from product, sales, finance, or engineering.

Another common mistake is mixing urgent work with normal work. A same-day deal desk request or a production hotfix will jump the line. That is fine, but it distorts the average. If you blend rush items with standard requests, the numbers stop reflecting daily reality. Split them into separate groups and compare both.

Teams also blame the last approver too early. The CFO, head of engineering, or sales lead often looks slow because their name is on the final step. But the real delay may sit upstream in an unclear form, missing data, or a queue nobody owns. Approval wait states usually start before the named approver even sees the request.

A few habits cause most measurement errors:

• ignoring rejected, withdrawn, and stalled requests
• mixing rush work with normal work
• timing only the approval click, not the queue before it
• treating a policy rule as a software problem
• adding headcount before testing a smaller process change

The software mistake is expensive. If a company requires three signatures for a small refund, a new tool will not fix that rule. It may speed up notifications, but the policy still creates the wait. Process mapping helps you see whether the delay comes from the tool, the handoff, or the rule itself.

Hiring can hide the same problem. One extra coordinator may clear the queue for a month, then the queue grows back because the path is still cluttered. Test a smaller fix first: raise approval thresholds, remove duplicate sign-offs, add a backup approver, or require one clean intake form. Those changes are cheap, and they tell you whether you have a capacity problem or a design problem.

If the numbers still look bad after that, then software or hiring makes more sense.

Quick checks before you automate or hire

Approval delays often look like a staffing issue. Many times, the real problem is simpler: the request arrives missing facts, two people check the same thing, or nobody can see where it sits.

Before you add software or hire another reviewer, test the path with a few plain checks:

• Can one person approve routine cases?
• Do your forms collect the facts reviewers always ask for?
• Can everyone see the same request status in one place?
• Do simple requests still go through duplicate approvals?
• Does each step have a response time?

Small fixes here often beat both automation and hiring. Bad automation just locks in a bad path. Extra headcount can clear the queue for a week, then the same messy intake fills it again.

A simple example makes this obvious. Say sales offers a discount under 10%, product confirms the package, finance checks margin, and engineering reviews delivery impact. If the form already includes deal size, margin floor, package details, and delivery date, one manager might approve most of these in minutes. If the form skips half of that, four teams start asking the same questions, and the request sits between replies.

Good process mapping does not need fancy tools. Start with common requests, split low-risk work from unusual cases, and put a clear response time on each stop. Once those basics work, you can decide whether you need automation, another hire, or simply fewer approvals.

What to fix first and what to do next

Pick the step that is both slow and common. That is where approval delays usually cost the most. A contract review that adds two days to half your deals hurts more than a rare exception that adds five days once a month.

Start small. Remove one handoff or one approval level first, then watch what changes. If a sales manager always forwards the same discount request to finance, you may not need both checks for low-risk deals.

A good first test lasts two weeks. Keep it simple so the team will actually follow it:

• set a rule for small requests that can auto-pass
• use one shared template so people stop sending approvals back for missing details
• add a time limit, such as same-day response for routine items
• send requests to one owner instead of a chain of reviewers

After the test, compare four numbers: total wait time, rework, error rate, and number of requests finished. If wait time drops and errors stay flat, keep the change. If errors rise, tighten the rule instead of bringing back the old process all at once.

Then match the fix to the problem. If people wait because nobody knows what "good enough" looks like, change the policy. If reviewers keep asking for the same missing details, use a template or simple software. If the queue stays full even after you remove extra checks, you may need more staff.

Most teams buy software too early or hire too early. A cleaner rule often solves more than a new tool. Software helps when work is repetitive and easy to route. Hiring helps when judgment is hard to automate and demand stays high week after week.

If approvals cut across product, sales, finance, and engineering, an outside review can save a lot of trial and error. That is the kind of fractional CTO work Oleg Sotnikov does through oleg.is: map the real process, remove unnecessary waits, and add AI automation only where it actually helps.