Website Chatbot Question Tree: How to Branch It

Why one script never fits

Most website chatbot projects begin with a single script: a greeting, two or three questions, a request for contact details. It works for a week, because the person who wrote it had one typical visitor in mind. By week two, the transcripts show that the typical visitor accounts for perhaps a third of conversations.

The rest are other people. Someone who has been on the pricing page for twenty minutes and types 'how much per month?'. Someone who arrived from a blog post with a general question. An existing customer who ordered last week and wants to know where it is. A competitor doing research. A single script asks all of them the same second question, and it is wrong for at least three of them.

Notice that the problem is not the number of questions. A bot asking five is no better than one asking two, if the second question does not depend on the answer to the first and on where the visitor is standing. A question tree is precisely the machinery that makes it depend on those things.

The tree's three inputs

In practice a question tree starts from three pieces of information, all available before the conversation begins or within its first message. Keeping them separate matters, because each opens a different branch.

1. 1Page context — where is the visitor right now?Pricing page, a specific product page, 'about us', a blog post, the checkout. This is the cheapest and most reliable intent signal available, because it costs the visitor nothing to give. A conversation opened on a checkout page that begins with 'what are you interested in?' is a wasted opening — there is almost always a specific obstacle there.
2. 2Opening message — what did they type?The first sentence usually declares the intent by itself. 'Price', 'how does it work', 'my order', 'are you hiring', 'complaint' — five different branches, none of which wants another's second question. The bot's first job is to classify that message, and its second is to answer it.
3. 3History — has this person been here before?For a returning visitor or a recognised customer, the tree starts somewhere else entirely. Asking them again for their name, their industry and their problem is one of the most complaint-generating behaviours available, because it announces plainly that the system does not know them.

These three inputs overlap, and the order of precedence has to be written down in advance. The general rule: a known-customer signal overrides everything, an explicit intent in the opening message overrides page context, and page context is what you use when nothing else is known.

Five branches and each one's second question

Five branches are enough for most sites. Building more is tempting and almost always a mistake — the sixth branch is usually the one that never fires, but still has to be maintained on every change.

• Sales intent — pricing, capability, comparison questions. Second question: one open question about the problem. The goal is not a phone number; it is a sentence the CRM can hold.
• Support intent — an existing order, an account, a technical fault. Second question: identification, such as an order number or phone. Asking a sales question here is the worst available move.
• Information intent — 'how does it work', general questions, arrivals from the blog. No second question is asked; an answer is given and the conversation is left open. Trying to qualify too early on this branch drives visitors away.
• Unrelated intent — job applications, partnerships, press, student research. No second question; the right address is given and the conversation closes politely. This is the branch that removes wasted calls.
• Complaint or dissatisfaction. No second question; route to a person immediately or queue it. Any qualification question put to an angry person makes the situation worse.

Example: a conversation from the pricing page

The sequence below is the shape of a real conversation opened on a pricing page. Note that contact details are requested only on the fifth move, by which point the visitor has received two useful answers.

1. 1Visitor: 'How much is it per month?'The bot states the published pricing structure — either the figure, or what the figure depends on. 'Let us prepare a quote for you' is not an answer to that question, and it ends a large share of conversations right there.
2. 2Bot: 'It depends on how many channels you connect and your monthly conversation volume. Which channels are you receiving messages on now?'This question sharpens the price and establishes fit at the same time. The visitor answers because it is useful to them, not because they are being qualified.
3. 3Visitor: 'Instagram and WhatsApp. About 50-60 messages a day.'The bot now has both scale and channel. Two fields are extracted and written to the record. No form has been filled in.
4. 4Bot: narrows the figure, then: 'Is this something you are looking at this month, or still at the research stage?'The timing question. Two options, both acceptable. The answer decides how the queue is sorted.
5. 5Bot: 'We can show you what it looks like on your channels in a short call. What number should we use?'The contact request arrives only now, and reads as the natural continuation of a conversation already in progress. Asked earlier, it would have replaced the pricing answer in move two.

In none of those five moves does the bot ask 'what is your name?'. The name comes from the transcript or the subsequent call. An early name question solves nothing and announces that the conversation is a form.

The routing table: where each branch ends

The second half of a question tree is routing. Every branch's endpoint has to be written down, because an undefined endpoint means 'nowhere' in practice.

• Sales intent + near-term timing + good fit → immediate notification to the sales group, high priority in the callback queue.
• Sales intent + distant timing → written to the CRM, no notification, added to a nurture list. Calling this branch burns the team's week.
• Sales intent + poor fit → closed politely, no lead created. The absence of this branch is the main source of wasted calls.
• Support intent → the support queue, with no sales notification. One conversation landing in both queues means two people message the same customer.
• Complaint → a person immediately, or a prioritised morning queue if it is out of hours.
• Unrelated → answered, and placed in no queue at all.

The table should have few rows, but every row needs a named owner. A row without one becomes a silent queue within a few weeks, and nobody notices, because nobody is looking at it.

What data and integrations it needs

A question tree is configuration rather than code. But four things have to exist underneath it.

• Material the bot can answer from: pricing logic, product and service descriptions, what is and is not supported, delivery times. Without the answer in move two, the rest of the tree never runs.
• Page context passed to the bot. The widget needs to know which URL it was opened on — the cheapest intent signal there is, and the one most often left unconnected.
• Customer recognition, matched on phone or email. Without it, the 'returning customer' branch does not exist.
• A destination for the result: a CRM record, a notification to the sales group, or both — with the transcript attached, so whoever picks it up does not start from zero.

What is not on that list is a separate machine-learning model for intent classification. For most sites, keywords in the opening message plus page context are enough to separate five branches; a heavier classifier is something you add when volume demands it, not before.

When the AI is enough, and when it is not

One of the most important branches in the tree is the one that leaves it. In four situations the bot should stop and hand the conversation to a person.

• An explicit request for a human — immediately, without asking why and without a counter-offer.
• The start of a commercial negotiation: discounts, special terms, contracts. The bot can state published pricing; it must not bargain around it.
• A visible complaint or open dissatisfaction.
• Anything the material does not cover. The right behaviour is to say so and offer a person; a plausible invented answer is an expensive mistake on a compliance or legal question in particular.

The conversation itself has to travel with the handover. If the operator cannot see what was said, the customer repeats everything, and the automation has added a step rather than removed one.

What to measure

Counting conversations tells you nothing about a question tree. Four figures show exactly where it breaks.

1. 1Branch distributionWhat share of conversations lands on each branch. A sharp divergence from expectation usually means classification is misfiring, or that one branch is drawn far too widely.
2. 2Completion by branchHow many conversations on each branch reach its endpoint. A sharply low figure on one branch points at a specific question in that branch — usually a contact request that comes too early.
3. 3Misroute rateSales conversations landing in the support queue and the reverse. This can only be measured if operators record it, so recording it has to be as easy as one button.
4. 4Repeat-question rateConversations where the bot asked for something the visitor had already said. It is the most direct sign that the tree's memory is not working, and the most common cause of abandonment.

Reading the abandoned conversations once a month teaches more than all four numbers. The stopping point is almost always one specific question, and it is usually fixed by moving that question one step later.

Common mistakes

• Asking a question immediately after the greeting. The bot wants something before it has given anything, and the largest single drop-off happens right there.
• Putting the same contact request in the same place on every branch. On the support branch a phone number is identification; on the sales branch it is continuation. Same question, different moment.
• Building too many branches. A ten-branch tree is in practice three live branches and seven dead ones, all ten of which must be checked on every change.
• Not using page context. The cheapest signal is the most frequently forgotten one.
• Failing to recognise a returning customer — the most conspicuous way to demonstrate that the system has no memory.
• Building the tree once and leaving it. The product changes, pricing changes, the season changes, and a branch that was right six months ago now gives the wrong answer.

How this is built in Vexvon

In Vexvon, the answering half of the tree runs from the knowledge base: your site crawled to as many as 4,500 pages, PDFs up to 25 MB, a product catalogue with variants and images, and entries added manually or in bulk at up to 200 per request. Material is organised into thirteen types — FAQ, pricing, product, catalogue, branch, campaign, opening hours, policy and others — which is what lets different branches answer from different sets of material.

The website widget supports anonymous conversations, streamed replies, speech-to-text on voice messages and image input, with a switch to a live operator from inside the conversation. Its rate limits are 20 per minute and 300 per day. Conversation memory covers the last fifteen messages, and query rebuilding turns a fragment like 'what about the red one?' into a complete query — the mechanism that reduces the repeat-question problem.

On the routing side, phone numbers are detected through a five-stage process, a buyer-intent filter removes false signals before a lead is created, and the company's own numbers are excluded. A lead that is created goes to the sales group as a Telegram notification with a Start button, enters the built-in CRM's nine-stage pipeline, or is pushed to Bitrix24.

There are three routes to operator involvement: an explicit visitor request raises a notification, a stop character typed by an agent pauses the AI on that conversation for thirty minutes, and the AI can be switched off for a conversation entirely. None of the three is silent — all are written to the log.

Frequently asked questions

1. 1What is the difference between a question tree and a script?A script asks its questions in a fixed order. In a question tree the next question depends on the previous answer, on the page the visitor is on, and on whether they are recognised. The practical difference is that a tree does not ask what it already knows.
2. 2How many branches should there be?Five for most sites: sales, support, information, unrelated and complaint. Add a sixth only when you are confident it will receive several conversations a week.
3. 3When should the bot ask for a name and phone number?The phone at the end of the sales branch, and at the start of the support branch where it is identification. The name often need not be asked at all — it comes from the call or the transcript.
4. 4What integrations are required?Material for the bot to answer from, a widget that passes the page URL, customer recognition on phone or email, and a CRM or notification channel for the result.
5. 5How do you measure a question tree?Branch distribution, completion by branch, misroute rate and repeat-question rate. Total conversation count replaces none of those four.
6. 6When should a person join?On an explicit request, in a commercial negotiation, on a complaint, and whenever the material does not cover the question. The operator must be able to see the conversation so far.

Start from your own transcripts

Do not design the tree on a blank page. Take last month's conversations, assign each one to one of the five branches above, and count how many landed on each. The distribution usually differs from what you expected, and that number alone tells you which branch actually matters.