Home · Blog · How to test a chatbot before launch: test chat, checklist and a check in the messenger

How to test a chatbot before launch: test chat, checklist and a check in the messenger

November 5, 2026 · Command CHBT · Flows, Start

A bot nobody has checked breaks on the very first customer: a button leads nowhere, a phone with spaces is rejected, at night the conversation goes to an operator who is not there. The good news is that almost all of this can be caught in half an hour before launch. Here is how flow checking works in CHBT, what the test chat does for real, what it deliberately skips and what is still worth checking in a live messenger.

The Check flow test chat

The flow editor has a Check flow button. It opens the Checking the flow window — a chat with your bot right in the dashboard. The flow runs on the real engine, but only you see the replies: nothing is sent to customers.

Write to the bot as a customer and tap buttons — they arrive in the test chat just as in the messenger.
Start again resets the conversation so you can go through another path from the beginning.
Launch as via link or QR starts the flow as if the person came via a link with a label. The text in the field is the link label and can be left empty. This is how you check branches for different sources: ads, a package insert, a post.

The test chat does not use up the plan’s conversation limit: check as much as you need.

What works for real in the test

Messages, buttons, transitions — exactly as the customer will see them.
Condition — branches are chosen by real data: tags, variables, channel, time and day of the week. If it is night now, the bot goes to the night branch.
Collect data — with format validation, Error message and attempts.
Tags and variables — are set on the test contact, and you can rely on them further in the flow.
Random branch — picks a variant at random, so go through the flow several times to check both branches.
AI nodes — answer for real and spend AI credits. This is shown in the test chat caption.

What the test deliberately skips

Some steps are risky to run for real in a test: they change something outside the dashboard. The test chat skips them and after the reply writes “Skipped during the test: …” with a list.

HTTP request — is not sent, the response variable stays empty.
CRM deal and marketplace requests — are not created or sent.
Delay — does not wait, the bot moves on right away. Convenient: you see the whole chain after the delay.
Reply in comments — needs a real comment under a post.
Payment — no payment is created, the step goes to Error with a note that this is a test conversation.
The Operator block — the conversation does not go to the team: no push, emails or automatic assignment.
The new request email — is not sent, even if you entered a phone.

So the Paid branches, responses from external systems and the operators’ work have to be checked separately — more on that below.

Pre-launch checklist

Every button leads somewhere. Go through all buttons of the first message and the menu.
No dead ends. At the end of each branch the customer understands what is next: “Thank you, we will call back”, the menu or an operator.
Collect data accepts real answers. Enter a phone with spaces and brackets, with “+7” and with “8”. Enter nonsense — check the Error message.
There is a branch after the attempts run out. Make three mistakes — the bot should not thank you for a request that does not exist.
The night branch. Temporarily shift the working hours boundary in the Condition and check the reply after hours. Do not forget to put it back.
Variables are inserted. Nowhere do you see {{name}} instead of a name.
The payment Error branch is not empty. In the test it will fire — look at what the customer will see.
Links with labels. Launch as via link or QR for every label you hand out.
AI answers to the point. Ask 5–10 real customer questions, including awkward ones.
Texts read well on a phone. Long paragraphs look like a wall in a messenger — split them into short messages.
Data consent. Before collecting the phone there is a notice with a link to the policy.
A version is saved. Before launch — Save version in Version history.

Checking in a real messenger

The test chat checks the logic, not the channel. Before launch go through the flow yourself in Telegram, MAX or VK — wherever your customers will be:

how buttons and long messages look on a phone;
whether links and the payment page open;
whether the operator gets a push when the bot hands over the conversation, and whether the conversation appears in Conversations;
whether the request email arrives after the first phone;
the Paid branch — with a real payment for a small amount, for example 1 ₽ in a test flow.

This run takes 10 minutes and catches what the test chat cannot see by definition: channel settings, notifications and external systems.

Ask someone else to go through the bot

The author of a flow knows which button to press and unconsciously follows the “right” path. A fresh person will do what you did not expect: write text instead of tapping a button, answer “I don’t know”, go back. Give a colleague or a friend the bot link without explanations and look at the conversation in Conversations: where the person got stuck, where they asked again, where they left. Three to five such runs are worth a week of arguments about the flow.

Version history: editing without fear

A working bot is scary to touch: what if it breaks. That is what Version history in the editor is for — “Save checkpoints and return to them”. Before a big edit press Save version. If something goes wrong after the changes, return to the saved checkpoint.

A good habit: save a version before every ad launch, A/B test and seasonal text edit — then a rollback takes a minute.

The first days after launch

Read the conversations. In the first days open 20–30 real conversations in Conversations. The best source of edits is what customers type instead of tapping buttons.
See where people leave. The bot funnel shows the step after which most conversations break off. How to read it — in the article on chatbot metrics.
Check delivery. If messages do not arrive, causes and fixes are in the article why a bot broadcast is not delivered.
Edit in small steps. One edit — one check in the test chat — a saved version.

Typical mistakes a check finds

A dangling button. The button was added, but the transition was forgotten — the customer taps it and nothing happens.
A loop. A branch returns the person to the menu they just came from, and the conversation goes in circles.
An empty variable. “Thank you, {{name}}!” before the name was asked.
An overly strict format. The example in the text demands one number format, but people write it in different ways.
An operator at night. The bot hands the conversation to a person at any time, and the customer waits until morning.
An old link label. A link with a label was handed out, but no branch was made for it — the person ends up in the general flow.

All these mistakes show up in the test chat in a couple of passes, but on live customers they cost requests.

Who on the team checks the bot

Flows are edited by the project owner and admins; an operator has no access to the editor. But operators are the best testers: they know what customers actually ask about. A convenient setup: the admin edits the flow and checks it in the test chat, while operators go through the bot in the messenger and write in notes where it answered off the mark. That way edits are based on real questions, not on the flow author’s guesses.

Flow editor Chatbot metrics A/B testing a chatbot Accepting payments in a chatbot