Branching a WhatsApp flow without losing anyone

A branch is a point where a flow takes one of several paths, and every branching step exposes its paths as separate exits on the canvas. The most important distinction in flow design is between steps that branch and steps that stop — because a stopper that fails ends the conversation without a word to the customer.

Steps that stop versus steps that branch

Step	Behaviour	What happens on failure
If Customer Message Contains	Stops	Flow ends silently — correct, since the message was not for this flow
If First Message	Stops	Flow ends silently
Check Customer Tags	Stops	Flow ends silently
Came From a Facebook Ad	Stops	Flow ends silently
Business Hours Check	Branches open / closed	Takes the other path
Time of Day Check	Branches before / after	Takes the other path
Has the Customer Replied?	Branches yes / no	Takes the other path
If Customer Info (Yes/No)	Branches yes / no	Takes the other path
Google Sheets / Call External API	Branches success / failure	Takes the failure path
Answer from Knowledge Base	Branches answered / unanswered	Takes the unanswered path

Silent stopping is right for a gate at the top of a flow. It is wrong anywhere after you have already spoken to the customer, because they are now mid-conversation and it just goes quiet.

The wiring mistake that strands people

A branching step with an unwired exit does not error. It simply has nowhere to go, and the customer — who has just answered a question or waited for a lookup — is left with silence.

The three that get left unwired most often:

1. The failure branch of a lookup. No matching row is a routine outcome, not an exception — customers mistype order numbers constantly.
2. The unanswered branch of a knowledge-base step. Also routine: it fires for anything your material does not cover.
3. The third option on a three-button question, usually because it was added last.

Two branches that do the same thing afterwards

Paths can merge. If your "Confirm" and "Cancel" branches both end by setting the conversation status, wire both into one status step rather than duplicating it.

This matters for maintenance more than for elegance. A duplicated step is a step someone will update on one branch and forget on the other, and the resulting inconsistency is invisible until a customer notices.

Flows are one-way

A flow is a chain that moves forward. It cannot loop back on itself to re-ask a question or return a customer to the main menu.

That constraint is worth designing around rather than fighting. If you want a customer to be able to start over, that is a fresh trigger — a keyword like "menu" matching a separate flow — not a loop inside the existing one.

Branching on something the AI worked out

The AI Check step does not branch by itself. It produces a result, and you follow it with a branch step that acts on the value. That two-step shape is deliberate: it keeps the decision visible on the canvas rather than hidden inside a prompt.

One rule about what you branch on: never let a model produce a number a customer is charged. Extraction is what models are good at; arithmetic is not. Use the calculation step for any total, deposit or discount — every automation step, explained covers both.

Keeping a flow readable

1. Name steps for what they do, not what they are. "Ask for the order number" beats "Ask Customer a Question".
2. End every path deliberately — a message, a handover, or an explicit End Automation.
3. Merge paths that converge rather than duplicating steps.
4. Keep it under about fifteen steps. A forty-step flow is usually two flows.
5. Use Auto-arrange after heavy editing so the shape matches the logic.

When to split into two flows

Two different jobs deserve two rules even when they serve the same customers. An always-on FAQ responder is not part of an order-confirmation flow; a win-back chase is not part of a shipping notification.

Bolting a second job onto an existing rule gives you one on/off switch and one version history for two unrelated things, so you cannot fix a bad FAQ answer without touching the flow that confirms orders. Separate rules all still run on the same customer message, so splitting costs nothing.

The opposite mistake is also real: three separate automations for returns, refunds and exchanges will all match "I want to return this for a refund", and the customer gets three replies. That is one job with three phrasings — one flow, three branches. Ordering and stop-after are covered in keyword triggers that actually match.

Branching does not change what you may send

Whichever path a customer takes, Meta's rules are the same. Free text works only inside an open 24-hour customer service window, per Meta's sending messages documentation, and a branch that sits behind a long delay may find the window closed by the time it runs.

So if any path in your flow waits 1,440 minutes or more before sending, that path needs a template rather than free text. This is the single most common way a well-drawn flow fails in production.

Branching on what you already know

Two steps let a flow take a different path depending on information you have stored about the customer, and the difference between them matters.

Step	If the information is missing	Use when
If Customer Info	Stops the flow	The flow is pointless without it
If Customer Info (Yes/No)	Takes the "no" path	You want to ask for it instead

The second is almost always the better choice in a customer-facing flow. "Do we already know their address? If yes, confirm it; if no, ask for it" is a good experience. Stopping silently because you do not have an address is not.

Branching by who sent the message

The From Number check branches on whether the sender is in a list you supply, which is how a flow can treat your own staff, a partner or a courier differently from a customer. Pair the "yes" path with a step that forwards the message to another team as an approved template, so it lands even with no open session.

Never invent numbers here. A list with a wrong number in it silently routes a customer down the staff path, which is the kind of bug nobody thinks to look for.

A worked example

Four paths, and every one of them ends somewhere a customer would find acceptable. That is the whole test.

A pre-publish checklist for any branching flow

1. Every exit on every branching step is wired.
2. Every path ends in a message, a handover or an explicit End Automation.
3. No variable is read on a path before the step that writes it.
4. Any path behind a delay of a day or more sends a template, not free text.
5. A person is reachable from anywhere in two taps.
6. Paths that converge share one step rather than duplicating it.

Point three is the subtle one. On a multi-path flow it is easy to reference {{contact.order_number}} on a branch that runs before the question that saves it, and the message goes out with a gap in it. Walking each path in the simulator catches it in seconds — see testing an automation safely.

How many branches is too many

A practical ceiling is 3 options on a question and about 15 steps in a flow. Past that, two things degrade at once: the customer has to read more than they will, and the flow becomes hard for you to reason about.

Remember the hard limit too — WhatsApp allows a maximum of 3 interactive buttons, so a fourth option means switching to a list and accepting the extra scroll. If you find yourself wanting 8 menu items, the top three usually cover most enquiries and the rest belong behind "Something else".

Branching does not extend the clock

One last constraint that catches people on long flows. The 24-hour customer service window is opened by the customer, not by your flow's progress through its branches — Meta's pricing documentation makes clear that only messages inside that window are free, and service conversations have been free and unlimited since 1 November 2024.

So a flow that branches five times over two days is not five separate opportunities to send free text. It is one window that closed somewhere in the middle, and the later branches need templates.