Implicit Knowledge: Meaning, Examples and How Support Teams Write It Down

Updated October 2026

Implicit knowledge is know-how a person could put into words but has not yet written down, such as the rule a senior agent follows before opening a billing dispute. It shows in how people work. No document holds it, yet the right question can usually draw it out.

That last clause separates it from tacit knowledge. And the distinction has a cost attached: a support team that files every unwritten rule under “tacit” will conclude that nobody can document those rules, then spend months coaching what one well-run interview could have captured.

This post gives the implicit knowledge definition, sets it beside the other two types of knowledge, works through three examples from a contact center, and then examines a capture project that went wrong because it confused the categories, which is a common way for a well-funded program to end up with nothing new in its knowledge base.

What implicit knowledge means, and the two-question test behind it

The cleanest version of the idea comes from Fred Nickols, in his yearbook paper for the Knowledge Management Yearbook 2000-2001. His test uses two questions. First, could anyone put the knowledge into words? A no makes it tacit. When the answer is yes, ask whether anyone has actually done so. Done means explicit; not yet means implicit.

So the implicit knowledge meaning is narrow and practical. Nickols adds that people infer it from how someone performs, and that a task analyst or knowledge engineer can often tease it out of a competent performer.

Not every source agrees. The Wikipedia entry on tacit knowledge opens by treating tacit and implicit knowledge as one thing, knowledge that is difficult to extract or articulate, and the word implicit comes up again only in the title of a 1993 book on implicit learning listed under further reading. Several vendor explainers follow that usage. A few others define implicit knowledge as the application of explicit knowledge instead, which is a third meaning again. Since both main readings appear in search results, a team should pick one and write it into its own glossary.

This post takes the Nickols reading. It gives a support team something to act on. “Hard to articulate” describes a feeling, whereas “sayable but unsaid” describes a backlog.

Implicit vs explicit knowledge vs tacit knowledge, side by side

The three types of knowledge differ on where they sit, how they move between people and what it takes to capture them. The table follows the order of the two questions.

So implicit vs explicit knowledge is a difference of state. The content stays the same; one rule moves from the middle column to the left the moment someone writes it down and puts it where others can find it. For a fuller look at the written column, see the post on explicit knowledge.

The implicit vs tacit split is a difference of kind, which is harder to see from outside. Both are invisible in the knowledge base, both live in experienced people, and both make a new hire slower than a veteran. But a document fixes only one of them.

Three implicit knowledge examples from a contact center floor

The examples of implicit knowledge that matter most in support are rarely dramatic. They are small, repeated decisions that experienced agents make without thinking, and nobody ever asked them to explain. What follows are composites of what support teams describe, not cases from one company. For a wider set across every type, see these knowledge examples.

The check before a billing dispute

A customer calls about a charge that looks wrong. The official process says to open a dispute. Before doing that, a senior agent checks whether the customer changed plans mid-cycle. A prorated charge explains many of these calls and makes the dispute unnecessary. Ask her why, and she can explain it in two sentences. Nobody ever asked.

The escalation route that actually works

The written route for a failed number transfer sends the case to a general provisioning queue. Experienced agents know better. One specific team resolves these, and the general queue forwards them there anyway, a day later. This is implicit knowledge in the workplace at its plainest: a fact about how the organization really runs, held by the people who learned it the slow way.

The order of systems for a delivery complaint

For a late order, a veteran agent opens the courier portal first, then the order system, and the CRM notes last. The courier status settles most calls before anything else needs reading, so the order saves time. Yet it exists only as a habit. A new hire opens the CRM first, because it is already on screen.

All three pass the two-question test. An agent could state each one in a sentence or two and would recognize it when read back. None is tacit. Still, a team that has not drawn the line would likely call them that.

A capture project that filed implicit knowledge under tacit

The failure pattern below is a composite, and it is common enough to trace step by step.

What was attempted

A support operation notices that new agents take far longer than veterans on the same contact types. Leadership concludes that veterans hold know-how the knowledge base never received. So it launches a tacit knowledge program: shadowing for new hires, a handful of recorded calls for coaching, and a mentoring rota.

Why it was reasonable

Every part of that plan suits tacit knowledge. Shadowing and practice are how a skill such as reading a caller’s tone passes from one person to another, and Michael Polanyi’s line that “we can know more than we can tell,” from his 1966 book The Tacit Dimension, is the usual reason given for skipping the document. The research on lost time also backs the urgency. A 2023 Gartner survey of 4,861 digital workers found that 47% struggle to find the information they need to do their jobs. In 2021, an APQC survey of 982 knowledge workers put the cost at 2.8 hours a week spent looking for or requesting information.

Where it went wrong

Months later, the gap between new and experienced agents has narrowed only a little. The knowledge base looks the same as before. Still unwritten: the billing check, the escalation route and the system order from the examples above. Each one now lives in a few more heads, because shadowing spread it one pair at a time, but it still leaves with whoever holds it.

A category error on the first day caused this. By calling everything unwritten “tacit,” the program accepted that nobody could write any of it down, so nobody tried. The implicit layer got the slowest available treatment, one apprentice at a time, while the faster one sat unused.

Nickols makes the same point about Ikujiro Nonaka’s famous example. In Nonaka’s HBR article, first published in 1991, a developer learns a baker’s kneading technique and turns it into a bread machine specification. His argument is that whatever she wrote down “might have been implicit knowledge at one point but was never truly tacit,” because nobody can articulate truly tacit knowledge at all.

How to capture implicit knowledge, starting from outcomes

The second attempt starts from the outcomes of the work rather than the expert’s memory. Asking a veteran “what do you know that nobody has written down?” rarely works, because people cannot list rules they no longer notice using. A better route comes from an analysis of insurance underwriters in the same paper. None of them said at the outset that every application ended in one of three ways: approve, deny or counter offer. Once the analyst named those outcomes, the criteria behind each one came out quickly.

The same method works in a support queue, shown here on a billing complaint:

1. List every way the contact can end. “Refund”, “credit to next bill”, “explain and close”, “open a dispute”, “escalate to billing ops”. Expect the expert to add one the team leader forgot.
2. Ask for the deciding question behind each outcome. “When do you explain and close?” draws “when the charge matches a plan change in the last cycle”, the billing check from earlier.
3. Put the questions in the expert’s order. Plan change, then duplicate charge, then service date. New hires most often get this order wrong.
4. Draft a decision path and test it on a real call. Wherever a new agent hesitates, a question is missing.
5. Record an owner and a review date. The expert who supplied the rules checks the draft.

Articulation, the step that turns implicit into explicit knowledge

Steps two and three are what Nickols calls articulation: implicit and explicit knowledge meeting on the page. Step four is where the work proves itself. A rule that reads well but fails on a live call is still half in someone’s head.

Most sessions like this produce a short branching flow, not a page of prose. An interactive decision tree suits it, because the agent answers one question at a time and never has to read the whole thing mid-call.

What capture costs, and the implicit knowledge to leave unwritten

The method takes expert time, and expert time is the scarcest thing in a busy queue. One outcome session per contact type adds up fast across a large catalog. A practical rollout starts with the contact types where new and experienced agents differ most, and it leaves the rest alone until those run cleanly. A few contact types done well beat a whole catalog done thinly. Start there, measure the gap again, and only then widen the scope.

There is also a real case for leaving some implicit knowledge unwritten. A workaround that exists only because a system fails belongs with whoever fixes the system. Written into an article, it makes the failure permanent. An escalation shortcut may work only because few people use it; publish it to three hundred agents and the receiving team drowns. In both cases the right move is to surface the knowledge, then decide openly whether it belongs in the call center knowledge base at all.

And some of what teams call implicit is really tacit after all. Tacit and implicit knowledge blur at the edge. A rule that the expert cannot state even after a good interview has answered the first question for itself. Treat it as tacit and move on. Shadowing and practice are the right tools for that part. The post on tacit knowledge covers how support teams handle it.

Where a knowledge platform fits once the rules are written

Tooling matters less than the method, and it should come after it. Three features decide whether the written paths stay accurate. An owner field makes a departed expert show up as a gap. A review date expires an article’s trusted status when nobody rechecks it in time. That matters most for billing and policy content, which changes without warning. And usage data ties each path to the contacts that followed it, so the owner hears about any path that keeps preceding repeat calls.

Knowmax offers these functions in a knowledge platform built for contact centers. It is one of several vendors worth comparing, and a buyer should test each against the same three features. The choice of platform should still follow the capture work, never lead it. A team that buys first tends to migrate its old articles and leave the implicit layer exactly where it was. Capture first, then buy.

The opinion behind this post is simple. In most support teams, the biggest store of unwritten know-how is implicit rather than tacit. It stays unwritten mainly because nobody asked the right question. That question is cheap. For the wider picture, the comparison of tacit versus explicit knowledge shows how each type moves. The practical next step is smaller: pick the contact type where new hires struggle most, and interview its best agent about outcomes this week.

Frequently asked questions