Everything proactive you send on WhatsApp requires a pre-approved template. That is the whole constraint, and its consequence is easy to state and easy to ignore: the messages you can send during an incident are the ones you approved before it.
Review usually takes minutes. It can take 24–48 hours if something gets flagged for manual review — reliably, at the moment you can least afford to wait. A library approved three weeks ago has no latency at all.
A starting set
Most businesses can cover the majority of their proactive messaging with about a dozen templates. Ours, grouped by category:
Utility
- Order confirmed
- Payment received / payment failed
- Dispatched, with tracking
- Out for delivery
- Delivered
- Delivery delayed (the one everybody forgets)
- Appointment or callback confirmed
- Appointment reminder
Authentication
- One-time passcode
Marketing
- New collection or product announcement
- Abandoned cart
- Re-engagement for lapsed customers
The delayed-delivery template is worth singling out. It is the one nobody drafts in advance, because nobody plans for the bad case — and it is the one you will want at 4pm on a Friday when a courier hub goes down. Draft it while nothing is wrong and the copy is calm.
Design the set, not the templates
Two habits pay for themselves immediately.
Name by category and purpose. utility_order_dispatched_v2, not template_17. The name should tell you which review path it is on and what it does, without opening it.
Version rather than replace. You cannot edit an approved template’s text — any change is a new submission. So treat templates as immutable and version them explicitly. Keep the old one live until the new one is approved and switched over; deleting first leaves you with a gap.
Keep a register
For each template, record: the category, the submission date, the approval status, the variables and what fills them, and which system sends it.
That last field is the one that decays. Six months in, someone asks why customers received two dispatch notifications, and the answer is that two systems both think they own that template. A register makes that a five-minute question instead of an afternoon.
Review the library quarterly
Templates rot in three ways:
- Facts change. A returns window, a support number, an office address. Any of these embedded in template copy is a fact that will eventually be wrong.
- Variables drift. A field that used to carry a product code now carries a product name, and the message reads oddly without anything technically failing.
- Templates go unused. If nothing has sent it in six months, either the flow that used it is broken or the template was never needed. Both are worth knowing.
The thing that actually matters
None of this is about tidiness. It is about the difference between two Fridays.
On the first, something goes wrong, you write a clear honest message, submit it, and wait — possibly for a day — while customers who do not know anything is wrong keep waiting too.
On the second, you pick the template you approved in March, fill three variables, and send.
The work is identical. It just happens at a different time, and the time is the whole point.