17 Min
A new agent takes a call about a refund that never arrived. She finds the policy article in under a minute, reads it twice, and still cannot tell whether to reissue the payment or wait. The article is correct. The author wrote it for someone who already knows how the billing system behaves. That gap sits at the center of explicit knowledge: writing something down does not make it usable.
In short, explicit knowledge is know-how that someone has put into words, numbers or diagrams, so a person who never met the author can act on it. This post defines it and shows what it looks like in a contact center. Then it does the part most definitions skip, which is helping a team choose the right container for each piece of knowledge, whether that means an article, an SOP, a decision tree, an FAQ or a recorded walkthrough that someone has to keep current.
Table of contents
- What explicit knowledge is, and where its edges sit
- Explicit knowledge examples across a support operation
- Why explicit knowledge still goes unused
- How to choose a format for explicit knowledge
- Explicit knowledge goes stale, and stale is worse than missing
- When explicit knowledge is the wrong answer
- Frequently asked questions
What explicit knowledge is, and where its edges sit
Wikipedia’s definition describes knowledge that people can readily articulate, codify, store and access. The same entry lists manuals, documents, procedures and how-to videos among its examples. It adds that this kind of knowledge passes between people without loss of integrity once the reader knows the rules for decoding it. For most teams, then, the explicit knowledge meaning comes down to know-how that outlasts its author.
Two boundaries follow from that definition. Raw data does not count: a table of ticket counts becomes knowledge only when someone interprets it, a distinction the guide to data, information and knowledge draws in detail. And it covers only half of what an organization knows.
Explicit versus implicit and tacit knowledge
The other half usually goes by the name tacit knowledge, the judgment an expert holds but cannot fully state. Writers use implicit knowledge in two ways. Some treat it as a plain synonym for tacit knowledge; others mean knowledge that could go into writing and never did. Check which sense a source intends before comparing advice.
The table below sets the two sides against each other on the terms that matter to a support operation.
| Dimension | Explicit knowledge | Implicit or tacit knowledge |
|---|---|---|
| Where it lives | In documents, systems and diagrams | In people’s habits and judgment |
| How it moves | Copy, search, link, translate | Shadowing, coaching, practice |
| How you check it | Read it and compare it with reality | Watch someone do the work |
| How it fails | It goes stale and nobody notices | It leaves when the person does |
For the second column in depth, read the companion post on tacit knowledge.
Explicit knowledge examples across a support operation
Textbooks list encyclopedias, manuals and formulae. A contact center holds the same thing in different clothes. These examples of explicit knowledge are ones a typical operation already owns, whether or not anyone calls them knowledge.
- Policy: the refund rules that say who may approve what.
- Procedure: the ordered steps to reset a locked account.
- Reference: a product specification, a price list, a plan comparison.
- Troubleshooting: what to check when a connection drops, and what each result means.
- Training material: onboarding decks, recorded sessions, quiz banks.
- Approved wording: the exact phrasing for a regulated disclosure.
Each type of explicit knowledge answers a different question. So a policy tells an agent what the company allows. A procedure tells them what to do next, and a reference page tells them what holds true. Content for troubleshooting points to the right branch, whereas training content describes what a person should manage alone by the end of the week. A format that suits one of those questions often fits another badly, so the broader map of types of knowledge helps before the choice of container does.
Why explicit knowledge still goes unused
Having the knowledge on paper is the easy half. A 2023 Gartner survey of 4,861 digital workers found that 47% struggle to find the information they need to do their jobs. The same survey found the average knowledge worker on 11 applications, up from six in 2019. An APQC survey of 982 full-time knowledge workers in 2021 added a number for the cost: 2.8 hours a week spent looking for or requesting information.
None of those findings describes a shortage. Instead, they describe explicit knowledge that exists, in eleven places, in shapes nobody chose on purpose. Most explicit knowledge management problems start with how the knowledge got packaged, long before anyone asks whether it got captured.
Get the Basics of Knowledge Management Explained
How to choose a format for explicit knowledge
The decision comes down to one question for each piece of knowledge. What will the reader be doing at the moment they need it? A reader trying to understand needs prose. A reader following a procedure under time pressure needs numbered steps. And a reader in the middle of a call, choosing between three outcomes, needs a branch. Five formats cover almost every case.
| Format | Best when the reader needs to | Weak at | Review burden |
|---|---|---|---|
| Article | Understand a policy or concept | Fast action mid-call | Medium |
| SOP | Follow a fixed sequence | Cases with many exceptions | Medium |
| Decision tree | Choose between outcomes | Background and reasoning | High at first, then low |
| FAQ | Look up one short answer | Anything with conditions | Low |
| Recorded walkthrough | See a screen or physical step | Search and quick updates | High |
A worked example: one fact in three formats
Take one fact from the opening scene: a refund went out, but the customer cannot see it. The three versions below are a composite of what support teams describe.
An article explains that refunds post in two stages, approval first and settlement second, and that customers see the money only after settlement. So the agent reads the whole page to learn that. An SOP lists steps: confirm the approval status, check the settlement status, read the settlement date, quote it to the customer. A decision tree asks one question at a time. Did the refund get approval? Has it settled? Does the settlement date fall in the past? The last branch ends in “reissue the payment.”
All three versions are accurate. Only the last lets the agent in the opening scene finish the call without a second read.
When an article wins
Write an article when the reader needs a reason: a policy with its rationale, a product concept, an onboarding explainer. Clear knowledge base articles suit the reader who has time and wants context. They cost the least to publish. But they work poorly during a live call, because the reader must dig the action out of the prose while a customer waits for an answer.
When an SOP wins
A standard operating procedure fits work that runs in a fixed order and rarely varies, such as onboarding a customer, closing a case or running a quality check on a sample of recent calls, where the same steps apply every time. Its strength is auditability, since a reviewer can compare what happened with what the steps say. Exceptions are its weakness. Once conditions start appearing in the middle steps, the SOP has turned into a decision tree written in the wrong shape.
Start From a Free SOP Template
When a decision tree wins
An interactive decision tree fits any case where the right action depends on answers the agent collects during the call, and it asks one question per screen, so a new agent never has to hold the whole procedure in memory. The cost comes up front. Someone with real expertise must map every branch, and a tree with a missing branch fails quietly. That trade pays off for a high-volume fault but wastes effort on a rare one.
When a short answer page or a recorded walkthrough wins
An FAQ answers one question with one short answer. It works well for customers helping themselves, but it breaks the moment the answer carries a condition. A recorded walkthrough wins where seeing beats reading, as with an unfamiliar screen; video also takes the most effort to keep current, since a changed menu label means re-recording the whole clip.
Explicit knowledge goes stale, and stale is worse than missing
A missing answer sends an agent to ask a colleague, which at least produces a correct reply. But a stale answer produces a confident wrong one. After the format, then, the second decision is ownership: who answers for each item, and when does someone review it?
Three habits keep written knowledge honest. Give every item a named owner, a person rather than a team. Attach a review date that the system enforces, instead of a calendar the owner must remember. And retire items outright when nothing depends on them, because an archive full of dead pages turns every search into a sorting exercise. Those habits make up the maintenance half of the knowledge management process, and teams budget for it last.
A concession belongs here. Maintenance has a real price, and some organizations do better by writing less. A team of eight with a stable product may serve its customers well on a dozen articles and a shared chat channel. Heavier tooling pays for itself only when the pace of change outruns what an owner can track from memory.
Turn a Written Procedure Into a Guided Flow
Where tooling earns its place
At contact center scale, owners and review dates need software behind them. Knowledge base software that records owners, expiry and usage shows a team which items agents actually open, so review effort goes where the traffic is. Knowmax is built for that case: it keeps articles, SOPs and decision trees in one governed library and surfaces them inside the agent’s workflow. Other platforms do versions of the same job. The test that matters is whether the review loop runs without anyone remembering to start it, because a loop that depends on memory stops the first week a product launch eats the owner’s calendar, and nobody notices until an agent quotes a retired policy.
When explicit knowledge is the wrong answer
Writing things down is a good default and a poor universal rule. Facts, rules and sequences suit it well, but judgment does not. The veteran who senses a call turning toward cancellation has no substitute in an article titled “Handling cancellation risk,” because the sense comes from years of calls and an article can only list the signs. A team that tries produces a page nobody trusts. Nobody should expect otherwise.
So the rule of thumb is to write down whatever a colleague could verify, and to leave to coaching whatever depends on feel. When a decision comes up often and has a clear shape, capture it as a branch. When it is rare, subtle or relational, accept that it stays with the person. Plan for their absence through shadowing and handover instead of another document.
The decision for a support leader is therefore less about volume than about fit. Pick the format that matches what the reader is doing. Give each item an owner. Then stop writing the moment a page starts pretending to hold judgment.
Ready to Put Your Written Knowledge to Work?
Frequently asked questions
A refund policy is a clear example of explicit knowledge. It states who may approve a refund and under what conditions, in words anyone can read. Product manuals, onboarding decks, troubleshooting guides and knowledge base articles belong to the same family: an author wrote each one once, and a stranger can use it.
Writing, recordings and diagrams hold explicit knowledge, so others can use it without meeting the author. Implicit knowledge, often a synonym for tacit knowledge, stays in a person’s experience and judgment, where nobody has written it down. Documents and search carry the explicit kind. Coaching, shadowing and practice carry the implicit kind.
Common types of explicit knowledge include policies, procedures, reference material, troubleshooting steps, training content and approved scripts. Each answers a different question for the reader. A policy covers what the company allows, a procedure covers the next action, and reference material covers what holds true. Content for troubleshooting points to a branch.
Most organizations keep explicit knowledge in a knowledge base, a document repository, a learning system and shared drives. Trouble starts when the same item lives in several of them. A single governed library, with a named owner and a review date for each item, keeps the written version trustworthy.
Word Document)
Excel File)
