Testing an automation without messaging real customers

Testing an automation means proving each path does what you intended before the flow is published, using the simulator for logic and your own phone for the parts only a real device shows. An unpublished flow sends nothing, so all of this is safe by construction.

This is the least-written-about part of WhatsApp automation and one of the most consequential. A flow that misfires does so on every matching conversation simultaneously.

The four stages

Stage	Catches	Risk to customers
1. Read the canvas	Unwired branches, missing handovers	None
2. Simulate	Logic errors, empty variables, wrong routing	None
3. Your own phone	Copy that reads badly, timing, real rendering	None
4. Publish, watch closely	Everything else	Real

Stage 1 — read the canvas before you run anything

1. Does every branch go somewhere? A question option with nothing wired to it leaves the customer in silence.
2. Is there a path to a human? On every failure branch and every menu.
3. Does anything read a variable before something writes it? On branching flows this is easy to build by accident, and it always produces an empty value.
4. Is there a cooldown or a first-message check on anything triggered by a customer message?

Stage 2 — simulate

The builder's Simulate mode walks the flow as if you were the customer, running the real conditions and showing what each step would send, without sending anything.

Walk every path, not just the happy one. The bugs live on the branches you did not think about: the customer who taps "cancel", the lookup that finds nothing, the question answered with an emoji.

Watch specifically for variables rendering as blanks. A message that reads "Hi , your order is on its way" in the simulator will read exactly like that on a customer's phone, and the usual cause is a contact field that was never defined.

Stage 3 — message your own shop

The simulator proves logic. It does not tell you that your message is a wall of text on a phone screen, that your three button labels are truncated, or that the tone is wrong.

1. Publish the flow while your team is watching, or use a quiet period.
2. Message your shop number from your personal phone.
3. Type the way a rushed customer types — lowercase, misspelled, abbreviated. If your keyword list only matches perfect spelling, you want to know now.
4. Tap through every button.
5. Deliberately do the wrong thing: answer a button question with free text, send a photo where text is expected, go silent halfway through.

Stage 4 — publish and watch

Each automation has an activity view showing every run, which conditions passed, and where a run stopped. For the first day of a new flow, this is the thing to check — not your inbox.

What to look for:

• No runs at all. A condition is blocking everything, usually a keyword list that does not match real phrasing.
• Runs that stop early. The view names the step. Often a lookup whose failure branch was never wired.
• Runs that complete but customers reply confused. A copy problem, not a logic one.

Publishing safely

Three habits that reduce the blast radius:

1. Publish the narrow version first. A keyword rule with three specific keywords is safer to launch than a catch-all that answers everything.
2. Publish early in your working day, not last thing before a weekend. If it is wrong, you want to be there.
3. Remember that editing a live flow changes nothing until you publish again. A fix made at lunchtime is not protecting anyone at dinner unless you pressed the button.

Why a draft is genuinely safe

An unpublished automation does not run. That is also why installing a ready-made flow is safe — it arrives as a draft, and nothing reaches a customer until you have read every step and published it deliberately.

A related protection: a flow whose template step has no approved template selected cannot be published at all. The publish is blocked with an explanation rather than going live and failing silently — which matters, because a template mismatch produces error 132000 and the customer receives nothing.

What to re-test, and when

Automations rot quietly. Re-test when any of these change: a template's variables, your opening hours, a Google Sheet's column headings, your knowledge base content, or your team structure. All five break a flow without producing an error anywhere you would naturally look.

A twenty-minute pass through the simulator once a quarter is cheaper than the alternative, which is a customer telling you.

The seven things to deliberately do wrong

Happy-path testing proves almost nothing. The bugs live where a real customer does something you did not anticipate, so test those on purpose:

1. Answer a button question with typed text. Does the flow cope, or does it wait forever?
2. Send a photo where text is expected. Keyword conditions cannot read images, so this should route to a person.
3. Go silent halfway through. What is the customer left looking at?
4. Give a deliberately wrong order number. The lookup's failure branch should reach a human, not stop dead.
5. Type in lowercase with a misspelling. If your keywords only match perfect spelling, you want to know now.
6. Send three messages in a row. Does a cooldown stop the flow replying three times?
7. Answer 20 minutes late, after a colleague has replied manually. Does the bot talk over them?

That last one is the most common production bug in any WhatsApp automation, and the fix is a separate two-step flow — handing a chat from bot to human covers it.

Testing anything that needs a template

Flows triggered by a store or external event are harder to exercise, and it is worth being straight about why: they need a real event, and they send an approved template rather than free text. There is no way to fire a store event by hand.

Flow type	How to test it
Customer-message triggered	Simulator, then message your own number
Shopify order events	Place a real test order with your own number, then cancel it
External event	Have your developer post one test event with your number
Agent-message triggered	Reply from the inbox to a test conversation

Do the test order on a real product at a real price, because a £0.01 test order will not exercise the variables that carry a total. And remember that a template whose variable resolves empty is rejected outright with error 132000 — the customer gets nothing, which is exactly the failure a test order is meant to catch. See the error code guide.

Why a draft is genuinely safe to install

Two protections make experimenting cheap. An unpublished flow does not run at all, so an installed blueprint sits inert until you read it and publish deliberately. And a flow whose send step has no approved template selected cannot be published — the attempt is blocked with an explanation rather than going live and failing silently on real customers.

The practical consequence: you can install several ready-made flows, open each one, and decide what to keep, without any risk of messaging anyone. Nothing you do before pressing Publish reaches a customer.

Who should test it

Not only the person who built it. Whoever draws a flow knows what they meant it to do, and reads past the gaps for exactly that reason.

Give it to someone on your team who did not build it and ask them to break it, with no explanation of how it is supposed to work. They will type things you would never think to try, which is precisely what a customer will do. Ten minutes of that finds more than an hour of the author re-walking the happy path.

Keep a note of what you tested

A short list per flow — the paths you walked, the odd inputs you tried, the date — turns the quarterly re-test from an hour of rediscovery into fifteen minutes of repetition. It also tells the next person which cases already have coverage, so they can spend their attention on the ones that do not.

None of this needs a tool. A few lines in the automation's description field is enough, and it lives next to the thing it describes.

The habit that matters most

Test on a real phone before every publish, not only for new flows. A change that looks trivial in the builder — a reworded button, an extra step — is exactly the kind that renders badly or breaks a branch, and it takes two minutes to send yourself one message and check.

Two minutes, every publish, without exception.

Why an untested flow is an account risk, not just a bad experience

The reason to test properly is not only that customers see mistakes. It is that some mistakes feed the systems governing your account.

Meta's policy enforcement documentation describes a graduated ladder — a warning, then 1 to 3 day blocks on a message type, then 5, 7 or 30-day blocks on all messaging, then an appealable indefinite lock, then permanent removal — with spam, template misclassification and excessive negative user feedback among the named triggers. A flow that messages the same customer four times because it has no cooldown produces exactly that feedback.

The same applies to sending. Messages that fail because a variable resolved empty, or that arrive unwanted, do not simply disappear; they shape the quality rating that gates your messaging tier, which starts at 250 unique recipients per rolling 24 hours and rises through 2,000, 10,000 and 100,000 per Meta's messaging limits documentation.

Twenty minutes in the simulator is cheap insurance against a mechanism that is slow to notice a problem and slow to forgive it.