Examples of Knowledge: What an Audit Counts and What It Misses

A support operation finishes a knowledge audit and finds that every article has an owner and a review date. Agents still turn to the next desk to ask what to do when a customer’s card fails twice. The audit was accurate, but it counted only what someone had written down.

Examples of knowledge are easy to list and hard to sort, because the standard labels overlap. Knowing a refund window, knowing how to reset a router and sensing which customer will accept an apology are three different things, but a knowledge base holds only the first two on a good day, and then only if someone keeps them current.

This post sets out six kinds of knowledge, each with an everyday case and a contact center case. It then crosses two of the axes in a grid so the missing cases show up, describes how each kind fails, and ends with a one-hour audit a team can run on its own queue.

Why counting articles misses most examples of knowledge

The obvious explanation for agents who keep asking colleagues is a weak search tool or careless readers. Both happen. Still, neither explains an audit where the articles exist, are current, and go unused for certain questions anyway.

A better explanation starts with what the audit counts. An article inventory counts written, factual material: steps and policies someone prepared in advance. It has no column for what an agent recognizes in the first ten seconds of a call, or for what an agent knows about one customer’s history. Those are examples of knowledge too, and they set how long the call runs.

Even the written layer is hard to use. A 2023 Gartner survey of 4,861 digital workers found that 47% struggle to find the information they need to do their jobs. An APQC survey of 982 knowledge workers in 2021 put the cost at 2.8 hours a week spent looking for or requesting information.

Those figures cover written knowledge only. They say nothing about the unwritten kinds, which no search box can return. The first job is therefore a vocabulary. What is knowledge, in a form an operation can sort?

Six examples of knowledge, defined and placed on a support floor

Wikipedia’s knowledge entry gives the working split. Knowing that something is the case is propositional knowledge, which the entry also calls knowledge-that. Practical ability is knowing how. Direct contact with a person, place or thing produces knowledge by acquaintance, a concept the entry credits to Bertrand Russell. A second split, between explicit and tacit knowledge, cuts across the first. The entry also names situated knowledge, which makes six.

The table lays all six side by side. Apart from the situated one, which is an illustration, the everyday examples come from that entry, while the contact center cases are composites of what support teams describe.

Examples of explicit knowledge and examples of tacit knowledge

These two labels describe how easily knowledge travels. An SOP, a pricing table and a recorded training session are examples of explicit knowledge, since a stranger can pick any of them up and act. The caller-reading in the table, and the feel for when a script is about to land badly, are examples of tacit knowledge, because the person who has them could not fully write them down.

Examples of procedural knowledge and declarative knowledge

Philosopher Gilbert Ryle brought the knowing how and knowing that distinction to prominence in The Concept of Mind (1949), according to Wikipedia’s procedural knowledge entry. Facts a sentence can state are examples of declarative knowledge: the warranty length, the plan limits, the cut-off time for same-day shipping. Abilities are examples of procedural knowledge, such as triaging a ticket, de-escalating a call or reading a log file.

The same entry reports that the two can be acquired separately. It cites 1980 research by Neal Cohen and Larry Squire in which amnesic patients learned motor skills they could not recall learning. In other words, an agent can know a fact without knowing how to apply it, and the reverse happens just as often.

Two axes cross, and the grid shows where the missing knowledge sits

Explicit versus tacit is one axis. The other runs from knowing that through knowing how to knowing a particular customer. Crossing them gives a grid, and the grid is the useful object, because it shows which cells a written library can ever fill.

An article inventory fills only the middle column. Wikipedia’s procedural entry calls procedural knowledge often tacit, so the right-hand column leans toward the lower rows. Situated knowledge sits mostly there too, since it comes from trial and error and usually lacks explicit structure, in the entry’s words.

Each cell holds examples of knowledge in customer service, and each fails differently. The next section takes them in turn. For the same ground at system level, the catalog of types of knowledge in a knowledge management program is a useful companion.

Each kind of knowledge fails in its own way

Sorting is only worth doing if the kinds need different fixes. In fact, they do.

Written facts go stale. A policy changes in the source system and nobody edits the copy, so the agent who follows the article gives a wrong answer with full confidence. The cure is an owner and a review date. An article audit already checks both, so this kind rarely surprises anyone.

For example, a twelve-step SOP read mid-call is a poor interface. Agents who cannot find step nine ask a colleague instead, and the procedure goes unused even though it is current. Branching procedures suit a guided format that shows one question at a time, while fixed sequences can stay as plain steps.

Judgment that nobody recorded leaves with its holder. The tacit knowledge in the grid goes when a veteran resigns, and the queue notices only after the spike.

The post on institutional knowledge sets out a 90-day plan for exactly that risk.

Familiarity with one customer resets on reassignment. Whoever takes over an account starts from the CRM notes, and the notes hold a fraction of what the last owner knew. Situated knowledge has a shorter life still, because the workaround that held last quarter may be this quarter’s bug.

An operation should audit failure modes rather than article counts. That is the position taken here. A team with five hundred current articles and no plan for the right-hand column has measured the cheap half of its knowledge. The other half keeps costing it in handoffs, repeat questions and slow ramp-up.

A one-hour audit that finds the examples of knowledge nobody counted

The audit uses the grid as a tally sheet and a sample of real cases as the evidence. It needs a team lead, a spreadsheet and the notes agents already write. Nothing else.

1. Pull a sample. Take 20 recent cases where an agent asked a colleague, escalated, or put the customer on hold, spread across at least three weeks.
2. Write the question in the agent’s words. Not “billing issue” but “Does the late fee come off if the card was declined twice in one cycle?”
3. Tag each question twice. First by kind: knowing that, knowing how or knowing this customer. Then by state: written and found, written but not found, or not written.
4. Count the cells. The heaviest cell is the finding, and it decides where the next month of effort goes.
5. Route each cell to its fix. Items that exist but cannot be found go to the search backlog, and unwritten facts go to an author. Procedures with branches belong in an interactive decision tree, one question per screen. Judgment goes to coaching on recorded calls.

A worked row shows the method. The question “Does the late fee come off if the card was declined twice?” is knowing that, and it is unwritten because the policy covers one decline only. So the fix is a single added paragraph with an owner. Meanwhile “How do I move a customer to annual billing mid-cycle?” is knowing how. A 30-page manual buries that answer. A shorter article that search can find fixes it.

How to tell the audit changed anything

So run the same sample a month later. Three signals matter, and none of them needs a new dashboard.

The first is the repeat-question tally. A fact that agents asked about five times should draw far fewer questions once it is written, so the heaviest cell should move. The second is the share of cases tagged “not written”, which should fall as authors close gaps. Third comes the time a new hire needs to handle a call type without asking anyone, which captures the right-hand column better than quality scores do.

A flat result is still information. In short, if the tally does not move, the written items probably do not reach the agent at the moment of need, and the problem has shifted from content to delivery.

When sorting knowledge by kind is not worth the effort

However, the taxonomy is a tool, not a result. A team of eight on a stable product may serve customers well on a dozen articles, a shared chat channel and weekly call reviews, so a grid adds paperwork there without adding answers.

Writers also contest the labels. Some writers treat implicit knowledge as a separate kind, others use it as another word for tacit, and vendor guides draw the lines in different places. Pick one definition per team and apply it consistently.

Tooling earns its place past a few dozen agents, when owners, review dates and usage data need software behind them. Knowledge base software that records those facts shows which written items agents open and which sit unread.

Knowmax serves this case in contact centers. It keeps articles, SOPs and decision trees in one governed library and surfaces them inside the agent’s workflow. That covers the written cells and the externalized fragments of judgment. Coaching still carries the part that depends on feel, and other platforms do versions of the same job. The test is whether the review loop runs without anyone remembering to start it. The approach to contact center knowledge management applies whichever tool a team picks.

Frequently asked questions