Designing an Approval Workflow

Ask why an approval takes two weeks and you will usually be told the approvers are busy. Measure it and you find something different: the decision took four minutes, and it took nine days for anyone to look.

Which means most workflow design effort is spent on the wrong variable.

Count the approvers, then justify each one#

The commonest defect in an approval path is people in it who have no decision to make.

A reviewer who needs to know a document exists is not an approver. A stakeholder who wants visibility is not an approver. A manager included because their team is affected is not an approver unless they can reject.

Each of those belongs on a notification, not in the path. Every approver added extends elapsed time and diffuses accountability — when six people approved something, no one approved it.

The useful test for each name: what would they reject, and on what grounds? If there is no answer, they are a recipient.

Assign to roles, not people#

An approval step assigned to a named individual stalls when that individual is on leave, and the workaround is somebody with administrative rights reassigning it manually, which is neither logged well nor consistent.

Assign to a role — quality manager, financial controller, department head — so anyone holding it can act, and the audit trail records who did. This also survives reorganisation, which person-based routing does not.

Parallel by default#

If three approvers are assessing different aspects — commercial terms, legal risk, technical feasibility — routing them in sequence makes the total wait the sum of three independent delays for no benefit.

Sequence only where a genuine dependency exists: a budget holder who needs the technical estimate first, or a signatory who signs only after legal has cleared the terms. Everything else runs in parallel.

Escalation is the highest-return setting#

Two reminders and then escalation to a named alternative or the assignee's manager. Intervals set per document type, because an invoice approaching a payment discount deadline needs a tighter schedule than a policy review.

This is the change that produces the largest measurable improvement, and it addresses the actual cause — the interval before someone notices — rather than the imagined one.

A useful side effect: a report of steps that escalated is a diagnostic of the design. If a step escalates routinely, the assignment is wrong, the approver is overloaded, or the threshold is low enough to send trivial items to someone senior.

Thresholds keep the path proportionate#

Not every document needs the full path. A purchase requisition below a value threshold can be approved by one person; above it, two; above a higher figure, a committee.

Without thresholds, organisations choose between a heavy process applied to everything — which people then route around — and a light process applied to everything, which fails at the top end. Thresholds let the process be strict where it matters.

Rejection needs to be as designed as approval#

Most workflows are built around the approval path and treat rejection as an exit. Then a rejected document goes back to the author with a comment and no defined next state, and it either sits there or re-enters the process from the beginning with all previous approvals discarded.

Decide explicitly: does a rejection return to the author for revision and then resume at the rejecting step, or restart? Both are defensible; having no answer is not, and the choice should be recorded in the document control procedure rather than emerging from whatever the tool defaults to.

What to record#

Who was assigned, who acted, when, what they decided, and — where a change was requested — the reason. Reassignments and escalations logged with a reason, so the trail explains why an approval came from someone other than the original assignee.

That last detail is what an auditor asks about, and it is the one most configurations omit because it only matters retrospectively.

Measure two things#

Elapsed time per step, so you can see where items wait rather than where people are busy. And the escalation rate per step, which tells you where the design is wrong.

Both are more informative than an overall cycle time, because an average hides the one step that is costing the process a week.