Most approval processes begin with sensible intent.
Someone wants control over spend. Someone wants quality to stay high. Someone wants risk reviewed before a commitment is made.
That is reasonable.
Then the approval process grows.
A second person is added because they were missed once. A finance check appears because a supplier invoice caused pain. A senior leader wants visibility because a project went sideways. A message thread becomes the real escalation route because the formal workflow is too slow.
Before long, the business has an approval process that nobody would design on purpose.
Requests sit in queues. People chase decisions. Work waits for someone who is not sure why they are involved. Approvers ask for information that should have been collected earlier. Exceptions are handled manually. Urgent items bypass the process entirely.
The instinct is to add reminders.
Automated nudges. Escalation emails. AI summaries. More visibility.
Those can help, but they rarely fix the real issue.
A slow approval process is often a decision design problem.
The business has not made it clear who can decide, what evidence they need, what risk they are controlling, and which approvals are actually worth the delay they create.
Approval Is Not The Same As Control
This is where many businesses get stuck.
They treat approval as proof of control.
If three people sign off a request, it feels safer than one person signing it off. If a senior leader sees every exception, the business feels more protected.
Sometimes that is true. Often it is theatre.
Approval only creates control when the approver has a clear decision to make and the information needed to make it.
If the approver is only checking that someone else did the work properly, the process may be compensating for weak standards earlier in the workflow.
If the approver asks the same questions every time, the process is missing required evidence at the point of submission.
If the approver does not know what threshold would make them reject the request, the business has not defined the rule.
That is not a people problem. It is a process design problem.
The Queue Is Usually A Symptom
Approval queues make delay visible, but they are rarely the root cause.
When a queue builds up, the useful question is not just "who is slow?"
The better questions are:
- why does this item need approval at all?
- what risk is the approval meant to reduce?
- who is the lowest appropriate person to make this decision?
- what information should be available before it reaches them?
- which decisions can be handled by rules instead of judgement?
- what should happen when the request falls outside the rules?
Without those answers, the business ends up pushing every decision through the same narrow channel.
Small, low-risk decisions wait behind complex ones. Clear requests wait behind vague requests. Senior people become bottlenecks because the business has not delegated authority cleanly.
The queue looks like a capacity problem.
Underneath, it is often an authority and evidence problem.
Good Approval Design Separates Rules From Judgement
One of the simplest ways to improve approval work is to separate decisions that need judgement from decisions that only need rule checking.
Some requests should not need a person.
If spend is under a threshold, comes from an approved supplier, matches the budget, and includes the required detail, it can often move forward automatically.
If a customer discount is inside an agreed range and does not breach margin rules, the system can approve it or route it lightly.
Other decisions do need judgement.
Unusual risk. Strategic trade-offs. Commercial exceptions. Reputational exposure. Changes that affect another team.
Those should be reviewed properly.
The mistake is treating both types of decision the same way.
When everything needs approval, approval stops meaning much.
The approver becomes a human traffic light instead of a useful decision-maker.
AI Can Help, But It Should Not Be The First Design Step
There are useful places for AI in approval workflows.
It can summarise long requests. It can extract key facts from emails or documents. It can flag missing evidence. It can classify risk. It can compare a request against policy. It can detect repeated exceptions. It can draft a decision note for a human approver.
That is valuable when the underlying decision model is clear.
But AI cannot rescue an approval process where nobody knows what good looks like.
If the policy is vague, AI will interpret vagueness.
If authority is unclear, AI will route uncertainty.
If every exception is handled differently, AI will learn inconsistency.
The better order is plain:
Define the decision first.
Then decide where automation belongs.
The Fix Is Often Practical And Small
Approval processes do not always need a major systems project.
The useful work is usually more grounded:
- remove approvals that do not control a real risk
- set clear thresholds for spend, discounts, changes, and exceptions
- delegate authority to the lowest sensible level
- collect required evidence before a request enters the queue
- standardise the reasons an approval can be rejected
- route exceptions to the right person, not the most senior person
- review repeated exceptions and fix the upstream process
This is not about making the business reckless.
It is about reserving human attention for decisions that deserve it.
Strong approval design should make normal work move quickly and unusual work receive proper scrutiny. Most businesses have it the other way round.
That is expensive.
It slows delivery. It creates inconsistent decisions. It hides risk in informal channels. It teaches teams that the official process is something to work around.
Approval Should Be A Decision System
A good approval process is not just a queue.
It is a decision system.
It should be clear what decision is being made, who owns it, what evidence is required, what rules apply, what happens when the request is inside policy, and what happens when it is not.
Once that is clear, technology becomes much easier to choose.
You may need workflow automation. You may need a better integration between finance, CRM, and project systems. You may need a small internal tool. You may need AI to read messy inputs and prepare structured summaries.
The answer depends on the friction.
At Intelligent Marmalade, this is the kind of problem an operational review is designed to uncover. Not "where can we add AI?" as a generic question, but where work slows down, why it slows down, and what kind of fix would remove the drag without adding another layer of noise.
If approvals are constantly late, bypassed, or chased manually, the problem may not be that people need more reminders.
It may be that the business has not designed the decision properly.