Which is fine, until a visitor types something the tree has no branch for — and most of them do. Retrieval takes the other route: read the customer's actual question, find the relevant passages in your own content, and answer from those.
You draw a decision tree. The visitor picks from buttons. Each branch ends in a message you wrote.
Strengths
Limits
You point it at your pages and documents. It finds the relevant passages for whatever was asked, then answers from them and cites the source.
Strengths
Limits
Retrieval is not universally better. If any of these describe your main use case, a flow builder will serve you better and you should use one.
Your existing flows are not wasted work. They are a tested corpus of answers, which is exactly what you need to train on.
Every branch that ends in a written answer is a Q&A pair waiting to happen. That copy is already tested on real customers — it is the best training data you have.
Flows tend to end in “see our shipping page”. Train on those pages directly and the assistant answers instead of redirecting.
The safety a decision tree gave you by construction now comes from the system prompt and handover. Name what it must not attempt.
The questions your flows never had a branch for will show up immediately. Most teams find three or four themes and close them in an afternoon.
A decision tree needs translating branch by branch, and every future edit has to be made in every language. Retrieval reads your one English knowledge base and answers in whatever language the visitor wrote in — more than ninety-five of them — with nothing extra to maintain.
How that worksWhat this page compares. Two approaches — scripted flows and retrieval — rather than two products. Individual tools change what they offer frequently, and several now do some of both, so check any vendor's current capabilities on their own site. The approach question is the durable one, and it is the one worth deciding first.
No. It is a retrieval-based assistant: you train it on content and it composes answers from what it retrieves. If a drag-and-drop decision tree is a hard requirement — for a legally fixed script, for instance — that is a genuine reason to choose a flow-based tool instead.
Not a staffed real-time agent console. Handover collects the visitor’s details and passes the conversation to your team with the transcript attached. For teams without someone watching a queue all day, that is usually the more honest arrangement — but if you are staffing live chat, you need a tool built around that.
Substantially. The system prompt sets the role, tone and refusals; Q&A pairs pin exact wording for the answers that matter most; and the knowledge base bounds what it can draw on at all. What you give up is guaranteed identical strings, in exchange for coverage of questions you never scripted.
This is where the difference is largest. A flow builder needs a translated tree per language. Retrieval detects the language of each message and answers in it — over 95 languages — from one knowledge base you maintain once.
Minutes to a working assistant: paste a URL, pick the pages, wait for indexing. The part worth spending real time on is the system prompt and a handful of Q&A pairs in your own voice.
Yes — it is a script tag on your own pages, so it coexists with anything else. Some teams keep a flow for one transactional path and put the assistant on everything else.
That is the whole test. Train it on your site and type the awkward question you know your tree cannot handle.
Start free