WhatsApp Outbound Messages: Templates, Opt-In and Best Practices

WhatsApp Outbound Messages: Templates, Opt-In and Best Practices

An outbound message on WhatsApp is one your company starts, outside a conversation the customer opened. On the official API, sending one requires a template approved by Meta and a recorded opt-in, meaning the contact's clear permission to receive that type of message. Without both, the send fails or, worse, triggers reports and a drop in your number's quality rating.

This guide covers how WhatsApp outbound messages, templates and opt-in fit together, and how to launch a first flow without putting your number at risk.

Key takeaways

• Outside the customer service window, a company can only start a conversation with an approved template. Free text is not allowed.
• A template has a category, fixed text and variables. The declared category must match the real content, because it affects approval and billing.
• Opt-in must be specific, provable and easy to withdraw. Having a phone number in your database is not the same as having permission.
• Sending quality matters: many reports and blocks reduce your number's sending capacity.
• Start small: one flow, one template, one list with clear consent, and a success criterion agreed in advance.

What is an outbound message and when does it require a template?

The WhatsApp Business Platform works with the concept of a customer service window. When a customer writes to your company, a period opens in which you can reply with free-form messages. The official documentation defines how long that period lasts, and it can change, so confirm the current value before you design the flow.

Once the window has closed, or when your company wants to speak first, you can only send a template message. This is the typical scenario for an appointment reminder, a delivery notice, a payment confirmation, a pending document alert, or a campaign to people who asked to hear your news.

The practical consequence is a design one: every outbound message must be planned in advance, written, submitted for approval and tied to a contact base that has given permission. Improvising is not an option on this channel.

How do WhatsApp message templates work?

A template is a message model registered in your WhatsApp Business account and submitted to Meta for review. It has predictable parts:

• Body: the main text, with slots for variables such as name, date or order number.
• Header and footer: optional, used for a title, media or an identification line.
• Buttons: optional, such as quick reply, link or call.
• Language: each language version is registered and approved separately.

Variables are filled in at send time, but the text around them is fixed. That is why a template does not suit an open-ended conversation. It works well for objective notices and for opening a dialogue that continues once the customer replies.

The official documentation groups templates into categories, generally utility, marketing and authentication. The difference matters for two reasons. First, the review checks whether the content fits the chosen category, and a promotional-sounding notice declared as utility can be reclassified or rejected. Second, how you are billed depends on the category. We do not quote figures here because the pricing table changes: check the current official pricing page before you project volume.

An approved template is not permanent. If recipients react badly, quality drops, and the platform may limit or pause that template. A poor template is expensive even when it was approved.

What counts as valid opt-in?

WhatsApp's business messaging policy requires companies to obtain consent before sending messages they initiate. In essence, the policy expects that the person gave their number voluntarily, knows they will receive messages from the company on WhatsApp, and that the company complies with applicable law. In Brazil, this connects with the LGPD: consent is one of the legal bases, and when it is the base you choose, it must be freely given, informed and for a specific purpose.

In practice, a defensible opt-in has these elements:

• It identifies who will send the messages (the company name).
• It states that the channel is WhatsApp.
• It states the type of content: order updates, reminders, offers, and so on.
• It is given through an affirmative action, such as ticking a box that starts unticked, sending a message to request the service, or replying to confirm.
• It is recorded: date, source, the text shown and the number.
• It can be withdrawn easily, and the withdrawal is honored immediately.

What does not work: buying a list, using contacts from an event without notice, reusing the sign-up for one service to send promotions for another, or hiding the permission in long terms. Keep consents separate as well. Someone who agreed to delivery notices did not thereby agree to promotions.

A note on legal basis: not every transactional message depends on LGPD consent as its basis, but WhatsApp's policy asks for opt-in in any case. Align on this point with your legal team or data protection officer. For the broader picture, see LGPD and Artificial Intelligence for Companies: What to Do and the guidance published by Brazil's data protection authority (ANPD).

Step by step: launching your first outbound message

This is an implementation outline for a first flow.

• Step 1, choose the flow: a situation where the customer expects to hear from you, such as an appointment confirmation or a shipped-order notice.
• Step 2, confirm the channel: outbound messages at scale require the official API, through a provider or the Cloud API. If you have not yet decided between the app and the API, read WhatsApp Business API vs App for an AI Agent: Which to Use.
• Step 3, define the opt-in source: where the person gives permission, with what text, and where that record is stored.
• Step 4, write the template: one purpose per template, direct language, variables only where needed, and a recognizable company name.
• Step 5, choose the category honestly and submit for approval. If it is rejected, read the reason and adjust, rather than resubmitting the same text with small changes.
• Step 6, define what happens when the customer replies. A person or a system must handle it, with a rule for handing off to a human.
• Step 7, implement opt-out: a simple way to stop receiving messages, with immediate removal from the send list.
• Step 8, send to a small group and track deliveries, replies, opt-out requests and reports before you expand.

Illustrative scenario: a pending document reminder

Illustrative scenario: a services company needs a customer to send a document to complete a registration. Today the team calls, the customer does not answer, and the deadline slips.

The flow would be designed like this. On the contract form, an unticked box asks whether the customer agrees to receive registration progress updates on WhatsApp, with the company name and purpose written out. The answer and the date are stored. A utility template says, in a few lines, that document X is missing to complete the registration, with a reply button for the customer to indicate whether they already sent it or need help.

If the customer taps the button, the service window opens and the flow can continue in free text, including with the support of an AI agent to answer simple questions. If they ask to stop, they leave the list at that moment. The company decides in advance that after two attempts with no reply, the case returns to human contact through another channel, rather than pushing further on WhatsApp.

What makes this flow safe is not the technology. It is the specific consent, the useful message, the limit on attempts and the easy exit.

Best practices for content, frequency and quality

The platform watches how people react to messages. Reports and blocks count against your number. A few practices reduce that risk:

• Send only what the customer expected to receive, based on what they agreed to.
• Start the message with the reason for contact, without long preambles.
• Identify the company right at the beginning.
• Avoid variables that could come out empty or wrong, such as a blank name. Validate the data before sending.
• Limit frequency per contact. Set a weekly cap per person and enforce it in the system, not through the team's good intentions.
• Respect reasonable hours for your audience.
• Do not use a utility template to push an offer.
• Monitor number and template quality in the dashboard and pause sending when the signals worsen.
• Log every send: who received it, which template, when, and which opt-in is linked. This helps with audits and complaints. For how long to keep these records, see AI Conversation Log Retention and Data Masking: LGPD Guide.

If your goal is to reduce no-shows for scheduled appointments, reminder design deserves its own attention. There is a deeper look in Reduce Patient No-Shows With AI Reminders: A Practical Guide.

Where AI fits and how to apply the method

AI should rarely decide who receives an outbound message or write the template in production. The deterministic part (list, consent, frequency, timing, approved template) is better handled by clear rules. AI adds more value afterwards, when the customer replies and the conversation needs interpretation, but always within topic limits and with a handoff to a person. For the technical layer that receives replies, see WhatsApp Cloud API Agent Architecture: Webhooks and Queues.

The method we use in projects like this has four steps:

• Map: list which messages the company already sends, through which channel, to whom and with what permission, and record the current baseline.
• Limit: restrict the scope to a few templates, minimal data in variables, and the actions the agent can take when a reply arrives.
• Pilot: run one real flow with decision records and a success metric agreed before the start.
• Hand over: deliver the documented operation and decide with the team whether to expand, adjust or stop.

The starting point usually reveals the biggest risk: contact lists with no proof of consent. Fixing that before any automation avoids rework.

Common mistakes to check before you send

• Treating the entire customer base as if it had agreed to receive messages.
• Submitting a promotional template as utility to try to get faster approval.
• Having no plan for replies, leaving customers without a response after a send.
• Ignoring opt-out requests written in free text, such as "stop messaging me".
• Measuring only send volume, without looking at reports, blocks and replies.
• Not reviewing the rules: policies and categories change, and what applied at launch may have been updated.

Frequently asked questions

Do I need a template for every outbound message?

Yes, whenever the conversation is not within a service window opened by the customer. Inside the window, the company can reply in free text. Outside it, only with an approved template.

Does the phone number I already have on file count as opt-in?

Generally no. Having the number does not prove the person agreed to receive messages from your company on WhatsApp about that subject. The ideal is to collect specific permission, recording the date, source and text shown, and to allow withdrawal at any time.

Can an approved template stop working?

Yes. Approval is not a permanent guarantee: if recipients react badly, with blocks and reports, the quality of the template or the number drops and the platform may limit sending. That is why it pays to start with small groups and watch the signals.

Can an AI agent send outbound messages on its own?

Technically it can trigger a template, but we recommend that the decision of who receives a message and when follow explicit rules, with frequency limits and a consent list. AI makes more sense in the conversation that starts after the customer replies, with limited scope and a handoff to a person. Always confirm the current rules in Meta's official documentation, and if you have doubts about the legal basis, consult your legal team.

Sources

• Meta for Developers: enviar mensagens de template na WhatsApp Cloud API
• WhatsApp Business: política de mensagens comerciais
• ANPD: Autoridade Nacional de Proteção de Dados