A template strategy that survives contact with production

Every WhatsApp programme eventually hits the same 2am problem: something has gone wrong, you need to tell customers, and the message you want to send does not exist as an approved template.

Think of templates as a small API you are publishing to your future self. The right question is not "what do I want to say today" but "what classes of thing will I ever need to say".

A workable starting set:

• Transactional confirmation. Something happened that the customer initiated.
• Status change. Something happened that they did not initiate but expect.
• Action required. They must do something, with a deadline.
• Time-sensitive alert. Service disruption, security, fraud.
• Re-engagement. A reason to reopen a conversation, used sparingly.

Each with enough variables to be reusable. Five well-parameterised templates beat forty specific ones, and are far easier to keep approved.

Templates are filed under a category, and the category determines how the message is billed. Meta moved the platform to per-message billing on 1 July 2025; the current rate card and the rules about what is billable live on the pricing page, and they have changed more than once.

Two operational consequences:

Do not file marketing as utility. It is detectable, it gets templates rejected, and repeated attempts damage the account. The saving is small and the downside is your channel.

Model cost per outcome, not per message. A utility template that produces a resolved query is cheaper than a marketing template that produces nothing, whatever the unit prices say.

The single highest-value operational practice here: maintain an approved, generically worded incident template that you never use.

Something that can carry a variable explaining a disruption and a link. Get it approved when nothing is wrong. The one time you need it, approval latency is the difference between telling customers and not.

The template you will need most urgently is the one for an outage, a recall or a security notice — and approval takes days you will not have.

Get a broad, honest, service-category template approved before you need it. Word it so it can carry any incident: what happened, what you are doing, where to look for updates. The temptation is to write it specifically. Resist it; a specific template is one you have to get approved again for the next incident.

Templates drift. Someone edits copy, resubmits, and now production references a template ID that no longer means what the code assumes.

Keep template definitions in version control alongside the code that sends them. Treat an approval as a deployment. If your CMS or platform lets you export them, export them on a schedule — reconstructing a template set from a vendor console is a bad afternoon.

Do not build a template that only makes sense as the opening of a conversation you have no capacity to continue. If a template invites a reply, someone — or something — has to be ready to answer it.

Five categories, and the discipline is in the count rather than the craft. A programme with forty templates has, in practice, a dozen that carry the traffic and twenty-eight that are variations nobody has retired.

Template rejection is rarely about the words. It is about the gap between the category claimed and the message written, and reviewers are consistent about it.

Marketing filed as utility is the big one. It is detectable, it fails, and repeated attempts attach to the account rather than to the template. The saving on a category is a rounding error; the cost of a damaged account is the channel.

Variables that carry the message. A template whose only fixed text is "Hello {{1}}" and whose body is a variable is not a template — it is a way of avoiding review, and it is treated as one.

No exit. A re-engagement template with no way to stop receiving them will be rejected, and should be.

Design the set, keep it small, file categories honestly, version templates as records you own, and approve the break-glass one while nothing is on fire. The unit price of a template is the least interesting thing about it.