Knowledge bases for voice agents: documents and testing

Choose information your team trusts

A voice agent knowledge base should contain task-specific approved information: hours, services, policies and frequent answers. Assign an owner and review date to each source. When documents disagree, establish the current rule before making the material available to the agent.

Use clear headings, short paragraphs and examples. A service list should explain what each service includes; an internal label alone may not help answer a caller's question.

Check processing and attachment

Upload the document to Tigy's knowledge base and wait for processing. Then select it in the agent's knowledge settings and save. A file in your workspace does not automatically become a source for every agent.

Attach materials relevant to the task. A reception agent does not need the entire sales library to explain how to reach your office.

Documents and live lookups serve different purposes

A document can explain a delivery policy. To know where an order is now, the agent must look it up in the system tracking that purchase. The lookup requires a prepared integration, such as an HTTP tool: a connection for requesting information from another system.

Define how the agent should explain a missing answer and offer a next step. A plausible answer is not a substitute for an available source.

Test before and after updates

Ask a question directly answered by the file, one using a different section and one outside the material. Compare the spoken answer with the source, including numbers and exceptions.

• Has processing finished?
• Is the correct agent using the current source?
• Are contradictory materials selected?
• Does an unanswered question receive a clear next step?

Test answers and missing answers

Consider a company with two branches and different opening hours. The document must connect each branch to its own hours without mixing one address with the other's schedule. Test direct questions, unspecified branches and comparisons.

Then ask for something absent, such as a clinician's availability tomorrow. The expected behavior is to acknowledge missing information and follow the permitted route, not infer an individual calendar from opening hours. Knowledge quality includes recognizing when the source cannot answer.

When investigating failures, verify processing completion and selection for the tested agent. Then examine ambiguity, outdated versions and missing information in the source. Prompt changes can improve the conversation but do not replace correcting contradictory documents.

Update with traceability

An opening-hours change should begin in the approved document. Update the source, verify processing, review agent selection and rerun affected questions. Avoid attaching contradictory versions to the same service. Archived content should not compete with current guidance.

Keep a simple change record containing the updated information, owner, affected agents and tests. Incorrect answers can then be traced to approval, processing, association or interpretation.

Measure correctness by question type rather than only an overall average. Easy address questions can conceal cancellation or service-condition errors. Include informal language, specific rules and questions without answers. This evaluation can be manual; it does not assume every measure is automatically available in a Tigy dashboard.

Questions about documents and current information

Can everything be placed in one file? Topic-based documents make review and selection easier. Clarity matters most: rules need enough context to remain understandable when retrieved as excerpts.

Does uploading activate the source? No. Processing must complete and the document must be selected for the agent. Check both before investigating model behavior.

Should individual customer records go in the knowledge base? General policies and approved guidance belong in documents. Account or order information should come from an authorized lookup when required. Do not use a shared knowledge collection as a substitute for controlled access to personal records.

Inventory questions and sources

A knowledge base starts with information customer service needs to retrieve, rather than the quantity of available files. List recurring questions and associate each with an approved source. Branch hours, return policy and service conditions may be scattered across pages, manuals and internal messages. Mapping them reveals both gaps and conflicts before the agent starts answering.

Record ownership and applicability for each source. A rule may apply to one branch, product or contract. If those conditions are absent, the agent may apply correct information to the wrong case. Include scope in readable document content instead of relying on a filename whose meaning is unclear to the reader.

Separate public information, internal service guidance and individual records. A general policy explains a process; it does not confirm a particular purchase's current status. Shared files should not replace authorized retrieval from current systems. That boundary also simplifies maintenance: policy usually changes less often than individual customer records.

Consider a fictional store with two locations. A manual says pickup closes at six, but an old page says seven. Do not upload both and expect the model to discover which is correct. Verify with the responsible owner, correct or remove the outdated source, and test questions mentioning both times. The answer should correct outdated assumptions.

Also define which questions documents cannot answer. Expected absences help test whether the agent acknowledges limits and offers a valid alternative. A reliable knowledge base does not need to answer everything; it needs to distinguish available information from insufficient evidence.

Write content preserving conditions and exceptions

Documents written for marketing do not always serve customer support well. “Fast delivery for everyone” is vague. A useful policy states supported areas, calculation conditions, exceptions and where to retrieve an individual estimate. You need not write artificial sentences for the model; you need to make explicit what a person would require to answer accurately.

Use headings corresponding to actual questions. A cancellation section should explain eligibility, how to request cancellation and which confirmations depend on a system. Avoid separating important exceptions from the general rule. Keep required context near the answer. This reduces the chance that incomplete information will appear unconditional.

Review tables and lists carefully. A price may depend on currency, billing period and contractual conditions. If these appear only in a detached note, retrieved information can lose its meaning. Put units and conditions alongside values where possible. For frequently changing content, consider whether live system retrieval is more appropriate than a static document.

Try an oral explanation exercise. Read the information to someone unfamiliar with the process and ask what they understood. A correct policy filled with abbreviations and internal references may produce answers difficult to follow aloud. Add definitions and customer vocabulary without removing necessary precision. The agent can explain plainly, but the source must supply the limits.

Do not embed conflicting behavioral instructions in documents as though they were facts. Sources explain policy; agent instructions define how to converse and act around it. If an old file tells the agent to confirm every request while the prompt requires system confirmation, that conflict can complicate evaluation. Review documents mixing operational commands and factual information.

In Tigy, verify document processing and association with agent sources. Completed upload alone does not establish that a particular conversation retrieves the material. Ask a question answerable only from the selected source to check configuration, then ask an absent question to examine boundaries.

Test updates using old questions

A policy update requires more than adding a new document. Identify the earlier copy, review source selection and confirm ownership. If the old file remains available, retrieval may encounter incompatible answers. Removing superseded content belongs to maintenance, with appropriate care to preserve information still valid.

Prepare a small question collection tied to primary sources. Include direct wording, an informal version and a question using an outdated premise. Repeat all three after an update. The outdated-premise case is particularly useful: it shows whether the agent accepts the customer's statement as fact or corrects it from approved information.

When an answer fails, examine whether necessary content exists, was retrieved and was explained accurately. These are distinct stages. Missing documents require source updates. Available information absent from responses may require investigating selection or retrieval. An explanation distorting a condition requires instruction review and additional test examples.

Track unanswered questions as editorial demand as well. Group them by topic and frequency, but do not automatically turn individual reports into policy. An owner must approve information before incorporating it. This discipline preserves the knowledge base as a reliable reference and allows broader coverage without confusing service observations with company rules.

Document the expected fallback alongside this collection. A useful answer to an unsupported question explains the limit and the next available action. Reviewing both successful retrieval and correct fallback prevents coverage expansion from becoming a pressure to answer confidently regardless of evidence.