Verification checklist before activating an automated flow on WhatsApp: testing steps, templates and monitoring

What this checklist is for

Activating an automated flow on WhatsApp is not like publishing a web page: if something fails, the error is not seen by an anonymous visitor, it is seen by a customer who messaged you expecting a response. And unlike an email, a poorly configured automated message can lead to a complaint, a number block, or a conversation cost you did not expect.

This checklist is for the moment before activating an automated flow on a platform that uses Meta's official WhatsApp API (WhatsApp Cloud API). It works whether you built the flow in Wando or in any other tool: the verification steps are about the platform and about WhatsApp, not about a specific brand. The idea is for you to print it, copy it, or keep it next to you while you test, and to check off each item.

What an automated flow is and what can go wrong

An automated flow is a sequence of messages that triggers itself based on an event: a customer writes for the first time, leaves an abandoned cart, asks for the store's hours, or reacts to a campaign. The platform detects the event and responds with a message, which can be a template approved by Meta (for the first contact or messages outside the 24-hour window) or a free-form message (inside the session window).

The three most common problems when activating a flow are:

• The trigger is misconfigured and the flow fires when it should not (or does not fire when it should).
• The template used is not approved or the text does not match the approved one, and the message is not sent.
• The flow does not account for the schedule or the context, and the customer receives a response that makes no sense at 2 in the morning or after their problem was already resolved.

None of these problems is detected by looking at the code: they are detected by testing with real messages and reviewing the history. That is why this checklist is organized in three stages: before activating, during testing, and after activating.

Stage 1: before activating, review the configuration

Everything that follows is done with the flow deactivated or in draft mode, before a single real message goes out. If the platform has a test switch or sandbox, use it; if not, deactivate the flow and test with a test number.

• The trigger is defined with a clear condition: for example, 'first message from the customer' and not 'any incoming message'. Check that there are not two flows with the same trigger, because there they collide and the customer receives two responses.
• The template the flow uses is approved by Meta. In the platform panel the status must show 'Approved' or 'Active', not 'In review' or 'Rejected'. If it is pending, approval can take up to 48 hours; do not schedule the flow activation for before that approval.
• The template text matches exactly the one that was approved. If you change a word after approval, Meta reviews it again and the flow may end up sending a message different from the approved one, which is grounds for blocking.
• The flow schedules are configured: if it is a business with business hours, the flow should not respond outside those hours, or it should respond with a different message ('we will reply during business hours').
• The data the template uses (customer name, order number, tracking link) has a defined source and cannot arrive empty. If the customer name is a required field and does not exist, the send fails.
• The WhatsApp number the flow sends from is the correct one and is connected to the platform. Check that there are not two active numbers with the same name so you do not send messages from the wrong number.
• The integrations that trigger the flow (form, e-commerce, spreadsheet) are connected and with valid permissions. An expired token means the flow does not fire and nobody finds out until a customer complains.

Stage 2: the test with real messages

The test is not done with the platform's 'send test message' button: that button only confirms that the template is approved, not that the complete flow works. The real test is simulating what a customer will do, end to end, with a number that is not the business's.

1. 1Write from a test customer number to the business's WhatsApp number, as if you were a real customer. Use a phone different from the one that manages the account, because if you write from the same number that is configured as administrator, the platform may not treat the message as a normal incoming message.
2. 2Verify that the flow is triggered: the automatic message must arrive in less than a minute. If it does not arrive, check the platform log: the event came in, but the send failed or the trigger did not match.
3. 3Reply to the automatic message as a customer would: 'thanks', 'yes', 'and the price?'. The flow must recognize the response and continue the conversation, or hand off to a human agent if it does not understand.
4. 4Test the edge case: write something the flow should not understand (an insult, a very specific query, an audio). The flow must hand off to a human, not stay silent or respond with anything.
5. 5If the flow sends attachments (image, PDF, link), open each one and verify that the link is not broken and the file does not weigh more than WhatsApp allows.
6. 6Test the flow outside the configured hours: if the business closes at 18:00, write at 20:00 and confirm that the message that goes out is the 'outside hours' one or that none goes out.
7. 7Review the test conversation history in the panel: each message must have the status 'sent' and 'delivered', not 'failed' or 'pending'. If you see a 'failed', the reason is usually in the message detail.

The full test takes between 10 and 20 minutes if the flow is simple. If it is a flow with several branches (customer asks for a time, customer asks for a price, customer wants to talk to a person), test each branch separately. Testing only the happy path is not enough: the flow that fails in production is the one you did not test with the ugly case.

Stage 3: initial monitoring after activating

Activating the flow is not the end: it is the moment when monitoring begins. The first 48 hours are critical, because that is when you see the errors that the test did not detect (for example, a spike in messages that you did not manage to simulate or an integration that goes down with real volume).

• Two hours after activating, check the panel: how many messages went out, how many were delivered and how many failed. If the percentage of failures is greater than 5%, deactivate the flow and review the configuration before continuing.
• After 24 hours, review the real conversations: the customers who received the automatic message, did they reply? Do the replies make sense? If a welcome flow receives many replies of the type 'what?', the message was not understood.
• Check that the flow is not replying twice to the same message or entering a loop (customer writes, the flow replies, the flow replies to itself). That shows up in the history: if there are messages from the business that do not correspond to any customer reply, there is a loop.
• Verify that the templates used are still approved: sometimes Meta disapproves them after a while if it receives complaints or if the content does not match what was declared.
• Check the schedule: if the flow replies outside the configured schedule, there is a time zone or trigger configuration problem.
• If the flow hands off to a human agent when it does not understand, confirm that this agent is available and that the handoff works: a customer who receives 'I am transferring you to an agent' and gets no reply afterward is worse than receiving nothing.

If something fails during monitoring, do not try to fix it with the flow active: deactivate the flow, correct the configuration, test again with the test number and only then reactivate it. The time you lose by deactivating is much less than the time you lose explaining to a customer why they received three identical messages.

What to do when something fails: quick decision table

Questions you have to ask yourself before each activation

• Does this flow answer a question the customer actually asks, or is it a message I like sending? If it's the second one, don't activate it: the customer will ignore it or reply 'what?'.
• What happens if the customer replies with something the flow doesn't understand? If the answer is 'nothing', the flow isn't finished.
• What happens if the flow fails at 3 in the morning? If no one is going to see it until 9, the error message still reaches the customer: set up a fallback message or deactivate the flow outside supervision hours.
• How much does each automatic message cost? Every conversation opened by a business message has a Meta cost that varies by country: if the flow is going to trigger thousands of messages, the monthly cost adds up. Check Meta's official documentation for your country before activating a mass flow.
• Does this flow replace a person or assist them? If it replaces them, the allowed margin of error is much smaller: a flow that answers a billing complaint incorrectly creates a problem that a person then has to fix.

The difference between a flow that works and one that annoys

A well-configured automated flow is noticeable because the customer doesn't notice it: they get a useful answer and go on with their day. A poorly configured flow is noticeable because the customer gets a message they didn't ask for, at a strange time, with a typo, or after they already solved their problem.

The difference isn't in the tool, it's in the prior verification. This checklist doesn't guarantee the flow will be perfect: it guarantees that you tested the main paths, that you reviewed the edge cases, and that you will look at the metrics during the first 48 hours. The rest is fine-tuning, and fine-tuning is done with data, not assumptions.

If you're about to activate a flow and you haven't done an end-to-end test with a real number, stop: the flow isn't ready. The test takes 20 minutes and saves you a complaint from a customer who got a broken message at 8 in the morning.