We build chatbots that read your documents before they speak. Every answer is traced back to a source your team can open, and when nothing in your content covers the question, the bot says so and hands the customer to a person.
The grounding loop
An AI chatbot development company builds conversational systems grounded in your own documents using retrieval-augmented generation, so answers cite a source instead of being generated from memory. When no source matches, the bot escalates to a human rather than guessing.
We have been asked to replace four of them. The pattern is consistent, and it is never that the model was not clever enough.
A bot connected straight to a general model will produce a plausible refund policy, a plausible warranty period and a plausible delivery timeline, none of which are yours. One invented commitment made in writing to a customer costs more than the salary the bot was meant to save, and it is the single reason most pilots never get past legal review.
The previous generation of chatbots were flowcharts. They worked for the eleven paths somebody drew, and every new product or policy meant another branch. After two years nobody was willing to touch the tree, so it slowly drifted out of date while still confidently answering from it.
The bot gives up, opens a ticket, and the customer explains everything again to an agent who cannot see the conversation. That experience is worse than no bot at all, and it is a routing problem rather than an AI one. Handoff design belongs in the first sprint, not the last, which is why this page and support automation are usually scoped together.
Three versions of the same policy live in three folders, and two of them are superseded. Retrieval will surface whichever one scores highest, which may be the 2022 draft. A chatbot does not create this problem, it makes it visible, and cleaning the corpus is usually the largest single task in the build.
A provider ships a model update, a prompt gets edited, someone reorganises the document folder. Any of these can degrade answer quality without producing a single error in the logs. Without a fixed evaluation set that runs on every change, the first signal you get is a complaint. This is standard practice in our LLM development work and it is not optional here.
The chat window is the last thing we build. These are the parts that decide whether it survives contact with real customers.
Naive chunking splits a table across two chunks and the answer becomes unretrievable. We chunk with structure preserved, keep headings attached to the text they govern, and run hybrid search so that an exact product code or invoice reference is matched literally while the surrounding question is matched semantically. Retrieval quality, not model choice, is what separates a chatbot that works from one that nearly works.
Where the source material arrives as scanned PDFs rather than clean text, extraction comes first — that overlap is handled by our document processing service.
Before a line of conversation logic is written, we agree three things on paper: the similarity score below which the bot must not answer, the topics it may never discuss regardless of retrieval, and exactly what it says when it declines. That document is what your compliance team signs, and it is what makes the system defensible later.
When the bot escalates, the agent receives the transcript, the retrieval trace and the reason for the handoff. No customer should have to repeat themselves because a system changed hands.
A public chatbot is an untrusted input surface. Retrieved content is treated as data rather than instruction, tool access is scoped, and system rules are not recoverable by asking politely. Covered in depth under AI governance and security.
Golden questions with expected answers, and questions the bot is expected to refuse. Run in CI on every prompt, index or model change, so a regression is caught by a build rather than by a customer.
Reading an order status is safe to automate. Cancelling that order is not, and the difference is not technical difficulty, it is reversibility. We let the bot perform read-only lookups freely, and route anything that writes to a record through an explicit confirmation that is logged against an identity.
Past a certain point that stops being a chatbot and becomes an AI agent, with a different set of controls around it. We will tell you which one you actually need.
The one your current bot gets wrong. We will show you what retrieval returns for it.
Four questions asked of the same grounded chatbot, built on a sample policy set. Two are answered, one is clarified, one is refused. The refusal is the feature.
Ask the bot
01 · Intent
Classified as billing.refund_policy. In scope.
02 · Retrieval
03 · Grounding check
PASS — top score 0.89 above threshold 0.72, two independent sources agree
04 · Response
Annual plans can be refunded in full within 14 days of the charge date. After that the plan runs to the end of its term and does not auto-renew if you cancel.
Source: refund-policy-v4.pdf §2
This genuinely is a sequence — each step depends on the one before it. Skipping step two is the most common and most expensive mistake. It follows the same five-stage shape we use across the whole AI and automation practice, with the corpus work standing in for process mapping.
We pull 90 days of tickets, chat logs and enquiry emails, cluster them by intent, and find the repeat set. This is what decides scope, and it is what decides which documents matter. Teams consistently guess this wrong: the question they most want answered is rarely in the top twenty by volume.
We agree which documents are authoritative, remove superseded versions, and get contradictions settled by whoever owns the policy. Two documents disagreeing is a business problem the chatbot will expose rather than create, and it is far cheaper to fix now than after a customer has quoted the wrong one back at you.
Documents are chunked with their structure preserved, embedded, and indexed in a vector store inside your own infrastructure. Search is hybrid, so exact identifiers match literally and natural questions match semantically. We tune this against your real question set, not a benchmark.
The similarity threshold below which the bot must not answer, the topics it may never discuss regardless of retrieval, the citation requirement, and the exact wording of a refusal. All agreed in writing before the conversation layer is built.
A fixed set of golden questions with expected answers, plus a set the bot is expected to refuse. It runs in CI and becomes your regression suite. Any future change that drops the score gets caught by a build rather than by a customer.
Live on the agreed channels, with handoff wired into a real queue rather than an unwatched inbox. Containment rate, escalation rate and retrieval-miss rate go on a dashboard, and every unanswered question is logged as a content backlog item. That log is usually the most valuable thing the first month produces.
Named tools, grouped by the job they do. Selection depends on where your data is allowed to live, which is a question we settle before anything else.
Where the chatbot needs to reach into an ERP, order system or CRM to look something up, the connection work is covered by AI integration services, and the front-end widget itself is built by the same team that handles our custom web development engagements.
Every input here is yours to set, including the deflection rate. We are not going to assert an industry average at you — put in the number you would actually defend.
Tickets, chats and enquiry emails combined.
Answerable from an existing document, not a judgement call.
Of those repeat questions, the share fully resolved without an agent.
Minutes of agent time per conversation, including wrap-up.
Deflected per month
1,080
conversations resolved without an agent
Agent hours back
144
per month
Still escalated
2,920
conversations per month
Formula: volume × repeat share × deflection rate, then multiplied by handling time for the hours figure. Note the escalated column — it stays large, and it should. A chatbot that claims to remove your support team is describing a different business to yours.
Test this against your logsSame retrieval layer behind all of them. The constraints are different enough that they change what the bot can promise.
Six scenarios from sectors we work in, filtered by what the bot is actually doing. Profiles are anonymised.
Showing all six use cases.
A regional freight operator fielded most of its inbound calls as one question: where is my consignment. A WhatsApp bot that authenticates on the sender's number and reads the tracking system answers it in seconds, and escalates anything involving a claim.
Logistics engagementsA multi-site clinic answers preparation instructions, timings and documentation requirements from its own patient handbook. The grounding policy blocks anything that could read as clinical advice outright, regardless of what retrieval returns.
Healthcare engagementsFor a lender, a paraphrased interest term is a compliance incident. The bot is configured to quote product documentation verbatim with a citation rather than summarise it, and every conversation is retained for audit.
Banking and insuranceSupervisors at a manufacturing plant query maintenance procedures and tolerance specs from a Teams assistant instead of finding the right binder. Retrieval keeps the revision number attached, so nobody works from a superseded procedure.
Manufacturing engagementsA professional services firm indexed five years of proposals and methodology documents. Consultants ask what was committed on a similar engagement and get the passage plus the document, which cuts the internal question round-trip out entirely.
Consulting providersA non-profit running a grant programme handled thousands of near-identical eligibility enquiries per cycle. A grounded bot on the programme guidelines absorbed most of them, leaving the small team to handle genuine edge cases properly.
Non-profit and NGOThe behaviour in the second row is the one that decides whether the project survives its first legal review.
| Criterion | Scripted decision tree | LLM with no grounding | Grounded RAG chatbot |
|---|---|---|---|
| Where answers come from | Paths someone wrote by hand | The model's training data | Your documents, retrieved per question |
| When it does not know | Falls back to a menu, or loops | Produces a fluent, plausible, unverifiable answer | Says so and escalates with the transcript attached |
| Updating it | Edit the tree; every change risks a branch | Rewrite prompts and hope | Update the document and re-index |
| Auditability | The path is traceable, the content is stale | No source exists to audit against | Every answer carries its retrieved sources and scores |
| Handles unanticipated phrasing | Poorly; it was not in the tree | Very well, which is the problem | Well, but only within what your content covers |
| Cost of being wrong | Customer frustration | A written commitment you did not make | A missed deflection, and a logged content gap |
Grounding is not free. It caps the bot at what your documentation actually says, which means thin content produces a bot that refuses a lot. That is the correct behaviour, and the fix is writing the missing page rather than loosening the threshold.
A chatbot rarely arrives alone. These are the neighbouring pieces of the AI and automation practice that come up most often in the same conversation.
The layer around the bot: intent routing, agent-assist drafting, escalation queues and voice. If deflection is the goal, this is where the rest of it lives.
When answering is not enough and the system needs to write to records, place orders or run a multi-step process on the customer's behalf.
The deeper engineering underneath: RAG architecture choices, evaluation harness design and model-agnostic deployment.
Where the chatbot is qualifying rather than supporting, and conversations need to become scored records in your CRM.
A public chatbot is an internet-facing input surface with access to internal content. Our VAPT team reviews it the same way they review any exposed service.
The business-side framing of the same problem, for operations leaders deciding where to spend an automation budget.
The ten that come up in almost every first conversation.
Twenty of them and the documents that answer them is enough for us to tell you what a grounded chatbot would and would not handle. We reply in under 3 minutes.
