Chatbot Decision Tree: How to Plan Conditional Flows

A chatbot decision tree is a map of every path a scripted conversation can take. Each question is a fork; each answer sends the visitor down a branch to the next message, another question, a person on your team, or the end of the chat. To build one, you define the goal, list the questions, save each answer, and write IF/ELSE conditions that decide where each answer leads.

Decision trees are the backbone of rule-based chatbots, and they're the reason those bots are predictable: you know exactly what the bot will say, because you wrote every branch. This guide shows you how to plan one on paper first, then build it without code.

The building blocks of a decision tree

Almost every no-code chatbot builder uses some version of these pieces:

The variable is the piece that turns a list of questions into a real decision tree. Once an answer is stored, you can branch on it anywhere later in the flow, not just right after the question, and you can reuse it in messages ("Thanks, {{name}}").

Step 1: Pick one goal per flow

Decision trees get messy when one flow tries to do everything. Choose a single primary goal:

• Triage: figure out what the visitor wants and send them to the right place.
• Lead qualification: collect a few facts and route serious buyers to sales. Our lead qualification chatbot guide goes deep on this one.
• Support deflection: answer a handful of common questions, then hand off.

Write the goal at the top of your page: "Get visitors to the right team within three questions, and capture an email for anyone we can't help right now." Every branch should serve that sentence.

Step 2: List the outcomes before the questions

Work backward. What are the possible endings?

For a small agency, the outcomes might be:

1. Priority sales lead: hand off to a person now.
2. Standard sales lead: capture email, follow up later.
3. Existing client needing support: hand off to a person.
4. Browser: share useful links, end politely.

Now you know the tree needs exactly enough questions to sort visitors into those four endings, and no more.

Step 3: Write the questions and choose answer types

For each fork, write the question and decide how the visitor answers:

• Quick-reply buttons for anything that fits a short list. They're fast to tap and give you exact values to branch on.
• Number for thresholds you'll compare, like team size or locations.
• Email when you need a valid address.
• Free text for open detail you'll read but not branch on.

A good rule of thumb: keep button lists short. If you need more than four or five options, split the question into two steps.

Step 4: Draw the tree

Use a whiteboard, a sheet of paper or a simple diagram tool. Here's the agency example written out:

1. Message: "Hi! I'm the [Your agency] assistant (a bot). I can get you a quote, help a current client, or point you to our work."
2. Question (buttons), saved as intent: Get a quote / I'm a current client / Just looking
3. Condition on intent:
   • IF intent equals "I'm a current client" → Handoff to the support person.
   • ELSE IF intent equals "Just looking" → Message with links to case pages → End.
   • ELSE → continue to step 4.
4. Question (buttons), saved as service: Website / Branding / Ongoing marketing
5. Question (number), saved as pages: "Roughly how many pages will the site need?" (Only asked IF service equals "Website".)
6. Question (buttons), saved as budget: Under $5k / $5k–$15k / Over $15k
7. Question (email), saved as email: "Where should we send your quote?"
8. Condition:
   • IF budget equals "Over $15k" → Handoff to sales now.
   • ELSE → Message: "Thanks! We'll email a quote to {{email}} within one business day." → End.

Notice the details:

• Support never sees sales questions.
• The page-count question only appears for website projects.
• The email comes after the visitor has invested a little in the conversation.
• There are only four endings, matching Step 2.

Step 5: Choose the right condition for each check

Most builders offer a small set of comparisons. Knowing which one to use avoids subtle bugs.

Two tips:

• Branch on buttons, not free text, whenever possible. "Contains" is handy but people spell things in surprising ways.
• Use "is set" to skip questions you've already answered, for example when a visitor has already given an email earlier in the flow.

Step 6: Add an escape hatch everywhere

No decision tree anticipates everyone. Some visitors will want a person on the first message; some will have a question you never imagined. Make sure:

• A "talk to a person" option is available at every step, not just at the end.
• Branches for unexpected answers lead somewhere helpful, not to a loop.
• Nobody hits a dead end without a next step.

User research backs this up: the Nielsen Norman Group found that chatbots work well for simple, linear flows but struggle when users deviate from them. Planning the exits is how you design around that.

Step 7: Test every path, then read real transcripts

Walk through each branch yourself. A quick checklist:

• Every button leads somewhere.
• Every condition has an ELSE.
• Variables used in messages ({{name}}, {{email}}) are always set before they're used.
• The handoff works when someone is online and when no one is.
• The flow reads naturally out loud.

After launch, review real conversations weekly. If many people pick the same "other" answer, add a button for it. If a question causes drop-off, cut or reword it.

When a decision tree isn't enough

Decision trees shine when the questions and outcomes are known. They're weaker when visitors ask open-ended questions you can't predict, like detailed product questions. That's where an AI assistant that answers from your own content can help, ideally inside the same flow so the rules still handle routing. Our comparison of rule-based vs AI chatbots covers when each approach fits.

How to do this in RetroChat

RetroChat's visual flow builder uses the same building blocks described above: message, question (quick-reply buttons, free text, email, number), condition, hand off to a person, and end. Each answer is saved to a variable you name, conditions support equals, contains, greater than, less than and is set, and any saved answer can be used in later messages with {{variable}}.

You can start blank or from the Welcome & triage template, which greets visitors, routes pricing, support and browsing, and checks team size, then adapt it to your tree. Flows can be exported as a file and imported again, which is handy for keeping a backup before big edits. The "Talk to a person" button stays visible in the widget at every step. See how it works for the full setup.

Start with a small tree

Your first decision tree should fit on one page: one goal, three or four questions, a handful of endings, and an exit at every step. Build it, watch real conversations, and grow it from there. You can build and test your first flow in a free 14-day RetroChat trial.

Frequently asked questions

What is a chatbot decision tree?

It's a map of every path a scripted chatbot conversation can take. Each question is a branch point, each answer leads to the next step, and conditions decide which branch a visitor follows. It's the core of a rule-based chatbot.

How many branches should a chatbot decision tree have?

As few as your goal needs. List your possible outcomes first, then add only the questions required to sort visitors into those outcomes. Many effective small-business flows have three or four questions and four or five endings.

Can a decision tree chatbot use answers later in the conversation?

Yes, if the builder saves answers to variables. You can branch on a saved answer several steps later and insert it into messages, for example greeting someone by name or confirming the email you'll reply to.

Is a decision tree chatbot the same as an AI chatbot?

No. A decision tree follows rules you wrote, so it's predictable but only handles paths you planned. An AI chatbot generates answers from content and can handle open questions, but needs guardrails. Many businesses combine both.