A purchase sits in someone’s inbox for three days because nobody is sure who can approve it. A customer quote is sent without the right margin check. A job starts before a site assessment has been signed off. These are not usually people problems. They are signs that the process has outgrown informal communication. Knowing how to design approval workflows properly helps you keep decisions moving without losing control.
An approval workflow should do two things at once: make the right person accountable for a decision, and remove unnecessary waiting from everyone else’s work. Get the balance wrong and you either create risk or build a slow, frustrating chain of permission requests. The aim is not to put every action behind a gate. It is to apply control where it genuinely protects the business.
Start with the decision, not the software
Many businesses begin by looking for an approval tool. That is understandable, particularly when approvals currently happen through email, WhatsApp, spreadsheets and conversations in the corridor. But software cannot fix an unclear decision.
Start by defining exactly what needs approval. “Approve a purchase” is too broad. Is the decision about the amount, the supplier, the budget, the specification, or whether the purchase is needed at all? The answer may differ depending on the type of spend.
The same applies beyond purchasing. A sales discount, a variation on a project, a staff expense, a new customer account or a refund can all need approval for different reasons. Be precise about the business event that triggers the workflow and the decision that closes it.
A useful test is to ask: what could go wrong if this went ahead without review? If the answer is little more than “we like to know about it”, an approval may not be necessary. Visibility and approval are not the same thing. A manager may need a notification, report or audit trail without becoming a bottleneck.
Map the current process before improving it
Before changing anything, follow a real request from start to finish. Do not rely solely on the documented process, if there is one. Ask the people who raise requests, check them, approve them and carry out the resulting work. They will show you the workarounds that matter.
Map what happens now: who creates the request, what information is included, how it is checked, who decides, what happens when they are unavailable, and where the outcome is recorded. Also note the exceptions. They are often where the real operational risk sits.
For example, a team may say that all purchase orders need director approval. In practice, routine stock purchases may be approved by an operations manager, urgent repairs may be agreed by phone, and invoices sometimes arrive before a purchase order exists. A workflow designed around the stated rule rather than the working reality will be ignored or constantly bypassed.
This exercise usually identifies avoidable delays too. Perhaps finance has to rekey information from a request form into accounting software. Perhaps approvers receive incomplete requests and spend time asking basic questions. Perhaps staff do not know whether a request has been approved, so they chase people manually.
Set clear approval rules and limits
Good approval workflows are built on straightforward rules that staff can understand without needing a policy manual beside them. The rules should determine who approves, when an extra check is needed, and what happens if a request falls outside the usual pattern.
For most growing businesses, approval decisions are based on a combination of four factors:
- the financial value of the request
- the type of spend or business activity
- the department, project or cost centre involved
- the level of risk or contractual commitment
A simple spending limit is often a good starting point. A team manager may approve routine costs up to a set value, while larger spend goes to a director. However, value alone can be misleading. A modest purchase from a new supplier, a recurring software contract, or work that commits the business to a lengthy term may need more scrutiny than a higher-value routine order from an established supplier.
Avoid creating too many tiers. If every request passes through three or four people, staff will either wait too long or find a way around the process. In many cases, one informed approver is enough. Add a second approval only where it brings a distinct check, such as budget ownership, technical suitability or legal authority.
Give every stage an owner and a deadline
An approval workflow fails quickly when responsibility is shared vaguely. “The management team” cannot approve a request. A named role or person must be responsible at each stage, with a sensible substitute when they are away.
Set service expectations as well. Not every approval needs an answer within an hour, but no request should disappear into an inbox with no visibility. A routine request might be due within two working days, while an operational issue that could stop a job may need a same-day route.
Escalation should be practical rather than punitive. If an approver has not acted by the deadline, the system can remind them, then notify an alternative approver or manager. The objective is to stop work stalling, not to generate more messages.
It also helps to separate approval status clearly. “Submitted”, “under review”, “approved”, “rejected”, “sent back for more information” and “cancelled” all mean different things. If staff can only see a vague status such as “pending”, they will still spend time chasing updates.
Make requests complete before they reach an approver
Approvers should make decisions, not hunt for missing information. The request form or system should capture the details needed for that particular decision at the point it is raised.
For a purchase request, that may include supplier, amount, VAT treatment, reason for spend, budget code, quotation or supporting document, and required delivery date. For a sales discount, it may include the normal price, proposed price, margin impact and reason for the exception.
The right fields depend on the process. Asking for too much information on every request is just another form of administration. A better approach is conditional information: request additional detail only when the value, category or risk level calls for it.
This is where a tailored system can make a material difference. It can pull customer, supplier, project or budget information from the systems you already use, rather than asking staff to copy it into another spreadsheet. That improves the quality of the decision and reduces duplicate data entry.
Design the exception route deliberately
Every business has urgent cases, unusual requests and genuine commercial exceptions. Pretending they will not happen simply pushes them outside the system.
Build an exception route with clear boundaries. An emergency repair might be authorised verbally by a designated manager, provided it is logged in the system afterwards with a reason and supporting evidence. A request above the usual limit may need a director’s approval, but it should not have to restart from the beginning.
It is also worth deciding what happens when a request is rejected. A rejection without a reason teaches nobody anything and often leads to the same request being resubmitted. Require a short reason, then allow the requester to amend and resubmit where appropriate. That creates a usable record and reduces back-and-forth.
Connect approval to the work that follows
Approval is rarely the end of a process. Once a request is approved, somebody may need to raise a purchase order, issue a customer credit, schedule work, update a budget, create a project task or notify the requester.
If these next steps are still manual, the approval workflow may look tidy while the underlying administration remains slow. Design the hand-off from the outset. An approved request should trigger the right action, or at least create a clear task for the person responsible.
The same applies to finance and reporting. If approved costs are not connected to the relevant project, customer or cost centre, managers cannot see commitments before invoices arrive. A well-designed workflow gives the business a reliable record of what has been requested, approved, committed and spent.
Test with real examples, then review the evidence
Before rolling out a new workflow, test it against recent real requests. Include ordinary cases, high-value requests, urgent work, rejected requests and requests raised while an approver is unavailable. This quickly exposes rules that sound sensible on paper but do not work in practice.
Once live, review the data after a few weeks. Look for approval stages that regularly exceed their target, common reasons for rejection, requests that are frequently sent back, and categories that generate too many exceptions. These patterns tell you whether the issue is training, missing information, unclear authority or an overly complicated rule.
Do not treat the first version as fixed. Businesses change, people take on new responsibilities, and spending patterns move. A workflow should be stable enough to create consistency, but simple enough to adjust without turning every process change into a software project.
The best approval workflow is usually not the most elaborate one. It is the one people can follow without guessing, managers can trust without chasing, and the business can improve as it grows. Start with one process that causes real friction, make the decisions and ownership clear, then build from there.