Designing approval workflows that people don't route around

Somebody in your company is waiting for an approval right now. The request is three messages up in somebody else's WhatsApp, beneath a birthday wish and a forwarded video. Nobody is chasing it because chasing feels rude, and in four days the person who asked will quietly proceed without the approval, because the work could not wait. Every business runs on approvals; very few run them through anything designed for the job.

Why chat approvals fail (it is not laziness)

Approvals in WhatsApp or email fail for structural reasons, not human ones. A chat message has no state: nothing distinguishes a pending request from an approved one except memory. It has no owner: a message sent to a group is everyone's job, which means nobody's. It has no deadline: nothing escalates when it sits. And it leaves no record: six months later, nobody can prove who approved the expense, the overtime, or the design change. People are not routing around your process because they are careless; they are compensating for a process that has no machinery.

The anatomy of a real approval workflow

Request means a structured form, not free text: what is being asked, how much it costs, why, and by when. Structure at the front is what makes every later stage automatic. Validation catches the incomplete and the out-of-policy before a human spends attention on it; a request missing its amount should bounce instantly, not sit in a queue for two days first. Routing is the heart, and it deserves its own section below. Decision is a button, with the whole context on one screen so the approver never has to go digging. Record writes who decided what, when, with what information in front of them. And notification closes the loop: the requester, the next approver, and anyone affected hear immediately, without anyone chasing.

Routing: by rule, never by guess

The question "who approves this?" must have a mechanical answer. The three rules that cover almost everything: by threshold (below ₹50,000 the team lead approves, above it the director; amounts make chains self-selecting), by category (IT purchases route to IT, travel to admin, hiring to HR), and by chain of command (the request climbs the real org chart, as in the crew-to-superintendent flow we built for DefectLog). If your team cannot state the routing rule out loud today, that is the first problem to solve, and it is a process conversation, not a software one. Software can only enforce a rule that exists.

Escalation and delegation: the vacation test

Here is the test that kills most approval systems: what happens when the approver is on leave? If the answer is "everything waits," people will route around the system within a week, and they will be right to. Two mechanisms fix it. Escalation: a request unanswered for a defined time moves up, visibly, so sitting on approvals has a cost to the sitter rather than the requester. Delegation: an approver can hand their authority to a named person for a date range, and the system records that the delegate decided. Neither is an advanced feature. They are the difference between a workflow and a bottleneck with a login page.

A workflow that cannot survive one approver's vacation is not a workflow. It is a bottleneck with a login page.

Rejection is a first-class outcome

Systems designed by optimists treat rejection as an afterthought, and it shows: a rejected request just disappears. The requester learns nothing, resubmits nothing, and trusts the system less. Design rejection with the same care as approval: it returns to the requester with a reason, the reason is recorded, and resubmission is one click with the original content pre-filled. In every deployment we have done, this single design choice does more for adoption than any dashboard, because it tells requesters their input goes somewhere even when the answer is no.

The four standard patterns

• Single approver. One person decides. Right for low-stakes, high-volume requests. Keep it fast: one screen, one button.
• Sequential chain. A approves, then B, then C. Right when each level genuinely adds scrutiny. Wrong when the middle layers are rubber stamps; every rubber stamp is a day of latency purchased for nothing.
• Parallel with quorum. Several people can approve; the first response (or any two, or a majority) decides. Right for time-sensitive requests where availability matters more than hierarchy.
• Threshold-tiered. The route depends on the size of the ask. Small amounts stay local, large ones climb. This is the pattern most growing companies actually need, and the one spreadsheets and chat are worst at faking.

The anti-patterns

• Approval theatre. Steps that exist so someone feels informed, where nothing is ever rejected. Convert those to notifications; save decisions for people who actually decide.
• The forty-field request form. Every field beyond what the approver needs is a tax on the requester and a reason to use WhatsApp instead.
• Notify-everyone. If every request pings the whole team, the pings become wallpaper within a month. Route to the person whose decision it is.
• No time dimension. A workflow without deadlines and escalation optimises for the approver's convenience and against everyone else's.
• Automating the argument. If two departments disagree about who approves capital requests, software will not settle it. Settle it first. We wrote about why you should never automate a broken process.

Tools or custom build?

Simple, standalone flows, leave requests, small expenses, are well served by workflow features inside tools you may already pay for. A custom build earns its place when the approvals live inside a wider operational system (as with defect approvals inside a fleet register), when routing rules are genuinely yours (thresholds, tiers, chains that no template matches), or when the audit trail carries regulatory weight. As one focused piece of work this is a small project: our automation sprint covers exactly one workflow, approval chain included, in two to three weeks, and it is deliberately the smallest way to try working with us.