Automate WhatsApp notifications for a business, and the billing
The technical part is straightforward. The part that decides whether it is worth doing is the billing model, and it changed in a way that rewards a specific design.
Automated WhatsApp notifications are one of the most requested small builds we see, usually phrased as sending customers an update when something happens: an order is confirmed, a delivery is out, an appointment is tomorrow. The build is not the hard part. The part that decides whether the project pays for itself is how Meta bills it, and most people costing this out are working from a model that no longer applies.
What changed, and why it matters to the design
Meta moved the WhatsApp Business Platform from conversation-based pricing to per-message pricing on 1 July 2025. Its pricing documentation sets out the current model: you are charged when a template message is delivered, and the rate depends on the template's category and the recipient's country calling code.
That single sentence has two design consequences. Billing is per delivered message, so volume is now linear rather than bundled into 24-hour conversations. And category matters more than anything else you control, because it is the difference between paying for a message and not paying for it.
| Category | What it is for | Billing |
|---|---|---|
| Marketing | Promotions, offers, re-engagement | Always billable on delivery |
| Utility | Order, account and transaction updates about something the customer did | Billable, but free inside an open customer service window |
| Authentication | One-time passcodes and verification | Billable, with volume tiers |
| Service | Your replies inside an open conversation | Free |
The two windows in that table are worth stating precisely. A customer service window opens for 24 hours when the customer messages you, and inside it your non-template replies and utility templates are free. A separate free entry point window runs for 72 hours and opens when someone reaches you through a Click to WhatsApp ad or a Page call-to-action button and you respond; while it is open, any message type is free.
The design that follows from the billing
- Classify every notification honestly as utility or marketing before you build. Dressing a promotion as an order update is both a policy risk and a template-approval failure, and the approval happens before you can send anything.
- Send utility notifications inside the customer service window wherever the flow allows it, because that is where they cost nothing.
- Treat the 72-hour free entry point window as a real asset if you run Click to WhatsApp ads. Front-loading the useful part of a conversation into it is a legitimate cost decision, not a trick.
- Batch nothing that does not need sending. Per-message billing removes the old incentive to cram messages into one conversation window, and it adds a new one: every avoidable message is a line on the invoice.
Rates vary by country and by category, and Meta publishes the current table rather than fixing it, so build the cost model against the documentation for the countries you actually send to rather than against a figure quoted in a blog post. That includes this one: we are deliberately not printing per-message rates here, because they change and a stale number in a cost model is worse than no number.
What to actually build
The minimum viable version of this is smaller than most people expect. You need an event source, a template per notification type, a queue, and a record of what was sent.
The record is the part that gets skipped and the part you will want within a month. Without it you cannot answer whether a customer was told, which is the question the whole system exists to answer, and you cannot reconcile your bill against what you believe you sent.
The queue matters because delivery is asynchronous and templates get rejected. A system that sends directly from the event handler loses messages quietly whenever the API has a bad minute, and quiet loss is the failure mode you least want in a notification system.
Where it earns its cost, and where it does not
The clearest wins are notifications that currently exist as a person typing the same message repeatedly: appointment reminders, order-out-for-delivery, payment received. Those have a measurable cost today in someone's time and a measurable failure rate, and automating them replaces both.
The weakest case is broadcast marketing, which is billable on every delivery, subject to the strictest template rules, and the fastest way to get people to block your number. If the plan is a weekly promotional broadcast to your whole list, cost it at full marketing rate against your whole list before deciding it is cheaper than email, because frequently it is not.
A related pattern worth considering first is whether the notification is the actual need. For an order flow, the notification is usually a symptom of the ordering system not having a status the customer can see. We wrote about that trade in scoping a restaurant ordering system, where the status page and the notification solve overlapping problems at very different costs.
Do not point a chatbot at it by default
Outbound notifications and inbound conversation are different systems, and combining them in version one is the most common way this project grows past its budget. A notification sender has no opinions. The moment customers can reply and expect answers, you have built a support channel with staffing implications.
If that is genuinely the goal, what to trust an AI chatbot with in customer support covers where the line sits. On the marketing side of the same question, Mostafa Faried's piece on when to use Lead Ads instead of a landing page is useful context for anyone whose WhatsApp volume is arriving from Click to WhatsApp campaigns. It is in Arabic.
The honest limits
This is not free infrastructure and it is not a channel you own. You are building on a platform whose pricing model changed once already and whose template policies are enforced by review rather than by documentation alone. A template that was approved can be rejected on resubmission, and a category can be reclassified by Meta rather than by you.
Plan for that rather than being surprised by it: keep the message content in your own system, keep a fallback channel for anything genuinely important, and do not make WhatsApp the only route by which a customer can learn something they need to know.
If the volume is low, do not build this at all yet. Under a few hundred notifications a month, a person and a shared inbox is cheaper than the integration, and the integration is easier to justify later with real numbers than now with estimated ones. The same reasoning is set out for the reporting case in reporting automation for a small business.
Describe it. We build it.
Seven or twelve days, pay on delivery, a year of maintenance included. Bring the problem, not a spec.
Book a meetingRead next
Why software projects fail, and why the average is the wrong number
IT cost overruns do not follow a bell curve. They follow a power law, which means the disaster case is far more likely than your contingency assumes.
ReadInternal tools for a small business, and when to stop using Excel
Most small companies already run on internal tools. They are spreadsheets. What the research says, and the four signs it is time to build something.
Read