Getting Approvals Out of WhatsApp and Into a System People Still Use

The purchase requisition is in the system. It has been in the system since Tuesday. On Wednesday afternoon the buyer needs it approved because the supplier is holding the price until close of business, so he takes a photograph of the screen, sends it to the general manager on WhatsApp, and gets back a voice note that says go ahead.

The goods are ordered. Later, somebody approves the requisition in the system, because the system will not let the invoice through otherwise. The approval timestamp is three days after the purchase order.

Nobody did anything wrong. The buyer protected a price. The general manager made a decision with the information he had. The clerk kept the process moving. And the company now has an approval record that is a fiction, a control that exists only in the sense that a screenshot of it exists, and an audit trail that describes a sequence of events that did not happen.

Everybody knows how to fix this. Almost every attempt to fix it fails, and it fails for a reason worth understanding before you attempt it, because the reason is not that people are undisciplined. This article is the specific case of the general rule that automating a process before you have measured it makes the mess faster — and approvals are where that error is most expensive, because a slow approval does not merely annoy people, it stops work.

Why the chat wins, stated honestly

The chat is not a lapse. On every dimension that matters to the person using it, it is better than the system, and any design that does not confront that will lose to it again.

It is where the person already is. The approver has the app open. He does not have the ERP open. He may not have the ERP on his phone at all, and if he does, it asks him to log in and the session has expired.

It reaches a person, not an inbox. A notification in a system competes with forty other notifications. A message on WhatsApp is read within minutes because that is what the channel is for. This is the largest single advantage and it is almost never replicated.

It carries context in one screen. The photograph shows the item, the supplier, the price and the buyer's face. A system approval screen shows a document number and a total, and the approver has to click twice to learn what he is approving.

It permits a conversation. Why is this one more expensive than last time? That question is one message. In most approval systems it is a rejection with a comment, a resubmission, and two days.

It is asynchronous and forgiving. He can reply from a car, from a meeting, from another country, at eleven at night.

Add those up and the chat is not a shortcut around the control. It is a better-designed piece of software for the task, built by people who thought hard about it, and the ERP's approval module was built by people who thought about the audit trail. That asymmetry is the whole problem.

What actually breaks

It is worth being precise about the damage, because the case for change is usually made emotionally and then loses to the case for speed.

The record is false, not merely absent. This is the important one and the one that gets understated. If approvals happened in chat and were entered afterwards, the system contains approval records with wrong timestamps, entered by the wrong person, in the wrong sequence. That is worse than no approval workflow at all, because a system with no approvals is honestly uncontrolled and a system with retrofitted approvals is dishonestly controlled — and the second one passes a cursory inspection.

The evidence has a lifespan. Chat history lives on personal devices. It leaves when the person leaves. It is deleted when the phone is replaced, when storage runs out, when a group is cleared. The approval that justifies a payment made two years ago is on a handset that was traded in — which is the same evidential decay that makes an approval agreed in a message and never re-entered impossible to price when the dispute arrives.

It cannot be delegated. The mechanism is the person. When the general manager is on a plane, there is no approval, because the control was never a rule — it was him. Every owner who wants to step back from signing everything discovers that there is nothing to step back into.

It fails an audit and it fails diligence. A tax authority, an external auditor or an acquirer asks to see the approval for a specific transaction. Producing a photograph of a phone screen is not a refusal, but it is an answer that generates ten more questions, and it is the point at which an inspection turns into an examination.

It hides the bottleneck. Nobody can measure how long approvals take, because the request is not in a system. So the organisation cannot tell whether the problem is one person's inbox or a badly designed threshold, and it therefore fixes neither.

The rule that decides whether this works

The in-system path has to be faster than the chat for the approver, not for the process owner.

That sentence is the whole design brief, and it is routinely inverted. Most implementations optimise for completeness of the record and treat speed as a nice-to-have, which produces a control that is correct and unused.

Faster means: fewer taps from notification to decision, no login if it can be avoided, the information needed to decide visible without navigation, and a reply possible from a phone in under thirty seconds. If a busy person cannot approve in half a minute, they will photograph a screen, and they will be right to.

Everything below is downstream of that rule.

Design decisions that make it survivable

Approve from the notification. The single highest-value feature. If the approver has to open an application, find a list, open a document and click a button, you have lost. Approve and reject should be actions on the message itself — an email with two buttons, a push notification with two actions, a message in whatever channel they already read.

Put the deciding facts in the notification. Not "PR-2026-0417 requires your approval". What it is, who asked, how much, against which budget or job, what the last price was, and why it is above the threshold. The approver's question is almost always comparative, and answering it in the notification removes the reason to ask it in chat.

Reduce the number of approvals before you speed them up. The most effective intervention is usually not a better workflow; it is fewer items in it. Raise the thresholds. Give the buyer a standing limit against an approved supplier at an agreed price. Approve the budget once instead of every line inside it. An approver reviewing four things a day reads them. An approver reviewing forty clicks through them, and a rubber stamp inside a system is a control in name and a delay in fact.

Design the exception path first. There will be genuine emergencies: a price expiring, a site stopped, a container in demurrage. If there is no legitimate fast path, the illegitimate one is the chat, permanently. So build one — a named senior person can approve outside the normal route, the record is flagged as an exception, and somebody reviews exceptions monthly. This is the same principle that makes any control survivable: a rule with no sanctioned exception is not obeyed, it is circumvented, and the circumvention is invisible.

Escalate on time, automatically. An approval sitting untouched for a defined period goes to the deputy. This is what converts a person into a mechanism, and it is the feature that finally lets an owner take a holiday.

Use the chat channel if you can, rather than fighting it. The objection to WhatsApp is not the app; it is that the decision is not attached to the transaction. A properly integrated messaging channel that sends the request to the phone, takes the reply, and writes it against the document with an identity and a timestamp keeps everything the chat is good at and fixes the only thing it is bad at. Where that is available it beats trying to move people to a channel they do not use — a straightforward application of the rule that you meet people where the work already happens rather than relocating them.

The order of implementation

Sequence matters here more than in most process work, because a false start on approvals is very hard to recover: once people have been told to use a new flow and it was slower, the second attempt is met with an eye-roll.

Measure first. For one month, count approvals by type and value, and time them from request to decision. You will discover the volume is concentrated — a small number of categories generate most of the requests — and that the median approval is fast while a tail of them takes days. Both facts change the design.

Fix the thresholds before building anything. Half the volume usually should not require approval at all, and removing it costs nothing.

Pilot one category with one approver. Purchase requisitions above a limit, or leave requests, or credit notes. One category, four weeks, with the chat explicitly still permitted. If people voluntarily stop using the chat for that category, the design is right. If they do not, the design is wrong and you have learned it for the price of four weeks rather than a programme.

Then close the old path — but only for the category that has proven itself. Closing it before the new path is faster produces resentment and a workaround. Closing it after produces a shrug, because nobody is defending something slower than the alternative.

Then expand, one category at a time.

What to expect from people

The resistance is real and it is not usually about the software.

Approvers resist because the new flow makes their response time visible, and it was not visible before. This is worth naming rather than pretending: the reason approvals were invisible is that nobody could measure the person holding them up, and the person holding them up is frequently senior. That is a management conversation and no workflow tool will have it for you.

Requesters resist for the opposite reason: the chat let them apply pressure to a human being, and a queue does not feel pressure. The answer is escalation timers, which apply the pressure impersonally and better.

And the person who resists most is frequently the one who is best at the current way of working, because their competence is partly in knowing whom to call — which is precisely the pattern that makes your strongest people your strongest resistance, and why the honest framing is that you are not fixing their behaviour, you are removing a dependency on them that they never asked to carry.

The short version

Chat approvals win because the chat is faster, reaches a human, carries context and allows a question. Any replacement that is slower on those four dimensions will lose, regardless of how much better its audit trail is.

The damage is not that approvals are missing. It is that they are reconstructed afterwards, which produces a record that is confidently wrong, evidence that lives on somebody's personal phone until they change it, and a control that stops working the moment one person is unavailable.

So do not start by building a workflow. Start by counting how many approvals there are and deleting the ones that should not exist, then make the remaining ones answerable in thirty seconds from a phone, then build a legitimate fast path for the emergency that will otherwise send everyone back to the chat. Close the old channel only after the new one has beaten it in a pilot — because the only thing that has ever moved an approval out of WhatsApp is that the alternative was quicker.