Almost every company we meet already has an approval process. Somebody can recite it. What they do not have is a written version that survives the week the Executive Director travels, and that gap is where requests go to die.
Start from what already happens, not from what should
The instinct when documenting approvals is to design the correct process. Resist it. Write down what actually happens today, including the parts nobody is proud of: the requests that skip a stage because they are urgent, the manager who approves by voice note, the supplier who is paid before the paperwork catches up.
You cannot enforce a process you have not described, and you cannot describe one while you are also arguing about whether it is right. Separate the two. Describe first. Improve second.
Thresholds are the backbone
Nearly every workable chain is a set of amount bands. Under some figure, a supervisor closes it. Above that, the same request keeps travelling. The mistake is treating the bands as a formality rather than deciding them deliberately.
Two questions settle most of it:
- What is the largest amount a supervisor can approve without anyone else seeing it? If the honest answer is "it depends", the band is not set yet.
- At what point does the Managing Director need to see it personally? Set this too low and the MD becomes the bottleneck. Too high and the board asks why nobody was watching.
Rules that differ by site are normal, not a special case
A group running a property development, a workshop and a facilities arm does not have one approval process. It has three that look similar. A joint venture property may need the MD on every request regardless of amount, because a partner is watching. A workshop may need two vendor quotes over a quarter of a million naira because that is where the leakage was found.
Treat that as the normal case. A process that only works when every site is identical will be worked around within a month.
The deputy problem
This is what actually stalls chains. One person is out, and every request needing their signature waits. A written process that does not name a deputy for each approver is incomplete, however elegant the rest of it is.
For each stage, decide three things:
- Who signs when the usual approver is unavailable.
- How long a request may sit before it moves anyway.
- Whether the deputy's signature carries the same weight, or is provisional until the usual approver returns.
If you only fix one thing after reading this, fix the deputy rule. It costs an afternoon and it is the single most common reason approvals stop.
A return is not a rejection
Most requests that come back are not refused. They are missing a quote, or the wrong budget line, or a description nobody can act on. If your process has only approve and reject, those requests get rejected, and the person who raised them learns that the system is hostile.
Give the chain a third outcome that sends the request back with a reason attached, and keep the history. A returned request that comes back corrected should show both passes, not replace the first one.
Write down who may see what
Visibility is part of the approval design and it is usually left implicit. Can a site manager see spending on a site that is not theirs? Can a procurement officer see the price a staff member proposed, or only the vendor quotes they sourced themselves? These questions have answers in every company. They are rarely written down, which means they are answered differently by different people.
Then, and only then, put it in software
A chain that is written down, has thresholds, names deputies, allows returns and states who sees what is ready to be enforced. One that is not will simply be automated in its broken form, and everyone will blame the software.
This is why our own deployment starts with a mapping session rather than a login. The routing engine stores all of the above as settings rather than code, so the chain you wrote down is the chain that runs, and changing it later does not need a developer.
See it against your own approval chain
A forty minute walkthrough, configured live on the call. Bring the messiest process you have.
Book a demo