How to build an AI voice agent knowledge base

The knowledge base is everything the agent knows about your business beyond the call scenario itself: answers to frequent questions, policies, opening hours and exceptions. A voice agent is only as good as the information it receives. So give it little, make it clear and correct, and write it to be spoken aloud, not read on a screen.

This guide shows what to include, how to write it for the ear, what to leave out, how to handle “I don’t know”, and how to test and maintain it without turning it into a project of its own.

Which documents and information should you give the agent?

Start from the phone, not from the office. Take the last 30 calls or messages you received and write down what people asked. That is the knowledge base your agent needs.

The agent answers from the documents and the website you connect during the “Agent and voice” step of the setup wizard, described on the how it works page. For initiated calls, data from the contact list is added (name, order number, appointment time), which you receive from your CRM or ERP through integrations.

The selection rule: if a piece of information never comes up in real conversations, it does not go into the first version. You can add it any time.

How do you write for the ear, not the screen?

A text that reads well on a page can sound awful on the phone. The caller cannot reread, cannot see tables and remembers little. Write the way you would explain something to a colleague over the phone.

Short sentences. One idea per sentence. If you need to breathe in the middle, cut the sentence.

Answer first, explanation second. The first words are the ones people actually hear.

• Weak: “Depending on the delivery area and courier availability, the delivery time may vary.”
• Better: “We deliver in two to three working days. Remote areas take one day more.”

Numbers that can be spoken. Write what is said, not what is seen.

• Times: “at half past nine”, not “09:30”.
• Amounts: “one hundred and twenty lei”, not “120 RON/pc.”
• Dates: “Tuesday the twelfth of May”, not “12.05”.
• Phone numbers and codes: grouped digits plus a confirmation rule (“let me read the number back to you”).

Proper names with pronunciation. If your company, products or street names are hard to pronounce, note next to them how to say them. Test them in the test call. This matters even more when the agent speaks one language and the names come from another.

No abbreviations or symbols. Write “street”, not “St.”; “pieces”, not “pcs”; “about”, not “~”.

No long lists. On the phone, three options is the maximum. If you have more, write “The three most popular are…” and then name those three.

A human tone. Polite but not stiff. Avoid internal jargon and department names the customer does not know.

What does a good question-and-answer entry look like?

The safest format is the question-and-answer pair, with variations of the question the way people actually say it. Here are three examples for a fictional company.

Question: How long does delivery take? Other ways people ask it: When will my parcel arrive? How long until I get my order? Answer for voice: We deliver in two to three working days after the order is confirmed. The courier calls you before arriving. Exception: Islands and hard-to-reach areas take one extra day. If the person insists on an exact date: I can’t guarantee a specific time. I’ll note your request and a colleague will get back to you.

Question: Can I cancel my appointment? Answer for voice: Yes. You can cancel or move your appointment free of charge up to one day before. Would you like to move it now? Exception: On the day of the appointment, cancellations are handled only by phone with a colleague.

Question: Are you open on Saturdays? Answer for voice: On Saturdays we’re open from ten to two. We’re closed on Sundays.

Notice the structure: a short answer, one exception, a follow-up line. That last part keeps the conversation moving instead of letting it stall.

What should you NOT put in the knowledge base?

What you leave out matters as much as what you put in.

• Customers’ personal data inside text documents. Data for a call comes from the contact list and integrations, not from general documents. See also the guide to call recording and GDPR.
• Special category data (for example, diagnoses), unless you have first assessed the legal basis.
• Passwords, keys and system access. They have no place in a document of answers.
• Information that changes daily and that you cannot keep current (exact stock levels, hourly promotional prices). Better to fetch it through an integration or send it as an after-call message.
• Long documents written for reading: full contracts, terms and conditions, brochures. Extract the spoken version in a few sentences.
• Contradictory versions. If two documents say different things, the agent may pick either. Keep only one.
• Promises you cannot keep: guaranteed deadlines, discounts “on request”, exceptions decided on the spot.
• Internal opinions and office gossip. The agent may repeat them.

How do you handle “I don’t know”: escalation

A good agent knows how to say “I don’t know”. Without a clear rule, the risk is that it tries to answer anyway. Write down exactly what it does when:

• it cannot find the answer in its documents;
• the person asks for an exception or a decision that is not the agent’s to make;
• the person is unhappy or explicitly asks for a human;
• the topic is outside the purpose of the call.

The recommended behaviour, in plain words:

1. Acknowledge the limit: “I don’t have that information.”
2. Do not improvise and do not promise.
3. Note the request and, if needed, ask the person for a good time to be called back.
4. Close politely and say what happens next: “A colleague will contact you.”

In AgentVocal, the request appears in the portal with the call summary, and a colleague follows up. Decide in advance who on your team checks these calls and how quickly. An escalation with no owner is worse than no escalation at all.

How do you test and keep it up to date?

Testing has three levels.

1. The test call on your own phone (the last step of the setup wizard). Ask the questions that are in your documents, then the ones that are not.
2. Your own set of trick questions. Write 15 to 20 difficult ones: odd phrasing, two questions in one, an exception, a request outside the scope. Repeat them after every significant change.
3. The first real calls, listened to in full. Use the recordings and transcripts in the portal.

For every wrong answer, do not just fix the line. Look for the cause:

Updating is a routine, not a project. Pick an owner and a rhythm:

• immediately, when a price, opening hours or a policy changes;
• weekly during the first weeks, based on the calls you listened to;
• then monthly, or whenever you add a new scenario.

Keep a simple change log (date, what changed, why). When something goes wrong, you will know what was changed last. Whatever you change in the portal applies from the next call.

What do you do next?

You now have a starting kit: a few dozen question-and-answer pairs, written for voice, with clear “I don’t know” rules. Do not wait for it to be perfect. Launch on a small sample, listen to the calls and improve. To track whether the improvements work, see how to measure an AI voice agent. If you are close to launch, go through the launch checklist.

Want to hear how an agent answers from documents? Browse the ready-made scenarios or listen to a demo.