How to Design Approval Workflows That Do Not Slow the Business Down

Where does an approval actually cost you time?

Signing takes seconds. Waiting takes days. A purchase order sits because the request arrived without the quotation attached. A leave application waits because the only approver is on a site visit until Thursday. A refund waits because three people must each say yes and each is waiting for the one before. By the time the decision is made, the supplier has revised the price and the customer has written again.

• The request is unclear, so the approver asks a question and the clock restarts.
• The evidence is somewhere else: an email thread, a shared drive, someone’s phone.
• There is one approver and no backup, so travel and leave become business delays.
• No response time is agreed, so an approval is never late, only pending.
• The chain repeats the same check three times and adds nothing after the first.

The purpose of an approval is to prevent a mistake that would be expensive, public or hard to undo. Any approval that does not prevent such a mistake is a tax the business pays in waiting. Good design keeps the first kind and removes the second, and that judgement belongs to the people who own the process.

How do you set approval thresholds that match consequence?

Two questions decide the tier. What does a wrong decision cost, and how hard is it to undo? Money is only one measure of consequence. A commitment made to a customer, access granted to personal data, a public post or a change to a master record can matter more than the rupee value attached to them.

Write the thresholds in your own numbers, in rupees where money is involved, and put a review date on them. A limit agreed three years ago quietly becomes a bottleneck as prices rise, until half of ordinary purchases need a director. Review the thresholds twice a year with the finance owner and the process owner together.

Who approves when the approver is travelling?

The single most common cause of a stalled workflow is one person, unavailable. Factory visits, client meetings, medical leave and festival weeks are not exceptions; they are the calendar. Every approver needs a named backup, agreed in advance, not found in a panic on the day.

• Name a backup for every approval role, and let the backup see the same queue.
• Delegate with a limit and an expiry date, so temporary authority does not become permanent.
• Show the age of each item in the queue, oldest first, so nothing simply sinks.
• Record who actually approved, not the role that was supposed to.
• Tell the requester who holds it now, so chasing does not need a phone call.

What response time should an approval carry?

Give every tier a response expectation and an escalation route, both written down. Same working day for routine items, one working day for standard, two for consequential ones with a full evidence pack. State the working hours the clock runs in, so a Saturday evening request is not counted as late on Monday morning.

Then decide what happens when the time runs out. The item escalates to the backup, the requester is told, and the queue owner sees it. What should not happen is silent auto-approval of a consequential action, which converts a control into a delay followed by a rubber stamp. Automatic approval is only honest where the item was already inside agreed limits, and in that case it is not an approval at all: it is a rule with a log.

Can routine approvals be batched?

Yes, and it is usually the cheapest improvement available. Approvals interrupt. Eleven separate notifications through the day cost an approver more than eleven items reviewed together, and the eleventh gets less attention than the first. Fix two approval runs a day, morning and late afternoon, and let the queue fill between them.

• Group items of the same shape together: all purchase requisitions, then all leave requests.
• Approve by exception: the list is approved as a set, with anything unusual lifted out first.
• Never batch a restricted item, a new supplier or anything outside policy.
• Record each item separately, even when the decision was made in a batch.
• Keep a batch short enough to read properly. If it cannot be read, it is not being reviewed.

Batching works only when the system does the sorting: same type, same tier, checks already run, exceptions separated. A pile of dissimilar decisions produces exactly the tick-through the approval was meant to prevent.

What should an approver see before deciding?

The approval screen is a working surface, not a notification. Someone should be able to decide from it in under a minute, without opening three other systems. That means the request in one line, the amount and its budget position, the source document, the checks the system ran, and what it could not establish.

1. What is being asked for, in one line, with the requester and the date needed.
2. The amount, the budget or contract it sits against, and the tier it fell into.
3. The source document: the quotation, the invoice, the customer message, the specification.
4. What was checked automatically: duplicate, price against the last order, supplier status.
5. What could not be checked, named plainly, so silence is not read as approval.
6. The recommended action and its reason, with approve, edit, reject and a place to say why.

This is the shape of the approval gates in our Agentic Operations work: the system gathers context, prepares the action and holds consequential steps for a person. The reviewer’s side of the design is covered in Design the human decision into the workflow, which is worth reading alongside this article. The NIST AI Risk Management Framework makes the same expectation explicit for automated work: policies and procedures should define and differentiate roles and responsibilities for oversight, rather than leaving “someone will check it” as the plan.

Can approvals happen on a phone or on WhatsApp?

They can, and for owners who spend the week between sites they often should. The condition is that the chat is a doorway, not the record. The message carries a short summary and a link; the decision is written in the system, with the approver’s identity, the time, the version of the request they saw and any reason they gave.

• Confirm who is approving. A message from a phone is not, by itself, proof of identity.
• Show the amount and the key figures in the message, so nobody approves a subject line.
• Link to the full evidence rather than pasting documents into a chat.
• Keep personal and payment details out of the conversation.
• Write the decision to the system of record, and let the chat be a copy of it.

If those messages go through the WhatsApp Business Platform, the Business Messaging Policy applies to your use of WhatsApp Business Services. You may contact people only if they have given you their number and opted in, conversations you start use approved message templates, and you may reply without a template within 24 hours of the person’s last message. Check the current policy with your messaging provider before you build an approval flow on it.

How do you measure approval time and remove approvals that add no control?

Measure the queue, not the click. Time from request to decision, by tier. Time spent waiting versus time spent being worked on. Touches per request. The share approved without any change. The share rejected, and the reasons given. The share that escalated because nobody answered.

That is the test worth applying to every approval in the business: in the last three months, how many times did this step change an outcome? If the answer is never, replace it with a sample check after the fact and keep the log. Keep, too, a way to stop: the NIST framework asks for mechanisms, with assigned responsibilities, to supersede, disengage or deactivate a system whose behaviour is inconsistent with its intended use. For the permissions and logging side of the same design, see AI permissions, logs and approval gates.