WhatsApp Lifecycle Programme on the Meta Cloud API

What we build: We build WhatsApp programmes where the marketing template budget is capped at two sends per contact per month and everything else is a utility template fired by an event that already exists in your systems: a schedule change, a dispatch, a refill window, a donation receipt. That ratio is the decision the rest of the build follows from. Meta prices template categories separately, a utility message sent inside an open 24-hour service window is not billed at all, and quality rating erodes on marketing sends rather than transactional ones. Programmes built the other way round pay more per message and lose their messaging tier inside a quarter. The reach test comes first: Before a template is written we run your file through a reach check and tell you what share of it is actually contactable on WhatsApp. On a Spanish, Brazilian, Indian or Gulf consumer list that usually comes back north of eighty percent. On a Swedish, Norwegian or Finnish list it is frequently under a third, because the Nordics never left SMS and Messenger. When the number is low we say so and tell you to put the money into RCS or into the email programme you already have. We have ended two engagements at this stage and refunded the balance. The build: Cloud API only; the On-Premises API is gone. Business verification, display name review and number provisioning through whichever BSP fits your billing: 360dialog when you want the Meta invoice in your own name, Sinch when you want one contract covering WhatsApp, RCS and SMS. Templates are written by category deliberately, submitted with the sample variables Meta reviews against, and versioned in your repository instead of a BSP console nobody can audit. Triggers come off CRM and ESP webhooks, not a nightly CSV. Quality rating, per-template pause status and tier changes land in a channel your team owns, not ours. Where it earns its keep: Travel operators with PNR-linked disruption messaging, where the utility template replaces a call-centre queue. Medtech onboarding after a device ships, where the alternative is a PDF nobody opens. Nonprofits recovering lapsed recurring gifts, where a receipt thread is already an open service window and the ask costs nothing to send. In all three the revenue sits in the transactional half of the programme, which is the half most shops treat as plumbing. What we do not do: No purchased lists. No numbers harvested from order forms with no opt-in record behind them. No unofficial web-automation wrappers. No template farms built to rotate around rejections. We will not run a WABA on a number carrying personal WhatsApp history until it has been migrated or replaced, and we do not write templates whose only real function is to reopen the service window. Who should not buy this: Anyone whose success metric is send volume. Anyone without an event stream: if your systems cannot tell us a booking changed within minutes of it changing, there is no utility programme to build and you have bought an expensive SMS channel. And anyone planning to move an email programme onto WhatsApp wholesale. The frequency ceiling here is roughly a fifth of what email tolerates, and the unsubscribe is a block, which is permanent, invisible in your ESP, and counted against you by Meta.