A managing director once told us, with a straight face, that his approval process was "basically instant" because his managers just sent a WhatsApp message and got a thumbs-up emoji back. It is instant, in the narrow sense that a reply can arrive in seconds. It is also untraceable, unenforceable, and invisible to anyone not on that specific thread. When an auditor later asked who approved a six-figure payment and on what basis, the answer was a scroll through a phone that had since been replaced.
This is the paradox at the centre of most WhatsApp-and-Excel approval processes: they feel fast because they skip every piece of structure that a proper approval requires — a defined approver, a recorded reason, a timestamp, a record that survives beyond someone's personal device. The speed is real, but it is borrowed against future risk, and the bill eventually arrives.
Why teams resist replacing it
The resistance to changing this is usually not about the destination — most operations leaders agree, in principle, that a proper system would be better. The resistance is about the perceived cost of the transition: a new tool that requires training, a rollout that disrupts the pace of approvals during the switch, and a fear that anything more structured than a chat message will feel bureaucratic and slow things down further.
These are legitimate concerns, and they are exactly why a badly executed migration fails and teams quietly drift back to WhatsApp within a month. The fix is not to argue people out of their concerns. It is to design the replacement so that it is faster than chat for the common case, not merely more auditable — auditability alone will never win against the felt experience of a thumbs-up emoji.
The sequence that actually works
- 01Map the current approval chain exactly as it happens today, including the informal steps nobody put in writing.
- 02Identify the one or two approval types that generate the most volume or the most risk, and start there — not everywhere at once.
- 03Design the new flow to require fewer taps than the chat version for the standard, in-policy case.
- 04Run the new system in parallel with the old process for a short, defined period, comparing outcomes rather than switching cold.
- 05Retire the old channel for that approval type on a fixed date, communicated in advance, once the parallel run shows the new flow is faster.
This sequence is deliberately unglamorous. It resists the temptation to redesign the entire approval landscape in one go, which is the single biggest cause of failed rollouts. [Internal portals & approvals](/solutions/internal-portals-approvals) is built around exactly this staged approach — start with the highest-volume approval, prove it is faster, then expand.
Mobile-first is not optional
If your managers currently approve things from their phone while walking a site or between meetings, the replacement has to work at least as well on a phone as WhatsApp does, or it will lose on day one. This sounds obvious, but a surprising number of internal tools are designed desktop-first and then squeezed onto mobile as an afterthought — a push notification with a link that opens a slow, cramped web form is not a replacement for a message with a thumbs-up reaction. The bar is a notification, one glance at the relevant context, and one tap to approve or reject, with a reason required only when rejecting.
What good looks like once it is running
A well-designed replacement gives a manager the same felt speed as a chat message, plus three things chat could never provide: a record of exactly what was approved and by whom, an automatic escalation if the approver does not respond within an agreed window, and visibility for whoever needs to see the full picture — a project lead checking on purchase order status, a finance controller reviewing outstanding approvals, a director scanning a dashboard rather than scrolling five separate group chats. This visibility is what [Management dashboards](/solutions/management-dashboards) are for: turning individually reasonable approvals into a picture of how the whole process is actually performing.
The same principle extends naturally into procurement, where approval chains often have amount-based thresholds that a chat thread cannot enforce at all — a gap [Procurement & vendor management](/solutions/procurement-vendor-management) closes by tying the approval step directly to policy rather than to whoever happens to be free to reply.
Handling the exceptions honestly
Not every approval fits neatly into a standard flow, and a good migration plans for that from the start rather than treating exceptions as a failure of the new system. Urgent, out-of-hours approvals, approvals that need a second opinion, and approvals affected by a rule nobody wrote down yet should all have a defined path in the new system — even if that path is simply "escalate to a named backup approver automatically after fifteen minutes." Building this in from day one, as described in [designing a single source of truth across operations](/insights/single-source-of-truth-operations), prevents the exceptions from becoming the reason the whole rollout gets abandoned.
The real measure of success
Success is not "we bought new software." Success is that, six months later, nobody is approving anything meaningful over WhatsApp, and nobody misses it — because the replacement was actually faster for the case that matters ninety percent of the time, and better for the ten percent that used to cause real damage.