Branching

Branching is where pathways earn their keep, and where most of them go wrong. The mechanics are simple; the discipline is in the wording.

The line is the condition

When you connect two steps, the label on that line is what tells the agent when to take it. The agent reads your labels and picks the one that matches what just happened.

12

1. 1Caller wants information — this path answers and stops.
2. 2Caller wants us on site — this path qualifies and books.

The label is edited on the line itself, and it's the only thing on there:

1

1. 1Be specific. This sentence is the entire instruction the agent gets.

That means labels are instructions, not decoration:

Two rules follow from this:

1. Never leave a line unlabelled when a step has more than one way out. The agent is guessing.
2. Make labels mutually exclusive. If two labels could both plausibly describe the same answer, you've built a coin flip. "Caller is interested" and "Caller wants more information" overlap badly — merge them, or sharpen the distinction until a reader could sort answers into one or the other without hesitating.

Opposites make the best labels

There's a reliable way to get rule 2 right: write the pair as opposites. If one label is the negation of the other, no answer can fit both, and there's no gap between them for an answer to fall into.

When a step has three or more ways out, the same test still applies to every pair: take any two labels and ask whether one answer could reasonably be filed under both. If it could, you've found the branch that will misfire.

Drawn out, a well-labelled fork looks like this — each way out says what the caller did, not which option it is:

Are you an existing customer?Route

Existing customer

Look up their accountCustom Tool

New customer

Collect their detailsDefault

Caller isn't sure

Check by phone numberCustom Tool

When to use a Route step instead

Hanging labelled lines off a Default step works well for two or three ways out. When branching is the actual purpose of the moment — sorting callers by department, by product, by eligibility — use a Route step. It keeps the decision in one obvious place, and it takes a fallback path for anything that matches nothing.

Always set the fallback. It's the difference between "I'm not sure I follow — let me get someone who can help" and a conversation that dead-ends.

Branching on what came back

Steps that reach outside the conversation — Custom Tool, Webhook — can branch on their result. This is how you handle the real world:

• Order found → confirm the details. Not found → offer to take a message.
• Slots available → offer them. None → route to the waitlist.
• Lookup failed → apologise and transfer, rather than pretending.

Always build the unhappy path. Systems are down sometimes, and a caller hearing dead air while the agent waits for a response that never comes is the worst outcome in the product.

Capture before you branch

If a branch depends on knowing something — an account number, whether they're a current customer, which location they mean — make sure an earlier step actually asked. Pathways commonly fail because the decision point arrives before the information does. Reading yours top to bottom and asking "does the agent know this yet?" at each branch catches nearly all of these.

When the information is genuinely required, don't rely on the caller volunteering it — put a loop condition on the step that collects it, so the agent won't move on without it. See Inside a step.

Don't branch for things that happen everywhere

A question that could come up at any moment — pricing, hours, "can I speak to someone?" — should not be a branch off every step. That's what global steps are for: one step, reachable from anywhere, that answers and hands the conversation back. Building those as ordinary branches is the most common cause of an unreadable canvas.

Common mistakes

• Too many branches too early. Sort callers into two or three groups first, then refine inside each. A step with nine ways out is unreadable and unreliable.
• Branching on things that don't change the conversation. If both paths say the same thing, you don't need a branch.
• No way back. A caller who takes a wrong turn should be able to get where they meant to go. Add a path back to the main line rather than a dead end.
• Assuming a clean answer. People reply "yeah I guess so" and "well, sort of". Labels written as full descriptions of intent handle that far better than "yes" and "no".
• Labels that point somewhere else. "The second option listed above" or "matches the department the caller picked" gives the agent nothing to match against — it reads each label on its own, with none of the surrounding context. Write the condition out in full on the label.
• Branching where a prompt would do. If a fork exists only because two things get asked, it doesn't need to be a fork. How many steps do you need? is the fuller version of this.

Prove it

Branching is exactly what automated tests are for — a simulated caller who gives an ambiguous answer will find your overlapping labels immediately, and much more cheaply than a real customer will. Write one test per branch: Testing your pathway.