Using conditions and variables to branch your chatbot conversations

Updated 2026-09-19 · 5 min read · By the Convo360 team

Why menus alone are not enough

A List Menu or Buttons block is fine when you are offering a fixed set of choices. But real conversations carry more context than a single tap: a contact's city, their stated budget, the language they replied in, or a value pulled from a webhook earlier in the flow. To act on that context, you need conditional logic rather than another layer of buttons.

A Condition block reads a variable and sends the contact down one of several paths. Everything downstream, the message tone, the offer, the team that gets notified, can differ per branch, without building separate flows for every scenario.

Think of it as the difference between a paper form and a receptionist. A form asks every visitor the same five questions in the same order. A good receptionist changes what she asks next based on the answer she just heard. Condition blocks give your bot that second behaviour.

Operators available in the Condition block

Convo360's Condition block supports the operators you would expect from a typed variable system:

• Equals / not equals: exact match, good for language codes or plan names.
• Contains: useful for free-text replies, such as checking if a message contains 'Mumbai' or 'urgent'.
• Greater than / less than / between: for number variables like budget or order value.
• Is empty / is not empty: to check whether a field was ever captured.
• Before / after: for date variables, such as a renewal date or event date.

Each Condition block can have multiple branches, so you are not limited to a simple yes/no split. A single block can fan out into five or six paths if your business logic genuinely needs that many, though for readability it is usually better to chain two smaller Condition blocks than build one very wide one.

Typed variables vs system variables

Convo360 supports typed variables, so a field you capture as a number behaves like a number, not text that happens to look like one. This matters when you branch on 'budget greater than ₹50,000' rather than doing a string comparison that breaks on '50000' vs '₹50,000'. A text-type variable holding '9' is not greater than '10' in string comparison, but a number-type variable is, so choosing the right type when you first create the variable saves you a debugging session later.

System variables such as {{phone}}, {{user_name}} and the channel a message came from are available in every flow without a Set Variable step. Combine both: capture a typed variable with Ask a Question, then branch with Condition, then personalise the reply using a system variable.

Date-type variables deserve a special mention because Indian businesses use them constantly: a policy renewal date, an EMI due date, an event date. Store these as Date variables rather than free text, so a Before/After condition can compare them correctly regardless of the format the customer originally typed the date in.

Common patterns worth copying

Three patterns cover most Indian business use cases:

• Language routing: Ask a Question with buttons for Hindi, English, Marathi and so on, store the reply in a variable, then use Condition to send the rest of the flow in the matching language.
• City-based routing: capture city as text, use Contains to match against known service cities, and route unmatched cities to a 'coming soon' branch with a waitlist form.
• Budget qualification: capture budget as a number, and use Between to split leads into low, mid and high tiers, each going to a different offer or a Save CRM Lead step tagged for the sales team.

A fourth pattern worth adding once you are comfortable with the basics is returning-contact routing: check a system variable or a custom field set on an earlier visit (for example has_ordered_before) and skip the introductory questions entirely for repeat contacts, taking them straight to a shorter, faster path.

Building it on Convo360

1. In Flow Builder, add an Ask a Question block and set its answer to store in a typed variable, for example a Number variable named budget.
2. Drag a Condition block right after it.
3. Add branches: e.g. budget less than 50000, budget between 50000 and 200000, budget greater than 200000.
4. On each branch, continue with an AI Reply, Send Message or Save CRM Lead block suited to that tier.
5. Use Set Variable anywhere upstream to normalise data, for example converting a free-text city reply into a standard value before the Condition block checks it.
6. Label each branch clearly on the canvas (Low / Mid / High, not Branch 1 / Branch 2 / Branch 3) so a colleague editing the flow six months later understands the logic at a glance.

Testing every branch before you publish

A flow with three or four Condition branches can hide a dead end you never noticed. Before publishing, open Preview / Try-it and manually walk through each branch with different sample values. Convo360's health checks also flag branches that lead nowhere, which is the most common mistake with conditional flows.

Keep drafts separate from the published version so you can test freely; only publish once every branch has been walked through at least once. It helps to keep a short written list of test values, for example budget 10000, 80000 and 500000, so anyone re-testing the flow after a change covers the same ground you did the first time.

Mistakes that break conditional flows in practice

The most common failure is a missing default or 'else' branch: a Condition block with only two explicit paths silently drops any reply that matches neither, and the contact never hears back. The second most common is comparing a number stored as text, which makes 'greater than' behave unpredictably. The third is nesting conditions too deep without labelling branches, which turns the canvas into something only the original builder can follow. Reviewing a flow's Flow Logs after a week live will show you exactly which branch real contacts are landing on most, and whether that matches what you expected when you designed it.

Step by step

1. Capture the variableUse Ask a Question to collect a reply and store it as a typed variable (text, number or date).
2. Add a Condition blockDrag Condition after the capture step and choose the variable you want to branch on.
3. Define branches with operatorsAdd as many branches as you need using equals, contains, greater-than or between.
4. Build each branchContinue each branch with the messages, AI Reply or CRM steps appropriate to that path.
5. Test in PreviewWalk through every branch with different sample answers using Try-it dry run.
6. Publish and monitorPublish the flow and check Flow Logs for the first few days to confirm contacts land on the right branch.

Example conversation

Frequently asked questions

Related reading

Available across India — see WhatsApp & AI calling automation by state and city.