TL;DR: A website chatbot answers questions when nobody is available and captures contact details that would otherwise be lost. Whether it helps depends almost entirely on two things: the quality of what you feed it, and whether a person actually picks up when it hands over. The software is the easy part.
Key Takeaways
The knowledge base is the product. A chatbot given thin documentation produces confident wrong answers.
Language-model bots beat scripted trees on phrasing, and they will invent things if your source material is incomplete.
Lead scoring is a prioritisation aid, not a measurement. Treat the scores as a sort order.
Handoff decides whether it works. An alert nobody answers is worse than no chat at all.
Set the limits explicitly, especially on pricing, availability and anything regulated.
Measure enquiries, not conversations. Chat volume rises whether or not anything improves.
Anchor targets assume your CMS generates slug IDs from heading text. Confirm on staging and adjust the hrefs if your platform slugifies differently.
What the problem is
Someone arrives on your site with a specific question, cannot find the answer, and leaves. You never know they were there.
Where the gap actually falls
Gap | Why it exists |
|---|---|
Outside working hours | Most of the week, for a small team |
During working hours when everyone is busy | A client call means nobody is watching the site |
Questions your pages do not answer | Edge cases, specifics, combinations |
Questions people will not use a form for | Too small to justify filling anything in |
The last one is underrated. Plenty of visitors have a question they would ask a person and would never submit a contact form to ask.
What the honest claim is
A chatbot answers some of those questions and captures some of those visitors. How many depends on your traffic volume, your category and how good the answers are.
Nobody can tell you a percentage, and the ones in circulation are invented.
On response speed
It is widely claimed that responding within minutes dramatically improves qualification. Research on lead response times does exist and is frequently quoted far beyond what it measured, so treat specific multipliers with caution.
The qualitative point holds: a visitor who gets an answer while still on the page is in a better position than one who waits until tomorrow.
Who this suits
Sites with enough traffic that the missed conversations add up, selling something with questions attached, and with someone who will actually respond to alerts.
Who it does not
Sites with very little traffic, where the constraint is that almost nobody arrives. A chatbot on fifty visitors a month answers two questions and costs a subscription.
Scripted or language model
Two architectures with different failure modes, and the newer one is not strictly better.
Scripted
Decision trees and keyword matching. The visitor picks from options or types something that matches a rule.
Strength | Weakness |
|---|---|
Says only what you wrote | Fails on unanticipated phrasing |
Entirely predictable | Frustrating when it misses |
Safe in regulated contexts | Needs constant script maintenance |
Language model
Interprets what the visitor meant and answers from material you supplied.
Strength | Weakness |
|---|---|
Handles varied phrasing | Can state things your material does not support |
Much less scripting work | Harder to predict |
Answers questions you did not anticipate | Including some you would rather it declined |
The failure modes differ in kind
A scripted bot fails visibly: the visitor sees it did not understand and leaves annoyed. A language-model bot fails invisibly: it gives a confident answer that is wrong, and the visitor believes it.
The second is worse, and it is the one that needs guarding against.
The guard
Boundaries written into the configuration: what it must not answer, what it should hand over, and an instruction to say it does not know rather than infer.
Most platforms support this and most deployments do not configure it.
Which to choose
Situation | Fit |
|---|---|
Regulated advice, pricing that must not be misstated | Scripted, or tightly bounded |
General product questions, varied phrasing | Language model |
Very narrow use, like booking | Scripted is simpler and fine |
The honest default
A language-model bot with explicit limits and a fast handoff. That combination gets the flexibility without the invisible failure, and the limits are the part that takes thought.
The knowledge base
The part that determines everything, and the part treated as setup.
What to feed it
Source | Why |
|---|---|
Product and service documentation | The substantive answers |
Pricing, with its conditions | The most asked question |
What you do not do | Prevents the worst failures |
Common questions from sales and support | The actual distribution of what gets asked |
Process and timelines | How long things take, what happens next |
Policies | Returns, cancellation, support hours |
The third row is the one people skip
A chatbot that only knows what you offer will answer questions about things you do not offer by inferring from adjacent material. Telling it explicitly what is out of scope is the single most effective safeguard.
Write a list of the things you do not do and feed it in.
Garbage in, confident garbage out
If your documentation is thin, contradictory or stale, the chatbot will produce answers that are thin, contradictory or stale, delivered fluently. Fluency makes them more convincing, not more accurate.
That is why a chatbot project frequently turns into a documentation project, and that is usually the right outcome.
Pricing deserves special care
The most asked question and the most volatile fact. If your pricing changes, the chatbot's knowledge must change with it, or you have a system telling prospects an old price around the clock.
Put it on the same change checklist as everything else that carries a price.
Maintenance
Not a setup task. When the product changes, the knowledge base changes, and someone owns that. Without it, accuracy decays and nobody notices because the bot keeps answering confidently.
The review habit
Read transcripts weekly for the first month, then monthly. You are looking for wrong answers and for questions your material does not cover, which is a content gap list generated for free.
Lead scoring
Useful as a sort order, misleading as a measurement.
What it does
Assigns points for behaviour: pages viewed, time on site, questions asked, details given. The total ranks today's enquiries.
What it is not
A probability. A score of eighty does not mean eighty percent likely to buy, and the weights were chosen by someone rather than derived from your outcomes.
Treat it as a queue order: look at these first.
Setting the weights
Signal | Usually worth points |
|---|---|
Viewed pricing | Yes, the most common one |
Asked about implementation or timelines | Yes, it implies intent |
Gave a work email and company | Yes |
Asked about a specific use case | Yes |
Long session | Weakly. Could be confusion |
Many pages | Weakly, same reason |
Calibrate against outcomes
After a quarter, compare scores against what actually converted. If high scorers are not converting better than low ones, your weights are wrong, and almost nobody checks this.
That comparison is the difference between a scoring system and a decorative number.
Keep it simple
Three or four signals with sensible weights outperform a dozen with invented ones, because you can reason about the result and adjust it.
What to tell sales
That it is a sort order, not a verdict, and that a low score can still be a good lead. Reps who learn the scores are arbitrary will ignore the whole system, including when it is right.
The honest framing
This saves time by ordering a queue. It does not identify buyers, and any product claiming it predicts purchase intent is describing a correlation it has not validated against your data.
Human handoff
The thing that decides whether any of this works, and the thing least planned for.
The failure
The bot cannot answer, offers to connect someone, the visitor says yes, and nobody responds. That visitor is now worse off than if there had been no chat widget, because they were promised a person.
What has to be decided before launch
Question | Why it matters |
|---|---|
Who gets the alert | A named person, not a shared channel nobody owns |
What hours they cover | And what the bot says outside them |
How fast is acceptable | Minutes during hours, and say so |
What happens out of hours | Take details and promise a time you will meet |
Who covers holidays | The gap nobody plans for |
The out-of-hours script matters
Not nobody is available. Rather: our team is back at nine tomorrow, leave your details and we will reply first thing.
A specific commitment, kept, is a better experience than an instant non-answer, and it is the realistic option for a small team.
When to hand over automatically
Trigger | Why |
|---|---|
The visitor asks for a person | Always, immediately |
Any sign of frustration | Before it becomes a complaint |
Pricing beyond the standard case | Where errors are expensive |
Anything regulated or safety-related | Where errors matter most |
Two failed answers | Stop before it becomes three |
Make takeover easy
One click, from the notification, into the live conversation with the transcript visible. If taking over requires logging into a dashboard and finding the thread, it will not happen during a busy afternoon.
The honest test before launch
Have someone outside the team trigger a handoff at an awkward time and see what happens. Most teams discover the alert goes somewhere nobody watches.
What goes wrong
The failure modes, roughly in order of how often they appear.
Confident wrong answers
The main risk with language-model bots. It infers from adjacent material and states something your business does not actually do.
The guard: an explicit out-of-scope list, an instruction to say it does not know, and weekly transcript reviews at first.
Stale facts
Pricing changed, a feature shipped, support hours moved, and the knowledge base did not. The bot now tells every visitor something untrue, around the clock, with total confidence.
The guard: the knowledge base joins the change checklist for anything that changes.
Nobody answering the handoff
Covered above, and it is the most damaging because the visitor was promised a person.
The widget that interrupts
A chat window that opens over the content a visitor is reading, three seconds after they arrive, is an obstacle rather than a service.
The guard: let them read. Trigger on intent signals or after meaningful time, and make closing it easy and persistent.
Pretending to be human
A bot with a person's name and photo that does not disclose what it is. People work it out, and the discovery colours everything else about your company.
The guard: say it is an assistant in the first message. Nobody minds a disclosed bot that is useful.
Collecting data carelessly
Chat transcripts contain personal information, sometimes sensitive. That brings data protection obligations around notice, retention and access.
The guard: a privacy note at the start of the chat, a retention policy, and a check with whoever owns compliance before launch.
The regulated-sector case
If you operate under professional rules, what an automated assistant may say about your services is constrained. That needs checking before deployment rather than after a complaint.
Measuring it
Chat volume rises the moment you install a widget. That is not evidence of anything.
What to measure
Measure | Why |
|---|---|
Qualified enquiries per month, before and after | The only number that matters |
Conversations ending without an answer | Your content gap list |
Handoff requests and response times | Whether the promise is being kept |
Enquiries outside working hours | The specific gap this was bought to close |
Wrong answers found in transcripts | Accuracy, which only reading reveals |
The before-and-after
Record three months of enquiry volume before installing. Without that baseline, you cannot tell whether the chat created enquiries or simply moved them from the form.
Substitution is the common outcome and nobody checks for it.
The substitution question
If form submissions fall by roughly what chat captured, you have changed the channel rather than increased the total. That might still be worth it if chat leads convert better, and that is a different claim requiring its own evidence.
The content gap output
Conversations where the bot could not answer are a ranked list of questions your site does not address. That output is worth having regardless of whether the chat converts anyone.
Many teams find this more valuable than the leads.
What not to report
Conversations handled, messages exchanged, response time of the bot itself. All rise with traffic and none indicates value.
The honest review at ninety days
Did qualified enquiries increase, did the out-of-hours gap close, and did anyone act on the content gaps. If all three are no, the widget is costing you a subscription and some goodwill.
Six mistakes
1. Treating the knowledge base as setup. It is the product. Thin or stale material produces confident wrong answers, and fluency makes them more convincing rather than more accurate.
2. Not telling it what you do not do. Without an explicit out-of-scope list, it infers from adjacent material and describes services you do not offer.
3. Launching without a handoff plan. An alert nobody answers leaves the visitor worse off than no chat at all, because they were promised a person.
4. Letting it pretend to be human. People work it out, and the discovery colours everything else. A disclosed assistant that is useful bothers nobody.
5. Treating lead scores as probabilities. They are a sort order with weights someone chose. Calibrate against actual conversions after a quarter, which almost nobody does.
6. Measuring conversations instead of enquiries. Chat volume rises the moment you install it. Record three months of enquiry volume beforehand or you cannot tell what changed.
The pattern
Most come from treating this as software to install rather than a service to run. The software takes minutes; the knowledge, the boundaries and the responding are the work.
The one to do before launch
Write the list of things your business does not do, and feed it in.
Ten minutes, and it prevents the failure mode that does the most damage: a confident answer about something you do not actually offer.
FAQs
Does a website chatbot actually generate leads?
It captures some visitors who would otherwise leave without contact, particularly outside working hours and people who would never fill in a form. How many depends on your traffic and category.
Scripted or AI-powered?
Language-model bots handle varied phrasing and can state things your material does not support. Scripted bots only say what you wrote and fail visibly on unexpected questions. For regulated or price-sensitive answers, tight boundaries matter more than flexibility.
What do I need to set up first?
The knowledge base, including an explicit list of what you do not do. That list is the single most effective safeguard against confident wrong answers.
Should the chatbot say it is a bot?
Yes, in the first message. People work it out either way, and the discovery damages trust more than the disclosure ever would.
Is lead scoring reliable?
As a sort order, yes. As a probability, no: the weights were chosen by someone. Compare scores against actual conversions after a quarter and adjust.
What happens outside business hours?
Say so specifically: our team is back at nine, leave your details and we will reply first thing. A kept commitment beats an instant non-answer.
What are the data protection implications?
Transcripts contain personal and sometimes sensitive information, which brings obligations around notice, retention and access. Add a privacy note at the start of the chat and check with whoever owns compliance.
How do I know if it is working?
Record three months of enquiry volume before installing. Then compare qualified enquiries, not conversation counts, and check whether form submissions simply fell by the amount chat captured.
Write the out-of-scope list
Before launching anything, write down what your business does not do: services you do not offer, sectors you do not serve, things people assume you handle and you do not.
Feed that in. Ten minutes, and it prevents the failure that does the most damage, which is a confident answer about something you cannot deliver.
Then
Build the knowledge base properly: documentation, pricing with conditions, process, policies.
Decide the handoff before launch: who, what hours, how fast, and what it says out of hours.
Disclose that it is an assistant in the first message.
Record three months of enquiry volume so you can tell what changed.
Read transcripts weekly for the first month. They are a content gap list.
Add the knowledge base to whatever checklist covers pricing and product changes.
On the product
Blazly Lead Engine covers the chatbot, knowledge base, scoring and handoff in one place. Verify the current pricing and trial terms before publishing, since the brief's figures need confirming.
Summary
A website chatbot captures visitors who would otherwise leave without contact, particularly outside working hours and those who would never fill in a form. Whether it helps comes down to two things the software does not provide: the quality of the knowledge base you feed it, including an explicit list of what your business does not do, and whether a named person actually responds when it hands over. Language-model bots handle varied phrasing well and fail invisibly by stating things your material does not support, which is why boundaries and weekly transcript reviews matter. Treat lead scores as a sort order rather than a probability and calibrate them against real conversions. And record enquiry volume before you install anything, because chat volume rises regardless and tells you nothing on its own.