Home · Blog · Bot script: conversation map, branches, dead ends and access to the operator
Bot script: conversation map, branches, dead ends and access to the operator
A bad bot script can be recognized by one response: “I didn’t understand you, select a menu item.” Good - because the client reaches the result in three clicks and does not notice that he was talking to the program. The difference between them is laid not in the constructor, but before it: on the sheet of paper where the conversation map is drawn. Below is a method for designing a script from the goal to the text of the buttons, with binding to blocks and triggers CHBT and to two editor modes - “Steps” and “Canvas”. Suitable for recording, requests, support and any conversation where there is a beginning and an end.
The end comes first: purpose and “successful exit”
The script is designed from the last message. What needs to happen for the conversation to be considered successful? There are few options: you have contact with the phone; the client received an answer and left satisfied; the conversation is transferred to the employee with clear context; the person signed up. One goal per flow - if there are two goals, these are two flows with different triggers in one bot.
Each goal has its own “successful exit”, a specific block at which the conversation ends correctly:
- Contact - block “Data collection” with a phone number, then “Message” with confirmation “Thank you, {{name}}, we will call you back before 18:00.” The result is visible in the “Contacts” section.
- The answer to a question is a “Message” with an answer and two buttons: “Helped” and “Ask another question.” Without the second button, you won't know that the answer didn't help.
- Transfer to a person - the “Operator” block, in front of which the bot said what it was doing: “I am passing it on to the administrator, he will answer within 15 minutes.”
Everything else in the script is a path to this block, and each branch either leads to it or to a statement. A branch that leads neither here nor there is a dead end; about them below. A metric also appears here: the proportion of conversations that reach a successful exit. It is convenient to consider it in CHBT as a tag - before the final block put “Action” → “Add tag” goal achieved, and after a week the filter in “Contacts” will show the number.
Raw materials: 50 real messages instead of brainstorming
The bot's menu, conceived at the table, reflects how the company thinks about itself, not how customers ask. Therefore, the second step is to unload the last 50-100 incoming messages from personal messages, mail and chat on the site and arrange them in piles.
Layout rules:
- The stack is an intention, not a word. “How much does a haircut cost”, “is there a price?”, “What are the prices” - one “Prices” pile.
- Stacks the size of one message are merged into “Another question” - for them there will be an operator or AI agent.
- The thickest stacks are the first level of the menu. If there are 12 thick stacks, you have two flows, not one.
- Inside each stack, write down the client's wording verbatim - it will become the text of the button. Clients write “make an appointment”, not “make a visit”.
A byproduct of the layout is a list of keywords for the "Keyword" trigger: if a person writes "price" instead of clicking a button, the price script should fire anyway. And one more - a draft knowledge base, if you decide to add it later AI agent for free questions: The “Other Question” pile will show what exactly he will be asked about.
Conversation map: tree no deeper than three clicks
The map is a tree where the nodes are bot messages, and the edges are buttons and client responses. Draw on paper or any diagram; transfer to the constructor is too early.
Rules that check the card before assembly:
- Three clicks until result. From greeting to successful exit - no more than three buttons. The client does not pass the fourth level of the menu.
- No more than six buttons on the screen. In Telegram and MAX, a long list of buttons stretches the screen, in VK the limit is 10 buttons, two in a row, but the first ones are readable four to six. More - divide into two screens.
- There is a way back from each node - “To the menu” or “Back” button. Otherwise, the client who pressed the wrong thing gets stuck.
- Each leaf of the tree has either a successful exit or an “Operator”. A sheet with a message without buttons and without a question is a dead end.
In CHBT, the map is transferred to one of two editor modes. “Steps” - linear list of blocks, available on all Plans; Suitable for chain flows: greeting → question → question → confirmation. “Canvas” (from the Basic plan) - a diagram with blocks and connections, where a paper tree is drawn one to one: a branch from each button is visible as a line. It’s possible to put together an extensive support menu in “Steps,” but it’s hard to read after a month; if the tree is wider than three branches, this is an argument for “Canvas”. Place large branches in the “Subflow” block - a nested script that looks like one “Record” node on the map and is expanded separately.
Input: what trigger runs the script
A trigger is an event that starts a script, and there are usually several of them in a bot project. One bot in CHBT holds several scripts with different triggers; When designing, define one for each entrance.
| Trigger | When to bet | Example |
|---|---|---|
| /start command | Main entrance by default; in the widget it corresponds to “Open widget” | Welcome and first level menu |
| Keyword | The client writes in text what is on the menu | “price”, “price”, “cost” → price flow; "contains" mode |
| Deeplink | You need to know the source or immediately lead to the right thread | t.me/bot?start=qr from packaging → buyer flow, bypassing the menu |
| Pressing a button | A button from another flow leads here | The “Register” button in the FAQ launches the recording script |
| Any message | Insurance: everything that is not included in other triggers | Time condition → operator or “we’ll answer in the morning” |
| Incoming webhook | The script is run by an external system | The payment took place in your system → “Transaction in CRM” and “Notify operator”; such a script is not written to a client in Telegram or MAX |
The order of priority is simple: exact triggers (/start, deep link, button) → keywords → “Any message”. The latter should be in every bot - without it, a message past the menu remains unanswered, and this is the worst of dead ends: the client does not even understand that the bot did not hear him. There is also an “Intent” trigger - AI text classification; it comes in handy when there are too many keywords and they begin to overlap.
Branching: buttons, free text or “Condition”
There are three ways to split into branches in the map, and each has its own price.
Buttons in the “Message” block. The most reliable way: the client cannot make a mistake in the wording. Use wherever there are a finite number of options: services, branches, topics. In Telegram, a button can be of two types - lead through a script thread or open a link (map, website, payment page).
Free response via Data Collection. When there are infinitely many options: name, phone number, convenient time, address. The block waits for a response, checks the format (phone, e-mail, number) and if there is a discrepancy, asks again with your “Text on error” - as many times as indicated in the “Attempts” field (three by default), and after the last failure it goes further according to the script without a saved value. Therefore, when designing, for each such block, write the text if there is an error with the output and decide what is the next block if there is still no data: “The number is missing numbers - write like this: +7 900 000-00-00, or write “operator”” - the standard “try again” does not explain what is wrong and does not give a way out.
Block "Condition". Branching without the participation of the client is based on the fact that the bot already knows: whether there is a “client” tag, whether the variable is filled in, what channel the person came from, what time and day of the week it is. The branches are named, each has its own output, the rules within the branch are added by “AND”; everything that doesn’t fit goes into “Otherwise”. Typical applications: do not ask a regular customer a question about his name; at night, do not promise “we will answer in 15 minutes”; in the widget it offers a file, in MAX it doesn’t. Comparison operators - equal, not equal, contains, greater than, less than, regular expression, "in list", "exists" - are described in information on terms and conditions.
Selection rule: if the decision is made by the client - buttons; if the bot knows the answer itself - “Condition”; free text - only for data that cannot be listed. Randomization also applies to branching: “Action” → “Random branch” divides the stream in half to test two versions of the text, but more on this in the section on the test.
Deadlocks and operator access: one rule for each sheet
Deadlock - a node after which the client does not understand what to do next, and the bot does not expect anything. On the map, he is searched for with one question for each leaf of the tree: “what does a person see and can click after that?” Hence the design rule: each sheet is either a successful exit from the first section or the “Operator” block. A message without buttons and without a next block, a thread without “Back”, a drawn button without a script behind it - three types of sheets that are traced on paper and not transferred to the editor while they are hanging. “Operator” is not a spare node in the corner of the map, but a point to which edges from each menu level converge: the “Another question” button on each screen, a separate script for the word “operator” (it also works inside “Data collection”) and “Any message” as insurance; in front of the block itself - “Message” with an honest expectation (“we respond during business hours in 10–15 minutes”) and, if there are no operators at night, “Condition” for an hour with a different text. How each of the paths to a person is structured, what the operator sees in “Conversations” and how the conversation is returned to the bot - in the article about transferring the conversation to the operator; what else breaks in the already collected flows - silence without “Any message”, sheets of text, transmission at night without warning - in the analysis of 10 errors in bot scripts. Here we remain at the map level: traversing a tree of 20 nodes takes 10 minutes and is cheaper than any edit after launch.
Texts of messages and buttons
Texts are written after the map, not instead of it. Several rules tested on conversations in instant messengers.
| Rule | Bad | Okay |
|---|---|---|
| Message – up to 300–400 characters, one paragraph | Company history on screen | “Haircut from 1,500 ₽, coloring from 3,500 ₽. The master will name the exact price after inspection. Should I sign you up?" |
| Button - verb or noun, up to 20 characters | "Click to find out about our prices" | "Prices" |
| The button speaks in the customer's words | "Make a visit" | "Sign up" |
| The question explains why | “Your phone?” | “Where should I send confirmation? Write your phone number" |
| Confirmation repeats data | “Thank you, lead accepted” | “Thank you, {{name}}! We made an appointment for Thursday, we’ll call {{phone}} in an hour.” |
| Input error explains what's wrong | "Invalid format" | “There are not enough numbers in the number - write this: +7 900 000-00-00” |
Variables {{name}}, {{phone}}, {{email}} and their fields are substituted in any message - details in help on variables. One limitation that affects texts: in Telegram, MAX and VK, the CHBT bot sends only text and buttons, without pictures and files. Price in PDF is a URL button for a file in the cloud; photo of works - link to the site. You can send files in the widget on the website.
Greeting is a separate topic with its own formula and options for the task, discussed in the article about the bot's first message. The rule here is enough: two lines about who you are and what the bot can do, and then a menu. A long greeting with the history of the company is the first dead end of the script, because they don’t finish reading it.
Test, launch and fine-tuning of conversations
The script does not end with the build. A procedure for testing and fine-tuning that takes less time than it seems.
- “Check script” in the editor: go through each branch to the end, enter the wrong phone number, write text past the menu. We are looking for dead ends from the section above.
- Test from phone in each channel: length of messages, type of buttons, deep link with a label, inclusion of a conversation in “Dialogs” and a contact in “Contacts”.
- First 20 conversations - read in full. Where the client wrote in text instead of a button, a button or keyword is needed. Where there is a break in the bot message is a dead end. Where we reached the operator with a typical question - the missing thread.
- Edit without fear. Autosave and version history with rollback: they changed the text, it got worse - they returned it. For major reworks - a duplicate of the script: edit the copy, include it instead of the original.
- Two text options. "Action" → "Random thread" splits the stream into two branches with different wordings; each branch has its own tag. A week later, the tags in “Contacts” show which one brought more people to the goal. There are no block counters in Analytics - tags replace them.
Ready-made flows designed according to this scheme are available in templates - for example, “Support” with a short menu and quick transfer to a person or “Collection of applications”, sorted into separate article. If the script is designed for the first bot, the entire route from task to launch is in the article how to create a chatbot without a programmer. The drawn map can be transferred to the editor in an evening: open the designer and build the script →
“Support” templateHelp: conditions and branchesHelp: Variables and FieldsHow to create a chatbot without a programmerPush-button, AI or hybrid