Approval Chain

An approval chain trades speed for control, and the trade is worth making only where the control is real.

The test for any step is whether the approver has information the previous one lacked, and whether they ever use it. An approver who has never rejected a request, and who could not say what would cause them to, is providing a signature rather than a control.

• Does this person know something the requester and previous approvers do not?
• Do they have authority to say no, and have they ever used it?
• Would removing them change any outcome, or only the timeline?
• Are they accountable for something the request affects, such as a budget or a risk?

Steps that fail all four are common, particularly in chains assembled by adding people who asked to be included. The cost is not just delay: a chain of nominal approvers dilutes responsibility, because each assumes the others are checking.

Approval chains grow in a predictable pattern, and almost never shrink.

Something goes wrong. An approval step is added so it cannot happen again. The circumstances that produced the incident pass, and the step remains, now applying to every request of that type indefinitely.

Repeated over a few years, this produces expense approvals with five steps, requisitions that take a fortnight to open, and leave requests routed through people who have no view on whether someone should take a holiday.

• Review chains periodically rather than only after an incident, since incidents only ever add.
• Set thresholds so small requests take a short path and only large ones take a long one.
• Record rejection rates per step, which identifies the steps doing nothing.
• Remove a step when adding one, as a discipline, unless there is a specific reason not to.

Thresholds are the highest-value change for most organisations. Routing a small expense claim through the same chain as a large capital request is not prudence, it is a failure to distinguish.

The single most common operational failure in approval chains is an approver being unavailable.

Someone is on leave, travelling, ill or has left the organisation, and requests queue behind them. In an unforgiving chain this stops leave approvals, expense payments and hiring, and the usual workaround is someone editing the request or approving in the system on their behalf, which defeats the control entirely.

• Build delegation into the chain rather than handling it as an exception, with a named alternate per approver.
• Make delegation time-bound and recorded, so who actually approved is answerable later.
• Handle departure explicitly, since a leaver's queue is invisible until someone chases.
• Set an escalation after a stated period, so a request cannot wait indefinitely on one person.

The second point matters for anything that might be examined later. An approval recorded against a person who was on leave that week is a problem, and it happens whenever delegation is done by sharing credentials.

Two routing logics coexist and are frequently confused.

Systems configured around one structure will route everything through it, which produces leave requests going to a budget holder who does not know the person, or expense claims going to a manager with no budget authority.

Where the cost centre and the reporting line differ, which is common, this is not a theoretical problem. It sends requests to people who cannot sensibly decide them and who approve anyway because refusing would be obstructive.

Most of the frustration attributed to approval chains is not the delay itself but not knowing where a request is.

A requester who can see that their claim is with a named person, submitted on a date, will usually wait. One who submitted it into silence will chase, often through several people, which consumes more time than the approval.

• Show the requester the current step and who holds it.
• Show the approver a queue rather than relying on email notifications, which are missed.
• Report age of pending requests by step, since that identifies the bottleneck rather than the general impression of slowness.
• Notify on approaching deadlines where the request has one, such as a leave date or a payroll cut-off.

The third is the diagnostic worth having. Chains are rarely uniformly slow; there is usually one step where everything accumulates, and it is often not the one people assume.