What conversational AI for ecommerce actually does
Conversational AI for ecommerce means a shopper types a question in their own words and gets a specific answer, instead of picking from a menu. The version worth having works by retrieval: your documents are indexed, the passages closest to the question are pulled out, and the answer is written only from those.
That last clause is the whole thing. Everything else in this article explains it in shop terms rather than developer terms. If you want the buying guide instead of the explanation, the ecommerce chatbot guide is the place to start.
What is conversational AI for ecommerce?
Conversational AI for ecommerce is software that lets a shopper ask a question in their own words on your site and get a specific answer back, rather than clicking through a menu of canned options. The useful sort draws its answers from your own documents.
The old kind of chatbot was a flowchart. You wrote the branches, a visitor clicked "Delivery", then "International", then read a paragraph you had pinned there. It broke the moment somebody asked something you had not anticipated, which is most of the time.
The new kind reads. It does not have branches. Whatever a visitor types, in whatever words, gets matched against what you have written and answered from it. That is a genuine change in what you have to maintain: no decision tree, just documents.
How does it actually work?
Think of a new Saturday assistant on their first shift. They know nothing about your shop, but they are quick, they read well, and they have a ring binder containing your delivery page, your returns policy and your size charts. Every time a customer asks something, they flip to the right page, read it, and answer in their own words. They never answer from memory, because they have no memory of your shop.
That is retrieval-augmented generation, which is the technical name and the last time this article will use it. There are three stages.
Stage one: your documents get indexed
When you upload a document, it is chopped into passages of a few hundred words. Each passage is then given what amounts to a numeric fingerprint of its meaning, worked out by a small language model.
The reason for the fingerprint rather than a keyword index is that shoppers do not use your words. Somebody asking "how much is postage" needs to reach a page that says "delivery charges", and a keyword search will not connect those two. Fingerprints of meaning will, because "postage" and "delivery" sit close together in the numbers.
On chatfor.site those fingerprints are produced on our own servers using transformers.js with the bge-small-en-v1.5 model, rather than by calling out to a paid API. That is a cost decision with a visible consequence: indexing a document carries no per-document API charge, which is why the free plan can allow 25 documents and the Growth plan can allow unlimited ones.
Stage two: the question is matched against the passages
A visitor's question gets the same fingerprint treatment, and the passages whose fingerprints sit closest to it are pulled out. Four of them, in order of closeness, capped at roughly 1,400 tokens of your text, which is about 5,600 characters. Best matches come first and the cap is spent in that order, so a long document cannot crowd out a better passage from a short one.
There is a floor below which a passage is discarded as junk. Here is what that floor can and cannot do, measured on a sample corpus rather than assumed:
| What was asked | Closeness of the best passage |
|---|---|
| A question the documents answer directly | 0.72 |
| The same question, reworded | 0.54 |
| An on-topic question the documents do not answer | 0.51 |
| A completely unrelated question | 0.43 |
| Gibberish | 0.41 |
Read the middle two rows again. A reworded question that the documents do answer scored 0.54, and an on-topic question they do not answer scored 0.51. Those are three hundredths apart. No threshold can separate "answerable" from "not answerable" using closeness alone, which is the single most important thing to understand about how these tools work, and the reason for stage three.
Stage three: the answer is written from those passages only
The retrieved passages are handed to Anthropic's Claude Sonnet along with an instruction that is not a suggestion: answer only from the material below, and if it does not contain the answer, say so plainly in one sentence and offer something the documentation does cover. Do not guess, extrapolate, or fall back on general knowledge.
Because stage two cannot tell an unanswerable question from an answerable one, the honesty has to live here, in the instruction. That is the design, stated openly.
Two things ride alongside the answer:
- Answers you wrote yourself take priority. If you have written a question and answer pair, and a visitor's question matches it closely enough, that pair is used as the basis of the reply in preference to anything in your documents. If the match is near enough to identical, the model is skipped entirely and your exact wording is sent.
- Products are retrieved separately. If the question is genuinely about a product, matching product entries are shown as cards under the reply rather than described in it. If it is not, no cards appear.
Worth knowing: the assistant has no idea what is in a document you have not given it. This sounds obvious and it is the most common cause of a bad answer. If the assistant is wrong about your returns window, the returns policy you uploaded is usually the one from 2023.
Why the honesty rule matters more than which model you use
Every vendor in this market is using one of about five language models. The model is not the differentiator, and neither is the chat bubble. What differs is what the thing is allowed to answer from and what it does when it has nothing.
A general purpose assistant asked "what is your returns window" will produce something plausible, because producing plausible text is what it does. Thirty days is the industry default, so thirty days is what it will say, and if your window is fourteen days you now have a customer with a screenshot and a good argument.
The alternative is to restrict the source material to your own documents and instruct the assistant to admit the gap. Asked who your chief executive is, with nothing about your team uploaded, it should say it does not have that to hand. Call this refusal by design.
Be precise about what that buys you. Restricting the source material shrinks the surface for invention. It does not repeal how language models work, and no honest vendor will tell you their tool cannot get anything wrong. What it should give you instead is verifiability:
- Every conversation is stored and readable.
- You can see which passages of which document an answer was drawn from.
- You can overrule any answer by writing a curated one, which then takes priority for good.
That loop is the actual product. The chat bubble is just where it surfaces. Six worked cases, including one where the documents do not cover the question at all, are laid out in our set of question by question walkthroughs.
What does one answer cost to serve?
About half a cent, and it is worth knowing why, because "conversational AI" is often priced as though it were expensive.
| Component | Measured figure |
|---|---|
| Input tokens per answer | 1,794 average |
| Output tokens per answer | 87 average |
| Rate for Claude Sonnet 5 | $2 per million input, $10 per million output (Source: Anthropic documentation, 2026) |
| Model cost per answer | about $0.0045 |
| Cost to index a document | no per-document API charge, because indexing runs locally |
Roughly 89% of that input figure is your own retrieved text. Everything else in the prompt is rounding, which is why the context cap is the only number worth tuning and why an assistant with a good set of curated answers costs less to run: a question matching a curated answer never reaches the model at all.
The practical use of this table is as a sanity check. If you are quoted a per-conversation price, you now know roughly what sits underneath it. On chatfor.site the plans are Free at $0 forever for 100 answers a month, Starter at $29 a month for 2,000, Growth at $79 a month for 6,000, and Business at $199 a month for 20,000. Every account starts free, so nothing needs a card until you choose a paid plan.
Worth knowing: cost per answer is not the same as cost per month. Hosting and the database are a fixed monthly figure, not a per-answer one, which is why a plan has a floor price rather than being pure metered usage.
What it does not do
Naming the boundary is more useful than another benefit list. This kind of assistant answers questions from documents. It is not an order management system, and giving it a policy PDF does not teach it anything about a specific order.
- It answers from what you upload: documents, pasted text, product entries and curated question and answer pairs. Nothing else.
- It does not know a shopper's order status unless you have told it, in writing, what the process is.
- It cannot enforce a policy. It can state one.
- It will be as out of date as your worst document.
The last point is the one that bites over time. A knowledge base for a chat assistant is a thing you maintain, not a thing you upload once, and our guide to organising the source material covers how to keep it honest. If you also run a physical shop, opening hours and collection questions need their own treatment, which is in the retail specific guide.
There is also a limit on the visitor side: 30 messages per minute per visitor, enforced in the database rather than per server instance, so it holds regardless of which instance a request lands on. Data sits in Supabase, hosted in Ireland. Sign-in for shop owners is a magic link, so there is no password to be leaked.
Frequently asked questions
Is conversational AI different from a chatbot?
In practice, yes. "Chatbot" usually means a scripted decision tree with buttons, where every path was written by hand. Conversational AI takes a question in the visitor's own words and works out the answer from your material, so there are no paths to write or maintain.
Should I add conversational AI to my ecommerce site?
If you answer the same handful of questions by email every day, and the answers already exist in writing somewhere on your site, yes. If your questions genuinely need judgement or account access on every enquiry, an assistant will handle the routine half and pass the rest to you.
How is this different from the search box on my site?
Site search returns a list of pages and leaves the reading to the shopper. This returns the answer. The mechanism differs too: search matches words, while retrieval matches meaning, so "how much is postage" reaches a page headed "delivery charges" without either word appearing in the other.
Does it learn from my customers' conversations?
Not automatically, and that is deliberate. Its knowledge changes only when you change what you have uploaded. What conversations give you is the list of questions it could not answer, which tells you exactly what to write next, with no guessing about what customers want.
How do I integrate an AI chatbot into my ecommerce store?
One script tag, the same shape as adding an analytics tag, pasted into your theme or your platform's script manager. On chatfor.site the snippet is generated with your assistant's id already in it, and it loads deferred so the widget never delays your product images.
Sources
- Anthropic documentation, Pricing: https://platform.claude.com/docs/en/docs/about-claude/pricing (retrieved 4 September 2026)
Try it on your own documents
Upload what you already have and ask it something. The free plan needs no card, and it will tell you when your documents do not cover a question.
Start free