---
title: "A template strategy that survives contact with production"
summary: "Templates are approved in advance, billed by category and impossible to improvise. Design the set before you need it, not during an incident."
canonical: https://cpaas.co/en/insights/whatsapp-template-strategy
kind: use-case
depth: applied
origin: original
published: 2026-07-20T11:34:07.986Z
updated: 2026-09-08T11:34:08.130Z
topics: ["WhatsApp", "Conversational Marketing", "Messaging"]
language: en
---
# 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.

## Design the set, not the message

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.

## Category is a billing decision and a trust decision

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.

> **Interactive figure — session-window.** The window governs free-form replies, not templates. Switch the message type to see which constraint actually applies.
> Available at https://cpaas.co/en/insights/whatsapp-template-strategy

## Keep a break-glass template approved

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.

## Version them like code

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.

```diagram:blocks
# What a template record has to carry
Body and variables | The exact text as approved, with the variable positions. Not the current text — the approved one.
Category | Utility, marketing, authentication. The billing consequence and the trust consequence in one field.
Approval state | Approved, pending, rejected, paused. With the reason, in the platform's words.
Version and dates | When it was approved, when it was superseded. Messages sent under it point here.
Language | One record per locale, not one record with a translation field. They are approved separately.
Break-glass flag | Marks the pre-approved template you keep for the incident you have not had yet.
> The identifier the platform issues is a foreign key, not the record. Everything above is yours to keep.
```

## And the thing to avoid entirely

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.

## The set, as a portfolio

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.

```diagram:matrix
# Where each template earns its approval
Customer initiated | Confirmations and receipts. Highest trust, lowest scrutiny, and the ones people actually want.
Expected but unprompted | Status changes. Trusted because they are relevant, not because they were asked for.
Required action | A deadline attached. The only category where urgency is honest.
Reopening a conversation | Re-engagement. Sparingly, and the first one you should cut when quality slips.
> The first two categories should be most of your volume. If the fourth is, the programme is a broadcast list wearing a conversation's clothes.
```

## The rejection loop, and how to leave it

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.

## What to take away

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.

## Sources

- [WhatsApp Business Platform pricing](https://developers.facebook.com/docs/whatsapp/pricing) — Meta for Developers
- [Updates to pricing](https://developers.facebook.com/docs/whatsapp/pricing/updates-to-pricing/) — Meta for Developers

---

Published by the company behind five products in this category. Those products appear in this site's directory alongside competitors under the same published criteria and are labelled as its own. Editorial content does not recommend them.
