WFM guideOperations

Contact centre knowledge base design

Q: How do you design a contact centre knowledge base?

A contact centre knowledge base should be designed around three principles: findability (agents find the right article within 20 seconds or they go to hold or to a colleague); accuracy (articles must be up to date or agents distrust the KB and stop using it); and governance (every article has a named owner and a review date, or it decays). Start with taxonomy: structure articles by customer contact reason, not by internal department. An article titled 'Direct Debit cancellation — customer request' is findable by agents; an article titled 'Finance Dept — DD processing guidance' is not. Then design the article template: every article should have a trigger phrase (when to use this article), the action (what to do), the script (what to say), and the policy basis (why this is the answer). Finally, assign ownership: every article has a named owner in the business who is responsible for keeping it current.

Q: What is the impact of a good knowledge base on contact centre performance?

A well-designed and maintained contact centre knowledge base produces three measurable operational improvements: (1) AHT reduction — the primary source of AHT variation in most contact centres is search behaviour (agents on hold searching for information or checking with colleagues). A well-designed KB reduces hold time by 30–60 seconds per contact, translating to 8–15% AHT reduction in operations where hold time is a significant component. (2) FCR improvement — agents with reliable access to accurate information resolve contacts correctly on the first contact. A 5–10pp FCR improvement is achievable through KB quality improvement alone in operations where inaccurate information is a leading cause of repeat contacts. (3) Ramp time reduction — new agents rely on the KB more heavily than experienced agents. A well-organised KB reduces new agent ramp time by 2–4 weeks, reducing the AHT premium that new agents carry and accelerating their time to full productivity.

Most contact centre knowledge bases are designed, built, and then abandoned. They are populated at launch and not maintained. Within 12 months they are inaccurate, distrusted, and unused. Design is only half the problem — governance is the other half.

Knowledge base impact on contact centre performance

AHT reduction

8–15%

Reduced hold time from searching. Agents spend 30–60 seconds on hold per contact searching for information in operations with poor KB quality. A well-organised KB eliminates most of this hold time.

When: Applies where hold time is >30 seconds per contact on average

FCR improvement

5–10pp

Agents with reliable access to accurate information give correct answers on the first contact. FCR failures driven by incorrect agent information are eliminated. Does not address FCR failures driven by agent soft-skill or process issues.

When: Applies where inaccurate information is a leading cause of repeat contacts

Ramp time reduction

2–4 weeks

New agents rely on the KB more heavily than experienced agents. A well-organised KB reduces the penalty of not yet knowing answers by memory — accelerating time to full productivity.

When: Effect is largest in operations with high complexity or many products

Taxonomy: structure by customer contact reason, not by department

The most common structural error in knowledge base design is organising articles by internal department rather than by customer contact reason. An agent handling a customer asking about a cancelled direct debit cannot quickly navigate to a folder called "Finance — Payments Operations". An agent can navigate to "Payments — Direct debit — customer cancellation request" in seconds.

Department-based taxonomy (wrong)

Finance > Payments

Finance > Payments > Direct debit

Finance > Payments > Refunds

Operations > Customer accounts

Operations > Customer accounts > Account changes

Product > Product A

Product > Product A > Features

Product > Product A > Pricing

Problem: agents must know which department owns the topic before they can find the article. Internal structure is invisible to agents.

Contact-reason taxonomy (right)

Billing > Direct debit

Billing > Direct debit > Cancel

Billing > Direct debit > Amend

Billing > Direct debit > Failed payment

Account > Personal details

Account > Personal details > Change address

Cancellations > Cancel product

Cancellations > Cancel product > Retention offer

Right: agents navigate from the customer's contact reason, which they know, to the resolution, not from the internal org structure.

Standard article template

Field	What to include	Why it matters
Trigger phrase	The customer's words that indicate this article applies: 'customer wants to cancel their direct debit / says they didn't authorise a DD / DD has been returned'	Agents search using customer language — the trigger phrase surfaces the right article when the agent types the customer's words into search
Action	Step-by-step procedural instructions: what the agent does in the system, in what order, with what checks. Screenshots or system navigation steps where helpful.	Agents need to know what to DO, not just what the policy says. A policy statement without procedural steps produces inconsistent handling.
Script	The exact words to say to the customer, or a template if the specific language varies: 'I've cancelled your direct debit. You won't be charged after [date]. You'll receive a confirmation by email within 2 hours.'	Consistent scripting reduces AHT variance and improves accuracy. Agents who are unsure what to say generate hold time while they think.
Policy basis	One or two sentences explaining the rule or rationale: 'Direct debits can be cancelled at any time. The customer does not need to provide a reason. The bank must act within 30 days of notification.'	Agents who understand why the policy exists handle edge cases better than agents following rules without understanding.
Exceptions and escalation	When this article does NOT apply and what to do instead: 'If the customer is disputing a DD they say was fraudulent, do not use this article — use the DD dispute article and escalate to the fraud team.'	Exception guidance prevents agents from applying the wrong article to a related but different situation.
Ownership metadata	Named owner, review date, last updated date, version number.	Agents check ownership metadata before trusting an article. An article last updated 18 months ago will not be trusted.

Search vs. browse — and what each requires

Search-first design

Used by experienced agents who know what they're looking for and can formulate a search query quickly. Search is faster when the agent can predict which terms will return the right article.

Requirements

→Search must return relevant results in the first 3–5 hits — agents will not scroll past these
→Article titles must include the customer-facing terms agents will search for
→Synonyms must be configured: 'DD' and 'direct debit' should return the same articles
→No duplicate articles on the same topic — conflicting results destroy agent trust

Failure mode: Search returns generic or too-broad results. Agents cannot predict which search terms will find the article. Agents abandon search and use colleagues or put the customer on hold.

Browse-first design

Used by newer agents who don't know the right search term, and for unfamiliar topics. Browse is more reliable when the taxonomy is structured around customer contact reasons.

Requirements

→Maximum 3 levels of taxonomy depth — deeper structures are too slow to navigate during a live contact
→No more than 8–10 items per category level — agents cannot scan longer lists under time pressure
→Category labels must match the customer's language, not internal terminology
→Popular articles should be surfaced at category level — not buried 3 clicks deep

Failure mode: Taxonomy is too deep or uses internal language. Agents cannot navigate to the right article within 20 seconds. Browse is abandoned; agents rely on memory or colleagues.

Four governance failures that make knowledge bases decay

No named owner per article

Consequence

When a process changes, nobody knows which KB articles need updating. Articles become inaccurate. Agents learn that the KB cannot be trusted and stop using it. AHT increases as agents default to hold-and-ask.

Fix

Every article must have a named individual owner (not a team or department — a named person) who is responsible for keeping it current. Owner is notified automatically when the article reaches its review date.

Review cycle too long or not enforced

Consequence

Articles that haven't been reviewed in 12+ months are likely inaccurate. A knowledge base where 40% of articles are potentially out of date is functionally useless — agents don't know which 40%, so they distrust all of it.

Fix

Set review cycles by article type: high-volatility articles (pricing, regulatory, offers) every 30–60 days; standard procedure articles every 90 days; background reference articles every 6–12 months. Automated reminders to owners. Escalation if overdue.

Article creation without quality control

Consequence

Agents or team leaders create articles to fill local knowledge gaps. Duplicate articles proliferate. Conflicting articles on the same topic confuse agents. Article titles are inconsistent, making search unreliable.

Fix

All new articles require approval from a KB owner or quality gatekeeper before publication. Templates are mandatory — articles not in the standard template are rejected. Duplicate check before article creation.

No usage data tracked

Consequence

Without data on which articles are used, searched for but not found, or opened but immediately closed (a signal the article didn't answer the question), it is impossible to improve the KB. High-use articles in poor state and low-use articles that agents need but can't find are both invisible.

Fix

Track: searches that returned zero results (demand without supply); articles opened but abandoned quickly (supply that doesn't meet demand); most-used articles (prioritise for freshness); articles not accessed in 12 months (candidates for archiving).

Knowledge base questions

How do you design a contact centre knowledge base?

Design around three principles: findability (agents find the right article within 20 seconds), accuracy (articles must be current or agents stop trusting and using the KB), and governance (every article has a named owner and a review date). Taxonomy should be structured by customer contact reason, not by internal department. The standard article template covers: trigger phrase (customer words that signal this article applies), action (step-by-step procedural instructions), script (what to say), policy basis (why), exceptions and escalation, and ownership metadata.

What is the impact of a good knowledge base on contact centre performance?

Three measurable improvements: AHT reduction of 8–15% (from eliminating hold time spent searching); FCR improvement of 5–10pp (agents with accurate information give correct answers on the first contact); and ramp time reduction of 2–4 weeks for new agents. The FCR improvement is the most significant operationally — a 5pp FCR improvement in a 10,000 contact/month operation eliminates approximately 500 repeat contacts, saving the full cost of those contacts.