An AI robot answers by searching the documents you supply and rephrasing what it finds. That means answer quality rests on three things: whether the documents are complete, whether they are organised well, and whether they are kept current.
Start from questions, not from existing documents
The common wrong approach: upload every company document and hope the robot finds things. Results are usually poor because company documents were written for other purposes.
The right approach: start from a list of questions. Record what customers actually ask over one week. Sort by frequency. This is the spine of the knowledge base.
Write an answer for each. Short, direct, complete enough for the robot to use without inference.
Then add background documents. For the less common questions.
Why this order matters. The thirty most common questions typically cover a very large share of real interactions. Doing that part well first produces the fastest result for the least effort.
It also avoids a common trap: spending three months preparing complete documentation before launching, when the robot could have been running in two weeks with thirty questions and improved from there.
Writing a knowledge entry
One entry answers one thing completely. Long passages mixing topics cause the robot to retrieve the wrong part.
Title it with the question itself. This improves matching.
Answer in the first sentence. No preamble. The robot may take only the opening portion.
Use the customer's vocabulary. Not internal terminology. If customers say basic package and the document says a product code, the robot cannot connect them.
Include alternative phrasings. The same question is asked many ways. Listing a few variants improves matching considerably.
Date time-limited information.
State certainty explicitly. Separate fixed information from expected or indicative information.
Write what you do not do. Services not offered, areas not covered. This lets the robot decline correctly instead of guessing, and it matters as much as the positive information.
Structure and permissions
Group by what customers care about. Products, pricing, process, contact, policy. Not by department.
Separate stable content from volatile content. Company information changes rarely; prices and promotions change constantly. Separating them makes updates tidier and lower risk.
Assign editing rights. Who may change what. Pricing and commitment content should require approval.
Maintain a prohibited list. Topics the robot must not answer and must transfer instead — complaints, professional advice, firm pricing.
Keep change history. So that when a complaint arrives, you know what the content said at the time.
One source of truth. If the same fact lives in two places, one day they will differ and the robot will retrieve the wrong one.
That last principle is the most important structurally and the easiest to violate once several people contribute content.
Quality checking
Without checking, you do not know what the robot is telling customers.
A standard test set. Twenty to thirty questions covering the main topics with known correct answers. Run it after every significant content change.
Weekly spot checks. Ask ten common questions. Ten minutes, and it catches most stale content.
Read conversation logs. A random sample weekly. You will find wrong answers nobody complained about — customers simply left.
Track unanswered questions. This list generates itself and is the best source for what to add.
Deliberately test difficult cases. Ambiguous questions, out-of-scope questions, sensitive questions. See how the robot handles them. This is the most-skipped area and the highest-risk one.
Have outsiders test it. People inside the company ask the way people inside the company think. Real customers ask differently, and one session with a few outsiders usually surfaces several issues.
Long-term maintenance
This decides whether the robot remains useful after a year.
Attach it to existing processes. Price changes, new services, changed hours — updating the robot must be a step within that process rather than a separate task easily forgotten.
One named person responsible. With the work recognised as part of their role.
Review everything periodically. Read the whole set each quarter, even with no reported changes. Something is always out of date.
Delete unused content. A bloated knowledge base makes retrieval less accurate. Content about discontinued products should be removed rather than retained just in case.
Record decisions. Why a particular answer was phrased a particular way. The next person will need to know.
Measure and report. Monthly: questions handled, accuracy rate, new entries added. Reporting keeps the work visible and valued.
Frequently asked questions
Where should a knowledge base start?
From a list of what customers actually ask over one week, sorted by frequency. The thirty most common questions cover a very large share of real interactions, so doing them well first produces the fastest result.
Why not simply upload all company documents?
Because they were written for other purposes — organised by department and using internal terminology. The robot struggles to retrieve the right passage and phrases it in ways that do not match how customers ask.
Why write what the company does not do?
So the robot declines correctly instead of guessing. Information about services not offered and areas not covered matters as much as the positive information and prevents a category of wrong answers.
What is the most effective quality check?
Reading a random sample of conversation logs weekly, because it reveals wrong answers nobody complained about — customers simply left quietly. Combined with having people outside the company test it.
More in Robots for business and Deployment and operations.
