Approvals Over WhatsApp With an Audit Trail

Approvals in a small business happen on WhatsApp because it works: the manager is out, sees a message, writes "approved" and everyone moves on. The problem appears later - when you try to answer what exactly was approved, when, and against which version. The message exists somewhere in the scroll, but there is no way to search it and no way to know whether it refers to what was eventually done.

What is broken about approving in a message

The second row is the commercially dangerous one. "Approved" given against a particular amount, after which a line was added to the order, is an approval that no longer applies - and nobody will notice, because the message stayed where it was in the thread.

The structure that fixes it

The idea is simple: the message is not where the approval lives but the route to it. Instead of asking "can you approve?", you send a message containing a short summary and a link to the record, and the approval is a click - a button in the message or on a dedicated page.

What gets stored on the other side is three fields: the record identifier, who approved, and when. That is the whole requirement, and it is enough to answer any future question without searching a conversation history.

Why verbal approvals create most disputes

An approval given by voice or in a free message rests on two people's memory, and the two memories retain slightly different things. That is not dishonesty but how memory works: one remembers the amount, the other remembers the condition mentioned alongside it.

In a small business that is tolerable until one expensive case - an order placed at a different scope, an expense nobody meant to authorise, or work done on an assumed discount. Then it turns out there is nothing to go back to, and nobody to attribute the gap to.

What prevents it is not suspicion but a field: the short summary sent before the approval. Once it exists there is nothing to remember - and both versions start from the same text.

What the message has to contain

• What is being approved in one line, with the number or amount.
• The record identifier, so there is something to attach it to.
• Who requested it and when.
• A link to the full detail.
• A way to approve or decline that gets recorded.

The last point is the difference between a record and a conversation. A free-text reply - "fine", "yes", "go ahead" - requires somebody to interpret and copy it, and that is exactly the step where the record gets lost in practice.

What counts as a record you can rely on

The practical test is simple: can you answer three questions within a minute - what was approved, by whom, and when. If the answer requires scrolling a conversation, there is no record; there is history, and that is not the same thing.

The difference between them is retrievability. History is kept either way - it exists in the chat, in email and in memory - but retrieval requires the approval to sit as a field on a record rather than as text in a stream. That is also what makes counting possible: how many requests were approved this month, how many declined, and how many are waiting.

A second point worth knowing: an internal record does not replace a signed document when the other party is external. For questions about validity against a customer or supplier, consult a lawyer; this article covers internal control only, and the business's grip on what it approved.

The rule that prevents the common fault

An approval attaches to a version, not to a request. The moment anything on the record changes after approval - amount, quantity, date - the approval lapses and a new one is required. That sounds rigid and it prevents the case where somebody approves one thing and another gets done.

In practice it is one extra field: a version number or the timestamp of the last change. If it is later than the approval, the approval does not hold. The broader logic of limits and who approves what is in approval limits and controls.

What the record looks like in practice

No dedicated system is needed. One record per request with six fields: identifier, what is being requested, amount or scope, who requested, who approved, and the approval date. All of those sit in a spreadsheet or a table and cover most small businesses.

What makes it useful is that the identifier also appears in the message. When the message says "request 148 - monitor purchase, 1,200 ILS" and a tap opens that request's page, the approval links itself - and nobody has to copy anything.

The field worth adding beyond the six is a short free note from the approver. "Approved provided it is from the previous supplier" is the kind of information that disappears entirely with click-only approval, and it is exactly what turns out to matter two months later.

What not to run this way

Requests needing a signed document - agreements, large customer orders, anything the other side needs to receive as a document. Those are not internal approvals but a signing process, which looks entirely different; what is required there is in electronic signatures for business.

Decisions needing discussion do not belong here either. A one-click approval suits a binary decision on information already settled; a decision that needs talking through stays a conversation, followed by an approval of what was agreed.

What do you do when there is no reply?

This is the practical question that decides whether the process works. An approval request sent and unanswered is a stalled order, and it will not remind anyone about itself. So two things are needed: an automatic reminder after X hours, and a defined default if there is no response.

The default is usually "not approved" - and that is fine, as long as it is written down and the requester knows it. What does not work is a silent default of "if they did not answer, assume approval", which produces exactly the expense nobody remembers authorising.

It is also worth having one screen showing what is awaiting approval right now. A short list somebody sees in the morning solves more than any reminder mechanism, because it turns stalled requests into something visible.

Sources

• Business automation for small businesses in Israel
• WhatsApp Business Platform - Meta documentation