What does a knowledge taxonomy actually do?
A knowledge taxonomy is the shared set of categories that your conversations and your articles are both filed against. It is easy to think of it as a filing system for the knowledge base alone. In practice it does three jobs at once:
- Reporting. Volume, cost, sentiment and gaps can only be reported by topic if the topics mean something. A report is never sharper than the categories behind it.
- Finding. Agents browse by category when search lets them down. An article filed under the wrong heading is close to invisible.
- Gap detection. Comparing what customers asked with what your articles cover only works when both sides use the same categories.
When the taxonomy describes demand poorly, all three degrade together. The symptoms are familiar: a large "Other" or "General enquiry" bucket, categories nobody uses, reports that lump unrelated questions together, and articles parked in sections agents never open.
Why do taxonomies designed in a workshop drift from reality?
Most taxonomies start in a meeting room. Someone sketches the organisation chart, the product list or the IVR menu, and the categories follow. The result is a reasonable map of how the business sees itself. Customers don't contact you in those terms. They get in touch because a payment didn't go through, a parcel shows as delivered and isn't there, or a letter uses a word they don't understand. Those reasons cut across products and teams.
Three habits make the mismatch worse over time:
- Categories named after teams. "Retail operations" means something to the people in it and nothing to a customer or a new agent.
- Categories that copy the product list. "Change my address" touches every product. Filed under each one, it becomes five small topics that never look important.
- No upkeep. Products launch, policies change and services retire, and nobody owns the structure. The knowledge base keeps growing while the taxonomy stays frozen at the day it was designed.
What are customer intents, and why build from them?
An intent is a single thing a customer wanted from a contact, written in plain language. "Find out why the direct debit failed" is an intent. "Billing" is a category. One conversation often holds several intents: a customer rings about a failed payment, then asks to update their card, then asks when the next bill is due.
Intents are the right raw material for a taxonomy for three reasons. They record demand directly, in the customer's own terms. They are fine-grained, so they can be grouped and regrouped without going back to the recordings. And they can be counted, so every proposed category arrives with evidence of how big it is.
Taxonomies built from intents tend to look different from designed ones. There are fewer categories that mirror departments and more that follow a customer's situation, such as "Payments that failed" or "Moving house".
Could someone on the floor tell which category a contact belongs to from the customer's first two sentences? If the answer depends on knowing which team handles it, the category is named for the organisation, not the customer.
How do you build a taxonomy from conversations, step by step?
- Gather a representative window. A month or more of conversations across voice, chat, email and tickets, so billing cycles and weekly patterns are included.
- Extract the intents. Record each one in plain language, including the secondary questions raised during the same contact.
- Group intents into candidate topics. Put together intents that need the same answer, even when customers use different words for them.
- Arrange the topics into two levels. Top-level groups with subcategories beneath them. Five to ten groups suits most operations.
- Measure coverage. Map every intent and article back to the draft. Count how many land in each category, and list the orphans that fit nowhere. Orphans are edge cases, new topics or a category you haven't created yet.
- Review with evidence. Read sample conversations for each category. Merge the thin ones, split the overloaded ones, and rename anything that sounds like a department.
- Apply and re-file. Classify articles and incoming conversations against the new structure, and record the date so trends across the change are read carefully.
Steps two to five are the expensive part by hand, which is why most taxonomies are designed rather than derived. They are also the steps that make the result trustworthy, because every category has a count and real examples behind it. The same intents feed a knowledge gap analysis, so the work pays twice.
What if you have articles but no conversations yet?
This is common. A team may be migrating its knowledge base before its contact centre integration goes live, or run a knowledge-only operation with no interaction data at all. Articles can still seed a taxonomy, because their titles, purposes and content group into topics in much the same way intents do.
Treat an article-derived taxonomy as provisional. It inherits the blind spots of the knowledge base: a topic nobody wrote about gets no category. It also tends to mirror whoever did the writing, so heavily documented areas look more important than they are. Once conversations start flowing, compare the two views. Categories with many articles and little demand are over-documented. Categories with demand and no articles are gaps. Orphaned intents point to categories the articles never suggested.
How deep and how wide should a knowledge taxonomy be?
Two levels is enough for almost every operation. A third level slows agents down when they browse, and it splits volume so thinly that most categories become too small to report on. A handful of principles keeps the shape useful:
- Distinct enough to agree on. Two people reading the same contact should file it in the same place.
- Named in the customer's language. "Card declined" beats "Payment processing exceptions".
- Each category earns its place. It either carries enough volume to report on, or there is a specific reason, such as a regulated product, to track it separately.
- "Other" is a measure, not a destination. Some contacts won't fit. Watch the share that lands there, and treat growth as a sign the taxonomy is falling behind.
If two teams handle genuinely different work, such as a claims team and an internal IT service desk, give each its own taxonomy instead of forcing one structure to fit both.
How do you know whether a taxonomy is healthy?
Check it on a schedule and after any big change, such as a product launch, merger or restructure. Four measures cover most of what goes wrong:
| Measure | What to look at | A poor result usually means |
|---|---|---|
| Coverage | Share of intents and articles that map cleanly to a category | Missing categories, or names that don't match how customers ask |
| Balance | Whether a few categories swallow most of the volume while others sit empty | Categories that need splitting, merging or retiring |
| Freshness | Whether categories still receive demand and their articles are still reviewed | Structure frozen around last year's products and policies |
| Catch-all share | The trend in "Other" and other unmapped contacts | New topics arriving that the structure can't place |
A rising unmapped share is often the first visible sign of new demand. Our guide to emerging topics and drift covers how to catch those shifts while they are still small.
How do you repair a taxonomy without starting again?
A full rebuild is rarely necessary. Run the conversation analysis again on recent data and compare the proposed structure with the live one. Each difference suggests one of five moves:
- Keep categories that match closely.
- Split a category whose conversations fall into two clearly different groups.
- Merge categories that customers treat as the same thing.
- Add a category where orphans cluster around a theme.
- Retire a category with no demand for a quarter, keeping its history so old reports still make sense.
Make changes in small batches and log each one. If your knowledge base lives on another platform, push the changes there too, so both systems describe topics the same way; adding gap detection to your knowledge base covers how categories are mapped between the two.
How does Knowledge Quest build and maintain a taxonomy?
Knowledge Quest builds the taxonomy with Taxonomy Genesis. It reads the intents extracted from your interactions, plus your articles where they exist, and proposes a two-level structure. Each category comes with a confidence score, counts of the intents and articles behind it, and sample interactions. A coverage report shows how much was mapped and flags the orphans. Nothing is applied automatically: your team reviews the draft, adjusts it and can export it as a PDF for sign-off. Genesis can work from around 100 interactions or 30 articles, and when a knowledge area has no interactions yet it builds the first draft from articles alone.
After that, Taxonomy Health scores coverage, balance and freshness with recommendations, and categories sync with supported knowledge bases, with each change reviewed row by row. Finding knowledge gaps in Zoho Desk shows why it matters which category field you read. You keep your knowledge base. Its structure starts to reflect what customers actually ask.
Frequently asked questions
Should we start from an industry template or from our own data?
Use a template only to get moving on day one, before data exists. Once you have a few weeks of conversations, build from them. A template reflects how a typical organisation in your industry is structured, which is the same problem a workshop taxonomy has. Your own demand is the better guide.
How many conversations do you need to build a taxonomy?
Enough to cover a normal cycle of demand, so a month across every channel is a sensible minimum. A few hundred conversations will show the main groups. Lower-volume topics need more data before they look like a category instead of noise.
Will changing the taxonomy break our historical reporting?
It changes what the categories mean, so record the date of every structural change and read trends across that date with care. Re-classifying recent conversations against the new structure gives you a comparable baseline from the change onwards.
What is the difference between a taxonomy and tags?
A taxonomy is a controlled, structured set of categories: each conversation and article has a home in it, so volumes add up. Tags and keywords are free-form labels that can overlap. Both are useful. Report on the taxonomy and use tags to help people find things.
Who should own the taxonomy?
One named person in the knowledge team, with input from operations and quality. Without an owner, categories get added and never retired, and the catch-all bucket grows until reporting stops being useful.