← Back to articlesKnowledge and support

Company information is scattered: what should you prepare for a knowledge base?

Specifications live in a product sheet, service rules sit in chat histories, and the same questions keep coming up. This can be a starting point for a knowledge-base trial. First establish which documents are trustworthy, who updates them and what happens when an answer cannot be found.

Start with one document category and a set of common questions. Check whether the assistant finds evidence, answers correctly and stops when there is no basis for an answer.

Define who needs to find which information

Helping employees find operating instructions differs from answering customers' product questions. Permissions, wording and confirmation requirements vary. Identify the users first, then choose a frequently searched topic with reasonably complete documentation.

Knowledge-base question answering typically retrieves documents before generating an answer from them. This is often called RAG. Its usefulness depends on the documents being correct, retrieval finding the right material and answers staying within what that material supports.

A first trial can focus on finding information and assisting with answers. Changing orders, updating stock or committing to refunds requires a separate review of interfaces, permissions and human confirmation.

My part in a brand customer-support project

According to the project notes, in a customer-support customization project for a UK water-filter brand, I handled knowledge organization, retrieval configuration and testing, working with the team from demonstrations through customer confirmation and live-site tests. The team handled version backups, deployment and upgrade rollback preparation.

The available public records show the initial support interface, welcome message, quick support options, question input and contact entry. They do not independently demonstrate answer accuracy or time saved. Neither has measured results in the available records.

The case page labels its sample answers as AI-written illustrations. They are not real support conversations or evidence of customer outcomes. Assessing answer quality requires records linking actual questions, answers and cited documents.

Prepare four things in your documents

You do not need to upload every company document on the first day. Pick one small topic and create a document set that can be checked and updated. Do not use files for testing without permission.

  • Source: which document is authoritative for product parameters, operating steps and service rules?
  • Version: who maintains each document, when is it updated, and how are old versions retired?
  • Access: what is internal-only, and what can be used in external answers?
  • Boundaries: which questions can be answered directly, which need clarification, and which require a person?

If documents conflict, ask the responsible person to resolve the conflict first. Do not let a model guess which one is true. A fluent answer about something missing from the knowledge base is not evidence that it is correct.

Test with questions people actually ask

Collect common employee or customer questions, remove personal information and ask the business owner to identify acceptable source material. During testing, review the question, answer, cited content and human judgment together.

  • The answer exists: does retrieval find the right document, and does the citation actually support the answer?
  • The question is unclear: does the assistant ask for the model, context or other necessary details?
  • The documents have no answer: does it say it cannot confirm and point to the responsible person?
  • The material changes: are old versions excluded, and does the answer reflect the update?

Rather than rushing to report an accuracy figure, record the specific failure: missing evidence, the wrong version, a misunderstanding or a commitment beyond the source. Each needs a different correction.

Estimate search effort before arranging a small trial

Hypothetical calculation, not measured data from the brand support project

Assume the team looks up information 20 times a day, averaging 4 minutes per lookup, across 20 working days a month. This example illustrates workload; it is not an industry average or a customer measurement.

Current lookup time (assumed)
20 lookups × 4 minutes = 80 minutes a day
If a trial measures 2 minutes per lookup
40 fewer minutes a day
Monthly time difference
40 minutes × 20 days = 13 hours 20 minutes

Include time spent verifying answers, identifying errors and handing over to a person. If repeated corrections cancel out faster lookups, the trial has not demonstrated an efficiency gain.

Further investment also depends on subscriptions, document maintenance, employee learning and implementation costs. Test your own tasks before applying someone else's percentage.

Start with a question that keeps coming up

For example: “We have product manuals and service instructions. Our support team keeps looking up the same specifications. Could we help employees find the source faster?” This makes the trial scope clearer than choosing a model first.

The initial conversation is free. Before implementation, agree on the document scope, typical questions, citation requirements, human handover and acceptance checks, then confirm the fee. Complex integrations, permissions and ongoing maintenance need separate assessment.

Start with anonymized material you have permission to use. Do not send account passwords, customer personal information or unprocessed internal files during the initial conversation.

Start with one task

Describe the current process and its slowest step. The initial conversation is free.

Let’s talk ↗
See knowledge-base and support services ↗

Keep reading