Why approvals stall, and what to fix before automating

Approvals stall because nobody can see where a request is or what rule decides it, not because the people approving are slow. A purchase request, a new-hire access form, a contract review or a policy exception usually waits in someone's inbox with no clock on it, no clear owner and no view for the person who asked. The fix starts with the process, not with a workflow tool, because automating an unclear approval only moves the wait somewhere harder to see.

The symptoms are familiar to any operations or IT leader. People send "just checking in" emails to find out where their request is. The same request goes back to the submitter two or three times for information that could have been asked for at the start. One approver becomes a bottleneck when they travel. Month-end or quarter-end turns into a chase. Nobody can say how long an approval normally takes, so nobody can say whether this one is late.

Most approvals stall for one of five reasons, and only one of them is that somebody is slow. The first is that the routing rule is unwritten. Who approves depends on the amount, the department, the vendor or the risk, but the rule lives in one person's head, so requests go to the wrong person first. The second is that the request arrives incomplete. The form, email or spreadsheet does not ask for what the approver needs, so the approver sends it back, and every return adds days. The third is that there are more approvers than the control requires. Sign-offs accumulate over the years as courtesy or as a reaction to a single past mistake, and they run one after another when several could run at the same time. The fourth is that nobody owns the process end to end. Each approver owns their step; nobody owns the time from request to decision. The fifth, and the least common, is capacity: the approver genuinely has too much to review.

Each cause has a different fix, and only some of those fixes involve technology. That is why the first step is to look at how the approval actually runs, not how the policy says it runs.

Walk three real requests from submission to decision and write down every hand-off, every wait and every time something went back for more information. Pick one that went smoothly, one that took far too long and one that was rejected. Use the timestamps already sitting in email, the ticketing system or the finance platform. The goal is not a perfect process map. It is a plain record of where time went, separated into time someone was working on the request and time it was waiting.

The pattern is usually obvious within a few requests. Waiting time dwarfs working time. The returns for missing information cluster around two or three fields. One approval step adds days and rarely changes the outcome.

Next, write the routing rule down. If the rule cannot be written as a short table of conditions and approvers, it cannot be automated, and it probably is not being applied consistently today either. Writing it down often surfaces disagreement between departments about who should approve what, and that disagreement is the real cause of the stall. Settle it with the people who own the control, not with the people configuring the tool.

Decide which approvals add control, and remove or change the ones that do not, before anything is configured. For each step, ask what risk it manages and what would happen if it were removed, raised to a higher threshold or run in parallel with another step. Some approvals exist because of an audit finding or a regulation and must stay. Others exist because it seemed polite. Keeping a control is a legitimate decision; keeping it by default is not.

Fix the front door next. Most returns for information can be prevented by asking for the right information when the request is made: the cost center, the business reason, the contract term, the data the access will reach. A structured intake form with required fields and simple validation removes a surprising share of the delay without changing a single approver.

Finally, give the process a clock and an owner. Agree how long each step should normally take, what happens when it takes longer, who is told and who can act. Name one person accountable for the end-to-end time, even if they approve nothing themselves.

Only now does technology earn its place. With a written rule, a clean intake and a clear expectation, a workflow tool can do the parts people do badly: route to the right approver the first time, send reminders without anyone having to chase, escalate when the clock runs out, show the requester exactly where their request sits, and keep an audit trail of who decided what and when. In many organizations that capability already exists in a platform they pay for, whether that is an enterprise service management platform, a CRM or the workflow features inside their productivity suite. The question is whether it is configured around the approval as it should run, or around the way it happened to run when the tool was installed.

Measure before and after, or the improvement is only an opinion. Three measures are enough for most approval processes: the time from request to decision, the share of requests sent back for more information, and the number of people who touch a request before it is decided. Capture them from the sample you walked at the start, and again after the change has been live for a month or two. If the numbers did not move, the problem was somewhere else, and it is better to know.

This is the shape of process before platform in practice. Assess how the approval runs today and where time goes. Architect the future process: the rule, the controls worth keeping, the intake, the clock and the owner, and only then the technology that will carry it. Implement it in the platform that fits, test it with the people who submit and approve, and stabilize it. Optimize it once real volume has run through, because the first version of any routing rule meets exceptions nobody predicted.

Two warnings from how these projects tend to go wrong. The first is automating the approval chain exactly as it exists. That produces a faster route to the same unnecessary sign-offs and a new system that now encodes them. The second is treating the tool's default workflow as the design. Default approval templates are a starting point, not an answer to how a particular organization manages risk.

An approval process that works is not just faster. Requesters stop chasing. Approvers see only what needs their judgment. Finance, audit and compliance get a record they can rely on. And leaders can finally answer a simple question: how long does it take us to say yes?

CnergyPro is a business process transformation, technology consulting and implementation company. CnergyPro starts with how an approval actually runs, fixes the process with the people who own it, then configures, integrates or builds the workflow that carries it, and stays connected through implementation and beyond go-live. If requests in your organization are waiting in inboxes, tell us what's not working.