Generative vs Rule-Based Chatbot

Which of Your Flows Should Move, and What Moving Costs (2026)

Quick answer: Decide per flow, not per bot. Ask three questions of each flow you already run: whether the set of correct answers is finite and writable, whether the flow changes anything in a system of record, and whether the customer's input is a choice or a sentence. Finite answers, a button-shaped input, or an action at the end means the flow stays a decision tree. Open questions your documents already answer are what should move to a generative bot. And the cost of moving is content preparation rather than build time, because the flow you are replacing was quietly serving as your documentation.

Our glossary entry defines the two architectures, sets out the three shapes generative bots ship in, and lays out the enumerability comparison that explains why the two behave differently. It deliberately stops before the decision. This page picks it up there. If you have not yet built anything, our chatbot build guide is the better starting point; what follows assumes a working rule-based bot and a nagging question about whether it should stay that way.

Step 1: count the flows, then find out which ones anyone uses

You cannot triage a list you have not written down, and almost nobody has written it down.

Open your builder and list every flow the bot can enter, in plain words: what triggers it, what it asks, what it answers, and what it does at the end. Owners routinely find more of them than they remembered building. Then pull the last ninety days of conversation data and put a number next to each one. Most platforms expose flow-level or trigger-level counts somewhere in analytics; if yours does not, an export of transcripts and an afternoon of tagging gets you close enough.

The distribution is the useful output, and our expectation is that it comes back lopsided: a small number of flows carrying most of the traffic and a long tail carrying almost none. That expectation is drawn from the analytics surfaces these builders expose rather than from a measurement of anyone's bot, which is exactly why you pull your own number instead of assuming the shape. If it does come back lopsided, that changes the whole conversation. Rebuilding the top three flows is a project with measurable stakes. Rebuilding the tail is rarely worth anyone's afternoon, and for much of it the right verdict is deletion.

Two columns are worth adding while you are in there. Note which flows end in a handoff to a person, because a flow that mostly escalates is telling you it never fit a tree in the first place. And note the fallback rate per flow rather than for the bot overall, since the bot-level number averages away exactly the signal you need.

Step 2: three questions that classify a flow

Run each flow through these in order. The first answer that comes back "no" usually settles it.

1. Is the set of correct answers finite, and could you write them all down? Store hours, return window, shipping zones, plan prices, warranty length. If a competent new hire could produce the complete list in an afternoon, the flow has a finite answer set. A tree serves a finite answer set perfectly and a model serves it approximately, which is a strange trade to make on purpose.

2. Does the flow change anything? Booking, canceling, refunding, writing to a CRM, applying a discount. Any flow that writes should keep the write deterministic no matter what else you do with it. This is not a stylistic preference. A model can be talked into things a form cannot, and our guardrails guide covers what that costs on a bot with permissions.

3. Is the customer's input a choice or a sentence? If the honest answer to "what does the customer say here" is one of four things, buttons are the better interface and the tree behind them is the better engine. If the answer is anything, you have a language problem, and language problems are what models are for.

Applied to the flows most SMB bots actually contain, the classification comes out like this:

Two notes on reading it. Lead qualification looks like a generative candidate because the answers are free text, but the flow's job is to collect and route structured fields, so the right shape is a designed multi-turn form with a model interpreting one or two open answers. Refund eligibility splits the same way: the rule stays in the tree, the question about the rule goes to the model.

One category is missing from the table on purpose. Complaints, and anything else where the customer arrives upset, fail all three questions and still should not become a generative flow, because the prior question is whether they belong to a bot at all. Our when not to use a chatbot guide takes that up.

Step 3: the four verdicts, and which one you will mostly land on

The classification produces four outcomes, not two, and the middle one is where most flows end up.

Stays a tree. Finite answers, a button-shaped input, or a write at the end. Leave it. Resist the urge to modernize it while you are in the builder, because a flow that already completes almost every conversation it starts has nowhere to go but down.

Tree with a generative step inside. The flow keeps its structure, its conditions, and its actions, and a model handles one open question or interprets one free-text answer. This is the shape our glossary entry calls generative inside a flow, and it is the most common ending for a rule-based bot that modernizes well. The deterministic parts stay deterministic, which is the entire point.

Moves to grounded generative. The questions are open, the answers live in documents you already maintain, and no write happens. The bot searches your content and answers from what it finds, which is retrieval-augmented generation, and the practical build is covered in our RAG build guide.

Gets deleted. A flow with almost no traffic and a poor completion rate is not a migration candidate. Removing it makes the remaining bot easier to test and cheaper to maintain, and nobody notices.

The useful reframe here is that migration is rarely wholesale. A bot that ends with, say, most flows unchanged, three carrying a generative step, two rebuilt on retrieval and four deleted has migrated successfully, and it will still look mostly rule-based in the builder. The wholesale version is the one that appears in vendor migration guides, and it is also the one that lands you on a bigger plan. Worth noticing that those two things point the same way.

Step 4: the bill is content, not build

Here is the line item that gets underestimated, and in our reading it gets underestimated by more than any other in the project.

Configuring a grounded generative flow takes hours. The flow you are removing, though, contained knowledge that existed nowhere else. The return policy was encoded into a branching structure at some point, by somebody, and that structure has quietly been the operative version ever since, drifting from whatever the website says. Delete the tree and the model has nothing correct to read.

So the real work is an inventory, done per flow you intend to move:

The pattern worth internalizing: a generative bot's answers are only as good as the content it reads, so a migration is a content project with a configuration step at the end. That is the same argument our hallucination guide makes from the failure side, and it is the reason a migration that skips the inventory produces a bot that sounds better and is wrong more often.

One more line that belongs in the budget, and it is easy to state too strongly. A tree is not free to run, since plenty of platforms cap conversations or charge per contact regardless of which engine answers. What is true is that a tree's cost is fixed by your plan rather than by what customers said, while a generative reply is metered on top of that, whether the vendor exposes tokens or wraps them in a conversation quota, and long threads cost more than short ones. Our pricing models guide covers the packaging, and the arithmetic belongs in the ROI quick math before the switch rather than after the first invoice.

Step 5: run both, but split by flow rather than by traffic

The instinct is to send a percentage of traffic to the new version. For this particular change that is the harder path, because the two architectures fail in different places and a percentage split mixes the evidence.

Split by flow instead. Move one flow, leave the rest untouched, and let the trigger decide which engine answers. Almost every flow-builder platform supports this natively, since a flow is already the unit of routing there. What you get is a clean comparison: the same customers, the same period, one changed variable.

Pick the second-best candidate first rather than the highest-volume one. The top flow is where a regression costs the most, and you want your first migration to be the one where you learn the platform's quirks cheaply.

Then measure for at least two weeks, against numbers you wrote down before the switch:

• Containment or resolution on that flow specifically. Bot-level metrics will not move enough to read. Our resolution rate guide covers the measurement itself.
• Escalation rate. If it drops, check whether the bot got better or simply stopped admitting it did not know. Those look identical in a dashboard.
• Wrong-and-confident answers. Grade a weekly sample of twenty to thirty transcripts against the source documents. There is no automated substitute, because a fluent wrong answer is indistinguishable from a right one to every metric you have.
• Cost per conversation on that flow. The tree's cost did not vary with what customers said. Whatever the new number turns out to be, watch its variance rather than only its average.

The last two are the ones teams skip, and they are the two that decide whether the migration was a good idea. A flow that resolves more conversations while producing occasional confident errors about your refund policy has not improved; it has moved the cost somewhere the dashboard does not show. The functional side of this testing is covered in our QA testing protocol.

Keep the old flow switched off but intact for a month. Rolling back should be a toggle, not a rebuild.

Five cases where the tree wins and stays

Five situations where a decision tree remains the better product in 2026, none of which is nostalgia. These are lookups rather than a step, so read them alongside the classification in Step 2 rather than after Step 5.

Regulated or contractual answers. Anything about pricing commitments, refunds, medical or financial matters, or terms you can be held to. A finite set of approved sentences is an asset when someone asks what the bot told a customer. If a wrong answer in this flow would eventually need a lawyer, keep the flow enumerable.

High-volume, single-answer questions. If a large share of your traffic asks about shipping times, a tree answers instantly, identically, and without adding a meter. A model answers approximately, variably, and for money.

Anything that writes. Booking, canceling, discount codes, CRM records. Keep the structure and let a model interpret the input if you like, but the action stays behind a form.

Very low volume overall. Below roughly a hundred conversations a month, the maintenance loop a generative bot requires costs more attention than the bot returns. Our when not to use a chatbot guide makes the fuller version of this argument.

No content, and no one to write it. A generative bot with nothing to ground on is the worst of both architectures: unpredictable and uninformed. If nobody owns the documentation, the honest sequence is to write the content first and revisit the bot afterward.

There is also a case that runs the other way, and it is worth stating plainly. If your bot's fallback rate is high and customers are visibly rephrasing themselves to get through the tree, the tree has failed at the thing trees are good at, and no amount of adding branches fixes it. That pattern, more than any vendor argument, is the signal to move.

Platform notes: what the move looks like where

The mechanics differ enough between products to change the sequencing, and the difference sits in how each product decides what to run next, not in how deep its settings go.

Where the flow is the unit of routing, the middle verdict is a native operation. Manychat is the clearest case: the flow keeps its blocks, conditions and actions, and an AI step drops in where the open question is, so nothing gets rebuilt. On Tidio the scheduling detail matters more than the configuration. Its review records that a website crawl proceeds asynchronously and the knowledge-quality score did not surface inside a two-day window, so plan a soak period of several days between importing content and pointing real customers at the flow. Step 4 is the gating task there, and it starts earlier than you would guess.

One product does not work this way at all, which is worth knowing before you plan a per-flow migration. Chatbase organizes around the knowledge source rather than a flow canvas, so the third verdict is what it does natively and there is little to triage; the honest caveat is that its own review records a recurring hallucination theme in third-party user reviews alongside a measured rate, so the transcript grading in Step 5 is not optional there. On Chatbase, mixing architectures means running two products rather than sorting flows into piles.

Botpress supports the triage and adds a second axis to it. Its Studio canvas holds ordinary deterministic flows and sub-flows, and its Autonomous Engine can be switched on per agent to let the model decide at runtime which tools, knowledge sources and sub-flows to invoke. The question there is therefore not whether a flow can stay a tree, because it can, but how much of the routing you hand over. Intercom sits on the support-desk side: grounded on the answering side, executing through documented workflows, so the split between the flow that answers and the workflow that acts is something you configure rather than inherit.

Those notes trace to each product's review at its own date, between 27 and 31 May 2026, and evidence depth differs per review and per claim. Those reviews carry affiliate links; our methodology sets out what that does and does not change about a score. The question worth putting to any vendor is narrower than "do you support AI": ask whether a single flow can run one generative step while the rest of its blocks stay deterministic, and ask what happens to that flow when retrieval returns nothing. A vendor whose answer to the second is "it still answers" has told you where your grounding rail will need to go.

The decision, compressed

List the flows and put ninety days of volume next to each. For each one ask whether the answers are finite, whether anything gets written, and whether the input is a choice or a sentence. Sort into four piles: stays a tree, tree plus a generative step, moves to grounded generative, gets deleted. Expect most flows to land in the first two. For anything moving, do the content inventory before touching configuration, because the flow was the documentation. Migrate one flow at a time starting with the second-best candidate, measure that flow against numbers you wrote down beforehand, and grade a weekly transcript sample for confident errors. Keep the old flow intact for a month. Then repeat for the next one.

And if the triage sorts every flow into the first pile, that is a result rather than a failed exercise. It means the bot is already the right shape, and the budget you had earmarked for an architecture change should go to the content instead, where it would have gone anyway.

Frequently asked questions

Related guides

• Generative AI chatbot (glossary) — the definition, the three shipping shapes, and the enumerability comparison this decision rests on
• What is a chatbot (glossary) — the four-architecture taxonomy, including the hybrid pattern most of these migrations produce
• How to build a chatbot — the greenfield path for anyone without an existing bot to triage
• Build a RAG chatbot — the build detail behind the third verdict
• Build a chatbot knowledge base — the content shape that makes retrieval work
• Reduce chatbot hallucinations — the grounding and transcript-grading loop a moved flow inherits
• When not to use a chatbot — the prior question for any flow that keeps escalating
• Migrating vendors: a 14-day playbook — the platform-change project this one should not be combined with
• Best AI chatbot — platforms ranked under our published methodology

About this guide

Chatbotscape launched in 2026 as an independent review site for chatbot platforms. This guide is part of our SMB chatbot Academy. Its central recommendation is that most flows in most bots should stay rule-based, which is an argument against buying the AI tier that generative features usually sit behind, and against our own commercial interest in readers upgrading their plans through our links. We have a mild commercial interest in readers choosing platforms through our reviews. This is editorial guidance rather than a consulting engagement. To flag an error, write to editorial@chatbotscape.com.

Methodology

This page contains no new measurements. We did not migrate a bot for it, and no figure here is a study result. The three classification questions, the four verdicts, the content-cost table, the split-by-flow cutover method, and the five stay-a-tree cases are our editorial framing rather than a published standard. Where the page says a pattern is common, usual or expected, read it as an anchored editorial assessment formed from the builder surfaces, analytics views and documentation we work through when reviewing these products, not as a measured prevalence; we have not surveyed customer deployments, and no percentage in this category should be trusted from us or anyone else who has not published a method. Every count and threshold on the page is illustrative rather than measured: the lopsided flow distribution, the illustrative migration split of a few flows gaining a generative step and one or two moving to retrieval, the twenty-to-fifty-question accuracy set, the twenty-to-thirty-transcript weekly sample, the two-week measurement window, the one-month rollback period, and the roughly-hundred-conversations-a-month floor carried from our when not to use a chatbot guide. Read each as a planning anchor rather than a study result. Architecture definitions, the three generative shapes, and the enumerability argument are carried from our generative AI chatbot entry and its cited sources rather than re-derived. Platform notes are structural, trace to our published reviews, and are stated as of those reviews' own dates (27 to 31 May 2026) rather than re-checked here; evidence depth differs per review and per claim, and the reviews record it row by row.

Sources

• Lewis, P., Perez, E., Piktus, A., et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33 (NeurIPS 2020). arxiv.org/abs/2005.11401. The primary description of the architecture behind this page's third verdict, and the reason the migration cost lands on the retrieval corpus rather than on the model.
• National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). Published 26 July 2024. doi.org/10.6028/NIST.AI.600-1 (publication record verified 27 July 2026 for our generative AI chatbot entry). Cited here for the general point that standards bodies treat generative systems as their own category rather than a feature upgrade, which is the background to keeping write actions deterministic in Step 2.
• Chatbotscape Glossary. Generative AI chatbot — carries the enumerability comparison and the three deployment shapes inherited by this page (verified 27 July 2026).
• Chatbotscape Glossary. What is a chatbot — carries the four-architecture taxonomy, including the hybrid pattern this page's middle verdict produces.
• Chatbotscape Glossary. Retrieval-augmented generation — carries the primary citation for the grounded architecture (Lewis et al., NeurIPS 2020) behind the third verdict.
• Chatbotscape platform reviews for Manychat, Tidio, Chatbase, Intercom, and Botpress, last updated between 27 and 31 May 2026. Architecture notes here are structural and stated as of each review's own date. Evidence depth differs by product and is recorded per review rather than flattened into a single claim on this page.
• Chatbotscape evaluation methodology. /methodology (continuously updated).

Last updated

29 July 2026 — Initial publication aligned to methodology v3.12.1. Next scheduled refresh: 29 October 2026.