Ease AIThe single most common reason a business kills its chatbot is that it invented an answer about pricing, policy or product specification in front of a customer.
Not a minor embellishment. A confident, specific, completely wrong statement that someone trusted because it came from the business's own website.
The term is hallucination. The consequence is lost trust. The fix is a set of practical guardrails that prevent the chatbot from ever speaking outside the boundaries you set.
Four matter: answer-source restriction, refusal design, escalation thresholds, and testing against the awkward questions.
Restrict the chatbot to named sources only
A chatbot without source restriction will answer from its training data. That training data includes every pricing page, every policy document and every product specification it has ever seen, from thousands of businesses, none of them yours.
The fix is retrieval-augmented generation. The chatbot searches a defined set of documents before it answers. If the answer is not in those documents, the chatbot does not invent one.
You control the document set. Product catalogue. Service terms. FAQs. Refund policy. Opening hours. Nothing else.
The chatbot cites the source. "According to your refund policy, returns are accepted within 30 days." That citation is checkable. You can audit every response against the document it claims to have used.
This is not optional. A chatbot that answers from memory is a liability, not an asset.
Design refusals for out-of-scope questions
Retrieval-augmented generation solves the problem of inventing facts. It does not solve the problem of being asked a question your documents do not answer.
A customer asks whether you can expedite an order placed last Tuesday. Your shipping policy says nothing about expediting. The chatbot has no source to cite.
A poorly designed chatbot will guess. A well-designed one will refuse.
"I don't have access to order-specific details. I've escalated your question to the team, and someone will reply within two hours."
That refusal must be explicit. The chatbot must recognise when a question is outside its scope and say so, clearly, without hedging.
The refusal must also offer a path forward. Escalation to a human. A contact form pre-filled with context. A callback request. Never a dead end.
Refusal design is where most implementations fail. The instinct is to make the chatbot helpful. The discipline is to make it accurate first.
Set escalation thresholds for uncertainty
Even when the chatbot has a source, it may not be confident in the answer.
The question is ambiguous. The policy document contains exceptions. The product catalogue lists variations but not the one the customer asked about.
You can measure confidence. Most platforms expose a score. Below a threshold you set, the chatbot escalates instead of answering.
"I found some information on this, but I'd like to check with someone who can give you the full picture. Can I connect you with the team?"
The threshold depends on risk. A chatbot answering questions about opening hours can tolerate lower confidence than one discussing warranty terms.
Set the threshold high at launch. Lower it only after you have reviewed a month of escalations and confirmed the chatbot is refusing questions it could safely answer.
The cost of one invented answer is higher than the cost of a hundred escalations.
Test against the awkward questions
This is the guardrail most implementations skip. It is also the only one that matters.
You have tested the chatbot against the questions in your FAQ. It answers them correctly. You launch.
Then a customer asks about the refund policy for a product bought on sale. Your policy covers refunds. It covers sale items. It does not explicitly state whether sale items are refundable.
The chatbot invents an answer.
The fix is adversarial testing. Give the chatbot every awkward, edge-case, exception-laden question your staff have ever fielded.
"Do you deliver to PO boxes?" "Can I return a custom order?" "What if I ordered the wrong size?" "Is the warranty valid if I bought it second-hand?"
Not the questions you want customers to ask. The questions they actually ask.
Document every failure. Refine the source documents to cover the gaps. Adjust the refusal logic to catch the ambiguities. Raise the escalation threshold if the chatbot is guessing.
Repeat until the chatbot either answers correctly or refuses cleanly.
This is not a one-afternoon task. Testing takes longer than building. If someone is quoting you two weeks for a chatbot, ask how much of that is testing time.
When not to deploy a chatbot
If your business has complex exceptions, conditional pricing, or product recommendations that depend on unstructured customer input, a chatbot may cost more trust than it earns.
A chatbot can handle "What are your opening hours?" It cannot handle "Which of your three service tiers is right for a business like mine?" without either oversimplifying or inventing criteria.
The honest answer is often that you are not ready. Your documentation is incomplete. Your policies have exceptions that are not written down. Your staff handle edge cases with judgment, not rules.
In that case, do not buy a chatbot. Fix the documentation first. If the knowledge is not written down in a form a human can follow, a chatbot cannot follow it either.
I lose work every month by saying this. I would lose more by deploying a chatbot that invents answers.
What this costs
A chatbot built without these guardrails is cheaper. It is also worthless.
A chatbot built with source restriction, refusal design, escalation thresholds and adversarial testing takes two to three weeks and costs between $3,500 and $8,000. That includes the testing time.
Monthly support, if you need ongoing refinement as your business changes, is $500 to $2,000 per month. Month-to-month, not a contract.
If you are an Ontario business with 1 to 499 full-time employees, the Digital Modernization and Adoption Plan through the Ontario Centre of Innovation covers up to $15,000 at 50% matched cost. That funding explicitly covers hiring an external consultant to produce a digital adoption plan, which can include scoping and implementing a chatbot. Funding is first-come, first-served. Ontario added $5 million to the programme on 20 May 2026.
If you operate a retail business with a physical storefront, 1 to 50 employees, and over $100,000 in revenue, the Retail Modernization Project Grant covers up to $5,000 at 50% matched cost. You cannot combine it with DMAP.
Both programmes require you to identify the consultant yourself. I work with businesses across Burlington, Oakville, Milton, Hamilton, the wider Niagara Region, London, Mississauga and Toronto to secure that funding.
If you are outside Ontario, these programmes do not apply. Pricing does.
Where to start
If you are considering a chatbot, the first question is not whether the technology works. It does.
The first question is whether you can write down, clearly and completely, the answers you want the chatbot to give.
If you can, the build is straightforward. If you cannot, the chatbot will expose that gap in front of your customers.
You can reach me at info@easeaiworks.com or review the AI chatbot service page for details on scope, timeline and what the process looks like.
If you would prefer to see pricing and timeline for your specific situation, the scorecard asks six questions and returns a cost estimate. It takes two minutes.