Start at the end, with the argument.
It is a Tuesday, three weeks after a wedding. The client is disputing the bill. They say a 10 per cent discount was agreed; the invoice shows 5. The salesperson is sure the owner approved the bigger discount. The owner is sure he did not. Someone scrolls up through the WhatsApp group and finds it: a quotation PDF, the message "ok to confirm?", and the owner's thumbs-up, forty minutes later.
The PDF is for ₹6.2 lakh. The invoice is for ₹6.9 lakh. Between the thumbs-up and the event, the client added two items, the quotation was redone, and the discount was changed. Nobody sent the new version for approval, because the order already had one.
Nothing about this is carelessness. Every step is how approvals usually run in a company of this size. The owner was reachable, the salesperson asked, the answer came back in under an hour. The chat did its job. What it could not do is the thing the argument now needs: say what, exactly, was approved.
What the thumbs-up was attached to
Work backwards from the dispute and ask what would have had to be true for it not to happen.
The thumbs-up would have had to be attached to the ₹6.2 lakh version in a way that survived the change to ₹6.9 lakh. Not attached to the chat, and not to "the order" as a loose idea, but to a specific set of numbers. When the numbers changed, the approval would have had to stop applying, so that someone had to ask again.
That is the first thing an approval has to carry: a version. An approval is a claim about one set of figures. Chat has no way to say which figures, so it defaults to "whatever the order turns into".
What the thumbs-up did not hold
Keep working backwards. Between the thumbs-up on Thursday evening and the booking sheet being updated on Monday, the equipment for that wedding was still free in every system the company had. On Saturday a second salesperson booked some of the same items for another event on the same dates, because nothing said they were taken.
So the second thing an approval has to carry is the hold. The moment the last yes lands, the units for those dates have to be taken out of circulation, in the same breath. An approval that reserves nothing is a promise the warehouse does not know about.
What the thumbs-up did not say was missing
Many orders in this company need two yeses, not one. Anything above ₹4 lakh needs the owner. Anything with an advance needs accounts to confirm the money has come in. In the chat these are two separate conversations in two separate threads, and an order with one yes and one silence looks exactly like an order with none. It sits. Usually until the client calls to ask why nothing has moved.
Third thing: an approval has to be visible as missing. Someone has to be able to open one screen and see every order waiting on them, and the salesperson has to be able to see which of their orders is waiting, and on whom.
Where the "no" went
The fourth comes from the other direction. When the owner turns a request down in chat, the "no" is a message. It scrolls away in an hour, and the reason scrolls away with it. The salesperson may not find out until the client asks. A rejection needs a place to live that the person who has to act on it will actually look at.
The fifth is the one nobody thinks about until it happens. Two people can approve the same thing at the same moment: the owner and accounts both clicking, or one of them double-clicking on a slow connection. In chat that is harmless, two thumbs-ups. In a system that reserves stock on approval, it is two reservations.
Five things, then: a version, a hold, visibility of what is missing, a home for the no, and protection against the double yes. None of them is a feature a chat app lacks by oversight. They are all things a message cannot be.
How the order system carries each one
I built the order system for an equipment rental company with six branches. This is how it carries the five.
The version. An approval sits on the order, and an order is created from a quotation that locks when it converts. A change to the value after that is itself a request with its own approval, and an order still waiting on a yes can be sent back to its quotation and resubmitted; neither path edits the numbers under an existing approval. The thumbs-up in the story above could not have been found on the wrong amount, because there is no wrong amount for it to be found on.
The hold. The rule decides who approves, not the person asking. Above ₹4 lakh the admin; with an advance, accounts; the threshold is a setting the admin changes himself. When the last required approval lands, the system reserves the units for those dates inside the same database transaction as the approval. If the units are no longer free, the approval does not go through, and the approver sees why. There is no state in which an order is approved and the stock is not held.
What is missing. The admin opens one page and sees every order, quotation and payment request waiting on a decision from him. Accounts sees theirs. The salesperson sees their own requests, each marked with who it is waiting on. An order with one yes and one silence is a row on that page, not a gap in a thread.
The double yes. This one is worth a paragraph, because the obvious way to build it is wrong. The obvious way is: read the order, check it is not already approved, then write the approval. Two people doing that at the same second both read "not approved" and both write. The system does it as one step instead: the write itself says "set approved, but only if it is currently not approved and the other side's flag is still what I saw". The database applies that as a single operation. The second click finds the condition false and is told the order is already approved. Nothing in the code "checks first"; the check and the write are the same instruction.
An early yes is kept. If the admin approved the quotation before it became an order, the order does not ask again. It records who approved and when. And once approved, the salesperson who raised the order can no longer delete it.
The one I got wrong
The home for the no.
When accounts turned down a payment request, the system did the right things: saved the reason, wrote a line on the order's history, and sent the salesperson a notification. I thought that covered it.
It did not. Notifications expire after 30 days, and nobody reads back through them. No screen listed "your requests that were turned down". In one 30-day stretch there were 28 rejected payment requests, and the only way for a salesperson to find any of them was to open the right order and read its history. Which they did not, because they did not know which order.
The fix was small. The salesperson's approvals page gained a section called "Rejected in the last 30 days": the amount, the reason, who rejected it and when, and a link to the order. A row leaves the list when the salesperson raises a new request on that order, because at that point the rejection has been acted on.
Saving a "no" and showing a "no" to the person who has to act on it are two different things. I had built the first and assumed the second.
Back to the Tuesday
In the system above, the Tuesday argument does not happen, but not because the software is clever. It does not happen because the approval was a claim about ₹6.2 lakh and nothing else, and the ₹6.9 lakh version had to be approved on its own.
If your approvals run on chat, take one large order from last month and ask the five questions. Who approved it, and for what amount, without scrolling? Did the figures change afterwards, and did anyone approve the new ones? Between the request and the yes, could someone else have booked the same stock? If two approvals were needed, where could you see that one was still missing? And for a request that was turned down, where is the reason, and did the person who asked ever see it?
WhatsApp is good at reaching the owner in forty minutes. There is no reason to stop using it for that. The trouble starts when the chat is also the record.