Home · Blog · Chatbot condition examples: eight branches almost every bot needs

Chatbot condition examples: eight branches almost every bot needs

November 5, 2026 · Command CHBT · Flows, Segments

Eight branches almost every bot needs, in the Condition block: a regular customer — Tag is set; a large budget — Variable “≥” with Number input validation; a city — in list; the channel — Channel “=” telegram; weekends — Day of the week in list 0, 6; a test result — points and “≥”; a number format — regex; an already known phone — is set. Below is the rule for each branch and the mistakes that make a branch silently fail.

Example 1. New or regular customer

Task: regulars get a short greeting and the menu right away, newcomers get an introduction to the company.

When a customer first gets to a request or a purchase, the flow sets Action → Add a tag customer.
At the start of the greeting flow — a Condition: a “Regular” branch with the rule Tag customer is set.
Otherwise — the branch for newcomers.

Why a tag and not a variable: variables live while the flow is running and are reset on a new start. A tag stays in the customer card forever — it is the right place for what the bot has to “remember” between conversations. How to build a tag system — in the article on tags.

Example 2. Budget above or below a threshold

Task: large requests go straight to a manager, small ones to the usual queue.

Data collection asks for the budget. In Input validation choose Number, in Save to variable — budget.
Condition: a “Large” branch — Variable budget “≥” 300000.
The “Large” branch leads to Action → Notify an operator and the Operator block, Otherwise — to the standard continuation.

It is convenient to keep the threshold round and clear to the team: “from 300,000 — straight to a senior manager”. If there are several thresholds — for example, up to 100,000, up to 300,000 and above — make three branches top to bottom from larger to smaller: “≥ 300000”, “≥ 100000”, Otherwise.

The Number validation matters: without it the customer writes “about 300 thousand”, and the “≥” comparison will not work — the variable will contain text, not a number.

Example 3. A city from a list

Task: delivery is available only in a few cities; the rest get pickup or a refusal.

A “We deliver” branch — Variable city in list Moscow, Khimki, Mytishchi, Korolyov.
Otherwise — “For now we deliver only in Moscow and nearby cities. You can pick it up yourself”.

“in list” compares the whole value with each comma-separated item. “moscow” in lower case will not match the list. It is more reliable to ask for the city with buttons and save the button’s value into the variable — then there will be no typos at all.

If there are many cities and you only need “we deliver or not”, a regex will also do — one pattern instead of a long list, case-insensitive: ^(moscow|khimki|mytishchi|korolyov)$. Then “Moscow”, “moscow” and “MOSCOW” land in the same branch.

Example 4. Different replies for different channels

Task: some features exist in only one channel. For example, a Telegram Stars invoice works only in Telegram, while MAX and VK customers need a link to the payment provider.

A “Telegram” branch — Channel “=” telegram → a Payment block with stars.
Otherwise → a Payment block with the provider.

Values of the Channel field: telegram, max, vk and web — the website chat. In the same way you can split links: in Telegram — to the channel, in MAX — to the MAX channel, on the website — to the catalog page. More about payment — in the article on accepting payment in a bot.

Example 5. Weekends and weekdays

Task: there are no managers on weekends, and the bot should honestly say when they will reply.

A “Weekend” branch — Day of the week in list 0, 6: Sunday is 0, Saturday is 6.
Otherwise — the usual handover to an operator.

In the “Weekend” branch the bot collects the question and the phone and promises a reply on Monday. Day of the week knows nothing about public holidays: before holidays change the branch text by hand. A branch by business hours is built on the Time field — a step-by-step breakdown with examples in the article on the bot outside business hours.

Example 6. A test or quiz result

Task: show a different result after a test of several questions.

After each answer — Action → Add points to the score variable: +1 for a correct answer or by a scale.
At the end — a Condition: an “Excellent” branch — score “≥” 8, a “Good” branch — score “≥” 5, Otherwise — “Room to grow”.

The order of branches decides everything here: “≥ 8” must be above “≥ 5”, otherwise 9 points will land in “Good” — branches are checked top to bottom. The same technique works for qualifying requests — in detail in the article on lead scoring.

Example 7. Checking that an answer looks right

Task: the customer entered an order number or a tax ID, and it needs to be checked by format before being passed on.

A six-digit order number — Variable order regex ^\d{6}$.
A tax ID — regex ^(\d{10}|\d{12})$.
An answer containing the word “urgent” — contains urgent.

Otherwise — a polite “Looks like the number is incomplete — please check and send it again” and a return to the question. So that the bot does not ask forever, count attempts with Add points into a tries variable and when tries “≥” 3 hand the conversation over to an operator. You do not need to check the phone and email this way: Data collection has its own Input validation for them.

Example 8. We already know the phone — do not ask again

Task: within one flow the phone may arrive earlier — for example, the customer left it in the first questionnaire — and asking for it a second time is awkward.

A “Has phone” branch — Variable phone is set → straight to the next step.
Otherwise → Data collection asking for the phone with Save to variable phone.

This works within one run of the flow: the variable is filled while the flow is running. To “remember” between conversations, set a tag after collecting the phone, for example has-phone, and check that instead.

Several rules in one branch

The most useful branches combine two or three rules. Example: an online store wants to offer regular Telegram buyers a private sale in its channel, and everyone else the usual catalog.

A “VIP in Telegram” branch: Tag customer is set and Channel “=” telegram and Tag vip is set.
A “Regular” branch: Tag customer is set.
Otherwise — the catalog for newcomers.

Note the order: the narrowest branch comes first. If you swap the first and second, VIP buyers will land in the general regulars branch — it fits them too and is checked earlier.

Why a branch does not fire

“≠” on a tag. For the Tag field only “=”, is set and is not set work. To check that a tag is absent, choose is not set.
A variable from a previous conversation. On a new flow start variables are reset. Long-term memory goes into tags.
The answer was not saved to a variable. Data collection writes the answer to the card, while Condition reads variables — fill in Save to variable.
Text instead of a number. “>”, “<”, “≥” and “≤” compare numbers — turn on Input validation Number.
A bad branch order. A broad branch above a narrow one takes everything.
An empty Otherwise. If no branch matched and Otherwise leads nowhere, the conversation stops.

How to test conditions

Open Check flow and go through each branch in turn: with a small and a large budget, with a city from the list and without, with a tag and without. The test chat uses its own test contact, so the easiest way to set the tag you need is with the same flow: temporarily add Action → Add a tag before the Condition and remove it after the check. It is handy to keep a short checklist: which values lead to which branch — and run through it after every edit of the conditions.

One peculiarity: the editor’s test chat works like the website chat, so Channel in it is always web. Test the Telegram, MAX and VK branches from a real messenger. More — in the article how to test a chatbot.

Conditions and branches Variables A chatbot after hours Tags as a segmentation system