Approvals are the most commonly automated process in business, and among the most commonly automated badly. The technology is rarely the reason. Something that works perfectly in a demonstration falls apart in month two, and the reasons are almost always the same four.
Nobody wrote down what happens when someone says no
Every approval process gets designed around approval. The request goes up, someone agrees, the thing proceeds. That path gets tested thoroughly because it is the one everybody pictures.
Then a real rejection happens and nobody knows what the system should do. Does the requester find out, and how? Can they fix it and resubmit? Does resubmitting start a fresh request or continue the existing one? Is there a record of why it was refused, or just a status that changed?
Getting this wrong produces the worst outcome available: people stop using the system for anything contentious and handle it by phone instead, which means the system now contains only the easy cases and no longer reflects what is happening.
Rejection and return are not edge cases. They are half the process. Working through a claim and taking each branch makes this obvious faster than any description.
It routes to a person instead of a role
Requests over a threshold go to Margaret. Margaret is the finance manager and this is entirely sensible on the day it is built.
Then Margaret is on annual leave for two weeks, and eleven requests sit waiting with nobody aware. Or Margaret changes role and the requests keep arriving. Or Margaret leaves and the process is now broken in a way that takes a fortnight to notice.
Route to a role, and give the role a deputy. Then decide what happens when nobody acts at all, because an approval sitting untouched for a week is the most common real failure and it produces no error message.
The rule is more complicated than anyone admitted
“Anything over five hundred goes to finance” is the rule you are told. It is never the rule.
The actual rule has exceptions that live in people’s heads. Except for the regular supplier. Except when the client is being billed for it anyway. Except in December. Except when it is one of the three people who have always had a higher limit and nobody has written that down.
Automating the stated rule produces a system that is wrong in exactly the cases people care most about, and the loss of trust from that is very hard to recover.
The way to find the real rule is not to ask what the policy is. It is to look at the last thirty decisions and ask about every one that does not match. This is the single most valuable hour in the whole project.
It made life worse for the approver
Automation usually optimises for the person submitting, because they are the ones who complained. The approver was managing fine with email.
Now they get a notification that makes them log in, find the request, open something else to see the context they need, and come back to decide. Three minutes instead of thirty seconds, several times a day.
They will not say this. They will simply become slow, and everyone will conclude the approver is the bottleneck.
An approval should be decidable from the notification itself, with everything needed to decide already in front of them. If the approver has to go looking, the design has failed regardless of how good the rest is.
What good looks like
- Every branch does something visible. Approve, reject and return each produce a clear consequence and tell the requester.
- Roles, not names, with a deputy and an escalation when nothing happens.
- The real rule, including the exceptions, written down where a non-technical person can read and change it.
- Decidable in one place, without hunting for context.
- A history showing who decided what, when, and why.
None of that is technically demanding. All of it is decided before anything is built, which is why approval projects succeed or fail in the conversation rather than in the software. The list itself rarely needs anything exotic, and a SharePoint list holds most approval processes comfortably.
The honest summary
If the current process is a handful of requests a week that everyone is content with, automating it will not repay the effort. Annoying is not the same as expensive.
It becomes worth doing when things get lost, when nobody can say what was decided, or when the volume has outgrown anyone’s memory.
If you have a process where approvals go missing and you are not sure whether the problem is the process or the tooling, describe how a request travels today, including what happens when someone says no. That last part usually identifies the problem on its own.
Common questions
Why do approval systems get abandoned?
Usually because nobody designed what happens when someone says no. People stop using the system for anything contentious and handle it by phone, so it ends up holding only the easy cases.
What is the most common design mistake?
Routing to a person instead of a role. It works until they are on leave, change job or depart, and then requests sit untouched with no error and nobody aware.
How do we find the real approval rule?
Do not ask what the policy is. Look at the last thirty decisions and ask about every one that does not match. That hour is the most valuable in the project.