AI chatbot development services for internal knowledge
We build assistants that answer from a defined set of your own documents, cite the passage they used, and refuse when nothing in scope supports an answer. Read-only to begin with, always.
Most of the work in a custom AI chatbot happens before anyone types a question: choosing which documents go in, getting them into a shape retrieval can use, enforcing who may see what, and testing for wrong answers rather than fluent ones. That work decides whether the thing still earns its place in month six.
Assistant, chatbot, or agent
Three different products get sold under one word, and anyone quoting for AI chatbot development services should say which of them they are building. They differ in the respect that matters most: what each is allowed to change.
| Type | What it does | What it can change | When it is wrong | What it costs to run |
|---|---|---|---|---|
| TypeInternal assistant | What it doesAnswers staff questions from an approved document set, with a link to the source passage | What it can changeNothing. It reads | When it is wrongAn employee gets a bad answer, sees the citation points at a 2023 policy, and flags it | What it costs to runQuery costs, plus a few hours a month keeping sources current |
| TypeCustomer-facing chatbot | What it doesAnswers a narrower, fully approved public set on your website | What it can changeNothing, but it speaks in your name, which can carry a disclosure obligation | When it is wrongA customer acts on a wrong delivery term and you hear about it as a complaint | What it costs to runQuery costs, transcript review, an escalation route into your helpdesk, a named content owner |
| TypeTask agent | What it doesReads, then writes: creates tickets, updates CRM records, sends replies | What it can changeRecords in live systems | When it is wrongA wrong record exists. Someone must find it, reverse it, and work out how many others are wrong | What it costs to runHighest: scoped credentials, an action log, a rollback path, someone who reads that log |
An autonomous agent is almost always the wrong first project. The technology is rarely what breaks. You simply have no evidence yet about how often the retrieval underneath it is wrong, and an agent turns a retrieval error into a database change. Start read-only. Once answer quality is measured rather than assumed, move to draft-only writes, where the assistant prepares the ticket and a person presses send. Autonomous action comes last, on the narrow set of cases where the error rate is known and reversal is cheap.
What the assistant is allowed to read
Source scope is a decision, not a data dump. Point an index at an entire shared drive and it will quote a rejected 2022 proposal with the same confidence as the live price list.
Normally in scope: SOPs and handbook sections carrying a version number and an approval date, product or service specifications where the spec is authoritative rather than a summary of it, policies HR or Operations confirm are in force today, and resolved support tickets stripped of customer names and account identifiers.
What stays out of the index, and why:
- Superseded policy versionsAn index has no way of knowing a document was replaced, only that it matches the question. Archive them somewhere retrieval cannot reach, rather than in the folder next to the replacement.
- Personal dataHR records, CVs and disciplinary notes belong in systems with individual access control.
- Draft or unapproved pricingThe assistant cannot tell a draft from a decision, and a quoted number is read as a commitment.
- Anything without a named ownerIf nobody is responsible for whether it is still true in nine months, it stays out.
- Email and chat threadsThey record discussion, not conclusions, and the conclusion is usually in the message nobody indexed.
Preparing documents so retrieval works
This is the unglamorous part, and it sets the ceiling on every answer the assistant will ever give.
An AI knowledge base does not search documents. It searches fragments of them. The pattern is called retrieval-augmented generation, or RAG. The interesting half is the retrieval. Each source is split into passages of a few hundred words, those passages are indexed, and at query time a handful of the closest matches go to the model with the question. The model answers from those passages. If the right passage was not retrieved, the model does not know that. It answers anyway, from whatever it was given.
That is why bad splitting produces confident wrong answers so predictably. A ten-step returns procedure cut between steps four and five produces a passage holding steps five to ten with no context. Ask how to process a return and you get a fluent, well-formatted answer that starts in the middle and omits the warranty check.
What goes wrong, and what fixes it:
- A 40-page PDF with no headingsNo natural boundaries, so it gets cut on arbitrary word counts. Add real headings, or split it by topic before indexing.
- TablesFlattened to text, a pricing or compatibility table becomes a row of numbers detached from its column labels. Convert it to labelled sentences, or keep it whole in one passage with the header repeated.
- Scans and image PDFsNo text at all. They need OCR first, and the output needs reading, because a misread part number retrieves nothing.
- Near-duplicate versionsTwo policies differing in one paragraph look nearly identical to a retrieval system, which cites whichever scores marginally higher. Remove the old one.
- Missing metadataEvery document needs a title, an effective date, an owner and a status. Without those fields nothing tells the assistant which of two documents is current, and nothing tells the reader that an answer came from the March 2026 handbook.
We hit each of these putting our own internal documentation and support request handling through the same pipeline. Budget real time for this stage. Expect it to be the longest task in the build, and one you are usually better placed to do with guidance than to hand wholesale to a chatbot agency.
What counts as a good answer
"It seems to work" is not an evaluation. Fluent output is the one thing these systems produce reliably, including when they are wrong. The method is a fixed evaluation set:
- The people who will use the assistant write 40 to 60 real questions in their own words, including the badly phrased ones.
- For each, record the correct answer and the document that should be cited.
- Include questions that must be refusedOut of scope, unsupported, or deliberately out of date.
- Re-run the set after every change to sources, prompt or model, and keep the dated results.
Grade three things separately, because they fail separately. Is the answer correct. Did it cite the right document or a plausible neighbour. Did it refuse when it should have. An answer that is correct but cites the wrong source is a warning. Retrieval missed, and the model filled the gap from general knowledge, which will not hold next time.
Review points and escalation
The assistant needs defined behaviour for the cases where it should not simply answer.
| Situation | Detection | What the assistant does | Who picks it up |
|---|---|---|---|
| SituationNo supporting source | DetectionNothing retrieved above the similarity threshold | What the assistant doesSays the document set does not cover this and gives the escalation route. No general answer | Who picks it upSource owner, via the unanswered-questions log |
| SituationWeak or conflicting sources | DetectionLow similarity, or top passages carry different effective dates | What the assistant doesAnswers from the current-dated source, names the date, flags the conflict | Who picks it upThe document owner named in the metadata |
| SituationQuestion outside scope | DetectionTopic matches the exclusion list: pay, contracts, disciplinary, legal, medical | What the assistant doesDeclines and routes to the named person for that topic | Who picks it upHR, Legal or the relevant lead, by topic |
| SituationAnswer would reach a customer | DetectionThe workflow is customer-facing by definition | What the assistant doesProduces a draft only. Nothing sends automatically | Who picks it upThe support or account owner for that customer |
| SituationUser disputes an answer | DetectionThumbs-down or written flag | What the assistant doesLogs question, retrieved passages and answer, so the failure can be reproduced | Who picks it upMaintenance owner, at the monthly review |
The similarity threshold in the first row is an output of the evaluation set above rather than a default copied from someone else's build. Run the must-refuse questions and the answerable ones through the built index, raise the threshold until every must-refuse question is declined, then measure what that costs in good answers now refused as well. Record the value with the date, the model and the document set it was measured against, because it does not carry over to another build.
The last column decides whether any of this holds. Escalation rules with no named person are decoration.
Keeping sources current
Every indexed document has an owner and a review date, both stored in metadata and visible to whoever looks after the assistant.
When a policy is replaced, the superseded version comes out of the index the day the replacement is approved. Removing something always feels riskier than leaving it where it is, which is why this is the rule to write down and hold people to. The archive still exists. It is simply not searchable.
Re-indexing runs nightly, with a manual run when someone approves a document in a hurry. Then a monthly review, and thirty minutes is usually enough: read the unanswered-questions log, read the disputed answers, re-run the evaluation set. That log is a ranked list of what your organisation has not documented, written by the people who needed it.
Maintenance needs one named owner. A committee or "the ops team" means nobody. If that role is empty at handover, the source set drifts out of date and the answers degrade quietly, because nothing announces the day a document stopped being current.
When an assistant is the wrong answer
Some answers live in a database rather than in documents. Order status, stock levels and invoice totals want a query, a report or an integration. Putting a chatbot in front of exported spreadsheets adds uncertainty to something that had an exact answer.
If a question comes up four times a year, write the page and put it where people look. Retrieval infrastructure is a poor substitute for one well-placed document. And if your documents contradict each other, fix that first. An assistant does not resolve contradictions. It picks one and states it confidently.
If being wrong carries legal, financial or clinical consequences, this is not the tool for the final answer. It can help someone find the relevant clause faster. It should not be what decides. And if nobody will own maintenance, do not build it at all. An assistant over stale sources is worse than none, because people stop checking the original.