Chatbot or knowledge assistant: which does your business actually need?

"We want a chatbot" is one of the most common requests we get, and it describes at least two completely different projects.

In a demo they look the same: a box, a question, an answer. Underneath they differ in content, in how often that content changes, in what happens when the answer is wrong, and in who is embarrassed when it is. Those differences drive most of the cost.

Getting this wrong is expensive in a specific way. You do not find out on launch day. You find out three months later, when the thing you built is technically working and nobody uses it.

The two things people mean

A website chatbot answers people who do not work for you. Prospective customers, mostly. What do you do, what does it cost, are you open on Saturday, can I book.

Its defining characteristic is that its knowledge is small and fairly fixed. A few dozen facts. They change when the business changes, which is not often.

A knowledge assistant answers people who do work for you. What is the leave policy, how do I get access to the deployment tool, what is the process for a refund over a certain amount.

Its defining characteristic is that its knowledge is large and constantly moving. Hundreds of documents, edited by many people, some contradicting each other, some out of date and nobody has noticed.

The AI part is roughly the same in both. Everything around it is not.

The test: who asks, and how often does the answer change?

Do this before you talk to anyone. Write down the last twenty questions somebody actually asked. Not hypothetical ones — real ones, from your inbox, your chat, your support queue.

For each, mark two things: who asked (customer or colleague) and when the answer last changed (this month, this year, never).

The shape of the answer is usually obvious once it is on paper:

• Mostly customers, answers rarely change → a website chatbot, and possibly not even that. A well-written FAQ page may be enough, and it helps your search visibility, which a chatbot does not.
• Mostly colleagues, answers change constantly → a knowledge assistant, and the real project is as much about your documentation as about the AI.
• A genuine mix → two projects. Do the one with more questions first.

It is worth being honest at this step. Businesses often want the customer-facing chatbot because it is visible, while the actual pain is internal. Visible is not the same as valuable.

Why being wrong costs differently

This is the difference that drives the engineering.

A customer-facing bot that is wrong is wrong in public. It might quote a price you do not offer, promise a service you do not provide, or contradict your terms. There may be a screenshot. In some jurisdictions there may be a contract.

So customer-facing assistants need tight scope, an explicit refusal behaviour, and review before launch. The correct answer to a question outside its knowledge is "I do not have that — here is how to reach a person", every time, not a plausible guess.

An internal assistant that is wrong wastes time and is usually caught. An employee reads an answer that does not match what their manager says and asks. Annoying, not dangerous.

But internal assistants carry a risk customer bots do not: access. Your internal documentation contains salary bands, supplier terms, unreleased plans, and personal information. An assistant that indexes "all of the shared drive" will happily surface any of it to anyone who asks the right question. Deciding what goes into the index — and what different groups of people may retrieve — is part of the project, not an afterthought.

The part nobody budgets for: content

Here is the thing that decides whether either project succeeds, and it has nothing to do with AI.

The assistant can only be as good as what it reads.

If your leave policy exists in three versions — the PDF from two years ago, the updated one in someone's email, and what HR actually does now — the assistant will find the PDF, answer confidently, and be wrong. It has no way to know which is current. It is not lying; it is reporting what it found.

So a realistic project includes a content pass:

1. Inventory. What documents exist, where, and who owns each one.
2. Cull. Delete or archive superseded versions. This step alone often produces the biggest improvement, before any AI is involved.
3. Fill the obvious gaps. The questions people keep asking that have no written answer anywhere.
4. Establish ownership. Each document has a person responsible for it being current.
5. Decide the update path. When a policy changes, what makes the assistant reflect it? Usually re-indexing on a schedule or on edit, but somebody has to own that too.

Businesses sometimes push back on this, reasonably, because they came for AI and are being handed a documentation project. The honest framing is that steps 1 and 2 are worth doing regardless. If you do them and then decide not to build the assistant, you have still fixed something real.

What "retrieval" means, and why it matters to you

The standard architecture is retrieval-augmented: your documents are indexed, a question finds the most relevant passages, and those passages are handed to the model as context for composing an answer.

Three consequences worth understanding, because they come up in every one of these conversations:

Your documents are not used to train the model. They are looked up at question time. This matters legally, and it matters practically — changing an answer means editing a document, not retraining anything.

The assistant can cite its source. Because the answer was built from specific passages, it can say which. Insist on this. Citations turn an unverifiable answer into a checkable one, and they are what makes people trust the thing over time.

Retrieval quality is the bottleneck, not the model. If the right passage is not found, no model can answer well. Most disappointing assistants are disappointing at the retrieval step — the content is poorly structured, or chunked badly, or the question phrasing does not match the document's vocabulary. This is where the tuning effort actually goes.

Scoping either one honestly

Questions worth answering before you commit:

For a customer-facing chatbot

• What are the twenty questions it must handle?
• What must it never attempt — pricing, legal, availability commitments?
• How does someone reach a human, and how obvious is that path?
• Who reviews its answers before launch, and how often after?
• What does it do outside opening hours, when the handoff is not available?

For an internal knowledge assistant

• Which documents are in, and which are explicitly out?
• Are there groups of people who must not see certain content?
• Who owns keeping each document current?
• What triggers re-indexing?
• How does someone report a wrong answer, and who acts on it?

That last one matters more than it sounds. An assistant with no feedback path degrades, because errors accumulate invisibly. One with a "this was wrong" button that reaches a person who can fix the underlying document improves on its own.

A reasonable order to do this in

If you are starting from nothing:

1. Write down the real questions. A week of collecting them.
2. Answer the top ten properly, in writing. You now have documentation that is useful with or without AI.
3. Decide which audience hurts more. Build for that one.
4. Start narrow. One department, or one category of question. A narrow assistant that is right is worth more than a broad one that is unreliable.
5. Measure whether it is used, not whether it works. Usage is the honest signal.

We built an internal assistant that helps employees understand company policies, find workplace knowledge, and get set up on company tools — the questions new joiners ask in their first month. The hard part was never the model. It was deciding what it should refuse to answer, and where it hands the question to a person.

If you are trying to work out which of these two you need, that is a good use of a free consultation. Bring your twenty questions.