Knowledge management for customer service

#Why one knowledge base

In many customer service teams, knowledge exists in several versions: on the intranet, in team leads’ emails, in the website FAQ, in the heads of experienced colleagues. Each version differs a little. So customers get different answers depending on channel and person.

AI makes this problem bigger, not smaller. An AI agent that relies on an outdated page repeats the mistake in every conversation, in a friendly and confident tone. At the same time the solution becomes simpler: one knowledge base that everyone draws from.

This guide describes how to build such a knowledge base: content, structure, writing rules, grounded answers, upkeep and measurement. The glossary gives an overview of knowledge management.

#What belongs in the knowledge base

Not every document is customer service knowledge. A knowledge base holds what is needed to answer and handle requests correctly. Anything else makes it bigger, not better.

What does not belong: personal data of individual customers, confidential internal matters and unapproved drafts. Those have their place in business systems and project folders.

#Structure: articles and attributes

The smallest unit is the article. An article answers one question or describes one procedure. Long collections covering twenty topics are hard for people to read and hard for AI to cite.

Every article carries attributes that make it findable and controllable. They are not bureaucracy; they are what makes the right article appear in the right place at the right time.

Univerx Knowledge

Question

Where is our data processed?

In EU regions of your choice. Hosting in Germany is planned. The sub-processor list and the processing-agreement documents are available on request.

SourceTrust Center · Data protection

Keep the topic structure flat. Two, at most three levels are enough. Deep folder trees usually mirror the organisation chart, not customers’ questions. Attributes and search do more than any nested filing system.

#One truth, several versions

Sometimes the same answer needs different versions: detailed for employees, brief for self-service, spoken for the voice menu. Keep those versions together in one article instead of maintaining three. When the rule changes, everything changes in one place.

#Writing for people and machines

Good knowledge articles follow rules that help people and AI alike. A text an employee can take in within ten seconds during a call is usually also one from which an AI can derive a correct answer.

1. Answer first. The first sentence answers the question. Background comes after.
2. Explicit conditions. “Applies to contracts from 2024” rather than “usually applies”.
3. One question per article. Related questions are linked, not appended.
4. No dead references. Neither customers nor AI understand “see above” or “as discussed”.
5. Tables for rules. Deadlines, amounts and responsibilities go in tables, not running text.
6. The customer’s language. Terms customers use belong in titles and text.

#Tone and voice

Decide how your knowledge base speaks: formal or informal, short sentences, no internal abbreviations in external articles. A short style guide is enough. It makes answers from self-service, AI agents and employees sound like the same organisation.

#Grounded answers

Generative AI can turn articles into answers that fit the specific question. For those answers to be right, they must be tied to your sources. The technical term is grounding: the AI looks up matching articles and phrases its answer on that basis.

A grounded answer names its source. Employees see which article a suggestion comes from and can check it. Customers in self-service see a link to the full article. That keeps it traceable where a statement comes from.

#When no source fits

The most important rule is the least glamorous: where no matching article exists, the AI says so. It does not guess or invent. An AI agent then hands over to a person, and assistance shows no suggestion.

That is how you contain hallucinations: plausible-sounding but wrong answers. They cannot be ruled out completely, which is why sampling and feedback are part of operations. The post Grounded answers goes deeper.

#Knowledge for the phone

On the phone, knowledge is spoken, not read. An answer that works well on screen, with a table and three links, is useless in a voice menu or for a voicebot. Spoken answers need their own version.

That version is short, names three points at most and repeats numbers. Instead of “see the table”, it says what applies to the caller and offers to send details by SMS or email.

It lives in the same article as the written version and is reviewed with it.

#Search that understands

Customers rarely ask in the words the article uses. They write “money back” when the article says “refund”. Semantic search recognises the meaning behind a question and finds matching articles without identical terms.

It still pays to know your customers’ language. Conversation analytics shows the words people use to describe their requests. Those terms belong in titles, introductions and synonym lists. That improves search for people and machines.

For employees in a conversation, the best search is the one they never need. Univerx Assist suggests matching articles while the conversation is under way. The employee decides whether and how to use the suggestion.

#Upkeep: ownership and life cycle

A knowledge base is never finished. Products change, rules are adjusted, incidents come and go. Without clear ownership, every knowledge base goes stale, often faster than you would think.

So every article has an owner from the business and a review date. When the review date passes, the article is checked, updated or withdrawn. The more important the content, the shorter the interval.

1. Draft. Someone from the editorial team or the business writes or changes an article.
2. Subject review. The owner confirms the content.
3. Approval. The article is made visible to its intended consumers.
4. Use and feedback. Employees flag anything unclear directly on the article.
5. Review or withdrawal. On the review date, or when needed, the article is updated or removed.

Incident notices play a special role. They are needed fast and go out of date fast. Always give them an expiry date and a person who withdraws them once the incident is over. Otherwise self-service will still be reporting a long-fixed problem weeks later.

#Feedback from daily work

The best signals of gaps come from the people who work with the knowledge every day. Make feedback as easy as possible: one click on the article, a short comment. And make sure feedback is visibly acted on. Otherwise it stops coming.

#From conversation to article

A lot of knowledge is created in conversations: a new question, a clever explanation, an exception nobody has documented. If that knowledge never reaches the knowledge base, it is lost when the call ends.

So build a short path from conversation to article. Employees can flag a gap straight from the desktop, with the request as context. Conversation analytics shows topics that are growing.

Team leads see where follow-up questions pile up, as the post Team leads see topics, not just numbers describes.

AI can propose first drafts from conversations and existing documents. That saves writing time. Review and approval still stay with people, because a draft based on a single conversation can mistake an exception for a rule.

#Multiple languages

Many customer service teams answer requests in several languages. Keep language versions close to the source article: same structure, same attributes, same review date. When the source article changes, all language versions are flagged for review.

Machine translation speeds up the work. For content with legal effect, a person fluent in the language should review the translation. Terms your organisation uses consistently in a language belong in a glossary that the translation also uses.

#Rights and approval

Not everyone should be able to change every article. A split has proven itself: many may propose, few may approve. For content with legal or financial effect, such as deadlines, goodwill rules or contract terms, a four-eyes principle is advisable.

Approval for AI agents needs particular care. An article that is helpful for employees can be unsuitable for an agent, for example because it assumes discretion. So decide per article whether an agent may rely on it.

#Measuring whether the knowledge holds up

Whether a knowledge base works does not show in its article count. It shows in whether questions get answered. A few metrics make that visible.

The first two figures are the most honest. They show gaps from the point of view of people who looked for an answer and did not find one. Make them the standing work list of the knowledge editors.

Review the figures monthly with knowledge editors, team leads and business owners. A short list of the most important gaps and overdue reviews is agenda enough. What matters is that every review produces concrete tasks with a name and a date.

#Privacy and confidentiality

Knowledge articles usually contain no personal data, and it should stay that way. Examples in articles use made-up names and numbers. Screenshots from business systems are redacted before they are added.

Watch the visibility of internal content too. An article accidentally released to self-service makes internal goodwill limits public. A clear separation of visibility and approval by a second person prevent that. The Trust Center has more on how AI features are framed.

#Common mistakes

Knowledge bases rarely fail because of technology. They fail because of habits that creep in unnoticed. These five patterns show up in many organisations.

• A file store, not a knowledge base. Documents are uploaded but never turned into articles. Search then returns twenty pages where one answer is needed.
• Nobody is responsible. Articles belong to “the team”. In practice, nobody reviews them.
• Parallel sources. The old intranet lives on next to the knowledge base. Employees do not know which version to trust.
• Feedback without response. Notes are collected but never acted on. After a few weeks they stop.
• Everything at once. A big project is meant to complete the whole knowledge base before launch. By the time it is done, part of it is out of date.

What these patterns share is that clear ownership and a fixed rhythm prevent them. Tools help, but they do not replace a decision about who is responsible for what.

#Where to start

Building a knowledge base looks big. In small steps it becomes manageable, and the first results show early. This sequence has proven itself.

1. Analyse contact reasons. Which requests are most frequent? That list is your editorial plan.
2. Review what exists. Collect existing documents, merge duplicates, discard what is outdated.
3. Set an article template. Attributes, structure and style rules, binding for everyone.
4. Write the first topics. The most frequent requests, done properly and with an owner.
5. Start internally. First for employees and assistance, then for self-service and AI agents.
6. Measure and extend. Searches without results and feedback decide the next articles.

#Checklist

#How Univerx Knowledge helps

Univerx Knowledge is one knowledge base for people, bots and self-service, with semantic search and answers grounded in your sources. Univerx Assist suggests the right knowledge to employees during the conversation, and AI agents base generated answers on your knowledge base.

The guide Introducing AI agents responsibly shows how to introduce AI agents on that foundation. If you would like to see how this looks with your own content, request a demo.