Skip to content
Rivl
16 September 2026AI9 min

An AI chatbot for a business website, and where it loses the lead

The model is the part everyone argues about and the part that matters least. What decides whether a website chatbot earns its place is what it is allowed to read and what it does when it does not know.

A chatbot on a marketing site is an easy thing to want and a hard thing to justify. The pitch writes itself: visitors ask questions at eleven at night, nobody is there, the bot answers, you wake up to booked calls. Sometimes that is what happens. More often the bot answers three questions competently, gets a fourth one wrong, and the visitor quietly leaves with a wrong idea about what you sell.

The difference between those two outcomes is not the model. Every current model is good enough to hold a coherent conversation about a business. The difference is what the thing is allowed to read, what it is forbidden to guess at, and how fast it gets out of the way. This note is about those three, and about the one legal obligation that is now genuinely in force rather than coming soon.

The sections of this note in order: the website chatbot is a different product from the support chatbot, grounding is most of the build, the escalation path is what protects the lead, the disclosure rule that is now in force, what it costs to run, what to build first, and the honest limits.
How this note is organised.

A website chatbot is a different product from a support chatbot

These get built by the same team with the same tools and they have opposite failure modes. A support chatbot talks to people who already bought. Its worst outcome is an annoyed customer who opens a ticket anyway. A website chatbot talks to people who have not bought, will not complain, and will never tell you they left. Its worst outcome is invisible.

That asymmetry should change what you build. We wrote separately about what to trust an AI chatbot with in customer support, where containment rate is a sensible target because the alternative is a queue. On the marketing site there is no queue. Containment is not a goal at all. The goal is that the visitor leaves with an accurate idea of whether you can help them, and a way to continue if the answer is yes.

So the metric is not how many conversations the bot handled without a human. It is how many qualified conversations reached a human who could close them, minus the ones it talked out of doing so. Nobody instruments the second half, which is why these projects report success so reliably.

Grounding is most of the build

The single largest determinant of whether a website chatbot is safe to deploy is whether its answers are tied to documents you control. A model answering from its own general knowledge about your company will produce something plausible and occasionally wrong about pricing, scope, turnaround or availability. Those are exactly the four things a prospect asks.

Grounding is a solved engineering problem, and the vendors document it. Anthropic's Citations feature is a fair example of the shape: you supply the source documents, the model answers from them, and the response carries back the exact passages that support each claim. Plain text and PDF documents are chunked into sentences by default, and the returned citation is a location into the source, whether that is a character range, a page, or a specific content block you defined yourself. Custom content documents exist precisely so you control where the citation boundaries fall.

The practical consequence is not the citations themselves, which most visitors will never click. It is that a grounded answer can be audited. You can read back a week of conversations and check every claim against the passage it came from. Ungrounded, you are reading a week of confident prose with no way to tell which parts were true.

What to ground it on, in order: your services pages, your pricing or pricing-logic page if you have one, your scoping questions, and a written list of things you do not do. That last document is the one nobody writes and the one that prevents the most damage.

The escalation path is what protects the lead

A chatbot that cannot say it does not know is a liability. A chatbot that says it does not know and then stops is a dead end. The useful behaviour is narrow: recognise the limit, name it plainly, and offer the next step in the same breath.

  • Anything about price beyond published ranges goes to a person. Quoting is a judgement, not a lookup.
  • Anything about timelines for work not yet scoped goes to a person, for the same reason.
  • Anything the grounding documents do not cover is answered with what is known, a clear statement of what is not, and a handover.
  • Anything that reads as a complaint or a legal question leaves the bot immediately and is logged.

Handover means a real mechanism, not a link to a contact form the visitor could already see. A booked slot, a message that reaches somebody, a callback request with the conversation attached. If the escalation is worse than the page the visitor was already on, the bot has cost you the lead rather than saved it.

You now have to say it is a bot

This stopped being a matter of taste. Article 50 of the EU AI Act sets a transparency obligation for AI systems intended to interact directly with natural persons: people have to be informed that they are interacting with an AI system, unless that is obvious from the context. The information has to be given in a clear and distinguishable manner at the latest at the time of the first interaction. The published text of Article 50 is short and worth reading in full. Its obligations apply from 2 August 2026.

If you sell into the EU, this is binding on you regardless of where the server is. If you do not, it is still the direction of travel and it costs nothing to comply with, because the disclosure was always the right call commercially. A visitor who works out mid-conversation that the confident voice was a bot has learned something about you that no amount of copy will undo.

The same article also requires that synthetic audio, image, video or text output is marked in a machine-readable format where technically feasible, which matters more for content generation than for a support widget, but is worth knowing before somebody on the marketing team wires the same model into the blog.

What it costs to run, honestly

Cost lineWhere it actually lands
Model inferenceUsually the smallest line. Conversations on a marketing site are short and infrequent compared to support volume.
Grounding contentA real writing job. Somebody has to produce and maintain the documents the bot answers from, and they go stale.
Escalation plumbingCalendar, CRM or inbox integration, plus the conversation transcript travelling with the handover.
Review timeAn hour a week reading transcripts. Skip this and you will not find out it has been wrong for a month.
Failure costUnmeasured, and the largest of the five. Every visitor talked out of contacting you is invisible in the dashboard.
The cost lines of running a website chatbot and where each one actually lands, from model inference through grounding content, escalation plumbing and weekly review to the unmeasured failure cost.
The cost of a website chatbot is mostly not the model.

The pattern here is the one that shows up in most small AI projects: the model is cheap, the data preparation is not, and the ongoing human attention is what actually decides whether the thing keeps working. We made the same argument more generally in how to use AI in operations without breaking the business.

What to build first

If you are going to do this, the smallest useful version is not a chatbot. It is the grounding corpus. Write the services document, the pricing-logic document and the we-do-not-do-this document, and put them on the site as pages. Half the time the exercise reveals that the questions visitors ask are unanswered on the site itself, and fixing that returns more than any widget will.

Then, if the questions genuinely arrive outside working hours in volume, wire a grounded bot on top of those same documents with a hard escalation rule and the disclosure in the opening message. Instrument two numbers from day one: conversations that reached a human, and conversations that ended without one. Read the second set weekly.

Whether this is worth doing at all depends on which side of your funnel is actually constrained. If inbound volume is not your problem, a chatbot is solving the wrong bottleneck, and bdg-labs makes that case well in outbound versus inbound, and which constraint you actually have. If you are drowning in unqualified enquiries instead, the honest fix is a better qualification step, not a friendlier one, and possibly scoring the leads you already have.

The honest limits

A website chatbot will not fix a positioning problem. If visitors cannot tell what you sell, a conversational layer over the same ambiguity produces confused conversations rather than confused bounces, and confused conversations cost more to review.

It also does not replace a person on a considered purchase. For anything with a real sales cycle, the bot's ceiling is triage: work out who this is, what they need, and whether it is worth a call. That is a genuinely useful ceiling and it is much lower than the pitch. Buy it for triage, measure it as triage, and do not be disappointed when it does not close anything.

And if the honest answer is that you get four enquiries a week, you do not have a chatbot problem. Four conversations a week is a person reading their email, and a calculator or a tool that earns its build cost will do more for the same money.

Describe it. We build it.

Seven or twelve days, pay on delivery, a year of maintenance included. Bring the problem, not a spec.

Book a meeting

Read next