Knowledge Management Life Cycle: Follow One Article From First Answer to Retirement

An article called “Refund exceptions” sits at the top of the search results on a billing queue. Nobody has touched it for a long time, it states a window that billing no longer enforces, and agents still open it first. Nobody is careless here, but nothing in the process stops the decay. The article has no stage that notices it has aged.

That gap is what the knowledge management life cycle exists to close. The cycle traces a piece of knowledge from the moment someone works out an answer to the moment a newer answer replaces it. So a team that manages only the middle of that path ends up with a library that grows while trust in it falls.

This post follows one composite article, the refund exception above, through six stages. At each, it shows what the textbook version leaves out, what breaks in a real queue and who should own the repair.

What the knowledge management life cycle covers, and why the stage count changes

Published versions of the knowledge management life cycle disagree on how many stages exist. The Knowledge Flow framework from APQC, updated in August 2023, describes a seven-step cycle of creating, identifying, collecting, reviewing, sharing, accessing and using knowledge, while vendor explainers compress the same movement into as few as four stages and others stretch it to eight, depending on where the author decides one step ends and the next begins. Five-stage versions dominate search results, and the so-called 5 stages of knowledge management usually run create, capture, organize, share and apply.

The disagreement is mostly about where to cut the line. So the stage count says little about what actually happens. However many stages a model draws, it follows one object through the same events: someone produces it, writes it down, files it somewhere findable, hands it on and uses it.

One well-known model is not a life cycle at all. The SECI model, which Wikipedia’s knowledge management entry credits to Ikujiro Nonaka and traces to Nonaka and Takeuchi’s 1995 book, describes a spiral between tacit and explicit knowledge through socialization, externalization, combination and internalization. It explains how knowledge changes form. A knowledge life cycle explains what happens to one piece of knowledge over time. The two answer different questions, so they can sit side by side.

This post uses six stages: create, capture, organize, share, apply, and review and retire. The sixth is a deliberate addition. A later section explains why.

One refund exception, followed from first answer to the sixth stage

The test case is a rule that every billing queue has some version of. A customer’s card fails on a second attempt, the order has already shipped, and an agent has to decide whether to refund, re-bill or escalate, all while the customer waits. The answer lives in one senior agent’s head and in a policy memo nobody reads.

The case is a composite of what support teams describe, not a single customer. It is deliberately boring, because most of what a contact center knows is as plain as this.

Stage 1, create: the answer appears before anyone calls it knowledge

A senior agent works out that a failed second attempt should trigger a re-bill link, not a refund. She does it on a live call, under pressure, and it works. Right now the knowledge exists, and nobody else has it.

What breaks: nothing visible. Creation happens daily, in every queue, but almost nobody labels it. The team lead owns this stage, because only the lead can notice that a call went differently from the script.

Stage 2, capture: externalizing the answer costs the most

Capture turns tacit knowledge into explicit knowledge, the externalization step in SECI terms. It is also where the work most often stalls. The expert holds the answer, a queue to work and no time to write anything up.

A common failure is capture by request. A manager asks for an article, the expert drafts it from memory a week later, and the draft leaves out the part that mattered: the condition under which the rule does not apply. Instead, a two-field form (what happened, what worked) filled in at the moment of the call gives a content owner something real to turn into a draft. Ownership sits with a knowledge author, not the expert, because the expert’s job is the queue. For the unwritten end of this problem, see the post on tacit knowledge.

Organize and review decide whether the article is ever found

A drafted article is not yet usable. It needs a place, a title that matches how an agent searches, and a check on its accuracy. In practice, most queues manage the first and skip the second.

Stage 3, organize: the title is a search query

The article lands in the billing folder under the name “Payment policy v3 final”. An agent mid-call searches for “card failed refund” and gets nothing. The article exists, but for that agent it might as well not.

Findability is the quiet failure of this stage, and the research on it is blunt. A 2023 Gartner survey of 4,861 digital workers found that 47% struggle to find the information needed to do their jobs, and that the average knowledge worker now uses 11 applications, up from six in 2019. An APQC survey of 982 full-time knowledge workers in 2021 put the cost at 2.8 hours a week spent looking for or requesting information.

Those numbers cover a whole workforce, so they probably overstate what one queue sees. Still, they remain the best primary evidence that title and structure choices carry a price. Whoever runs search quality owns this stage, not whoever wrote the article.

The review gate: the check that most teams skip

APQC places review ahead of sharing, and for good reason. A second person checks the article for accuracy before it reaches agents. For the refund exception, someone asks billing whether the window in the draft still matches the window the system enforces. This post keeps that gate inside stage three and runs it again as stage six.

What breaks is the owner. Someone names a reviewer once, at launch, and the reviewer later leaves the team or moves to another topic, so nobody checks anything. The fix is a named subject matter expert per article cluster plus a date, which makes a departed reviewer show up as an empty field instead of a silent assumption.

Share and apply: an article that is read is not yet an article that is used

After review, the article goes live and the cycle appears to be over. Most explainers stop at this point, but the real test starts here. In contact center knowledge management, the customer is waiting on the line while the agent reads.

Stages 4 and 5, share and apply: access is one step, use is another

APQC lists access and use as two separate steps, and the split is useful. Knowledge sharing puts the article in front of an agent through search, a pushed suggestion or a knowledge sharing platform. Knowledge application means the agent acts on it correctly, mid-call, with that customer waiting.

An article can pass the first and fail the second. A long policy page opens, the agent skims it, misses the condition in paragraph five and re-bills a customer who deserved a refund. Access worked and application failed, yet the page view looks identical in both cases. Same click, opposite outcome.

For that reason, call centers need more than a wiki. The signal that matters is outcomes, not opens: did the agent use the article, and did the contact resolve? Anyone who tracks knowledge management KPIs per article can see which pages get opened often and still precede a repeat contact.

Why a five-stage knowledge management life cycle is really a line

Many five-stage lists end at apply. A knowledge management life cycle that ends at use is a line with a loop drawn on it, because nothing in it sends knowledge back to the start when conditions change.

The opinion here is plain. The stage that decides the health of a library is the one after application, where someone rechecks, revises or retires the article. Teams that count only what they add tend to discover, on audit, that old material outweighs new material and that agents have learned which pages to distrust. Once that happens, even accurate articles lose readers.

Retirement is the uncomfortable part, so this post names it as a stage. An article that nobody opens, or that now contradicts the system of record, should leave the search index. Deleting it is rarely required. Instead, hiding it from search and keeping an archive copy is usually enough, and it makes the knowledge life cycle reversible if the old policy ever returns, which happens more often than anyone plans for.

The table is a design, not a measurement. It shows what each stage needs, and a team can adopt it without buying anything.

The redesign: every stage gets an owner and a trigger

The refund article would have survived with two changes: each stage needs a named owner, and the last stage needs a trigger that does not depend on anyone remembering, which is the piece most teams never build. In short, a working knowledge management life cycle runs on fields and events. Goodwill does not scale.

Three triggers cover most queues. A policy or product change in the source system sends a recheck to the article’s subject matter expert. A repeat contact tied to an article flags it for review. And a review date, set at publication, expires the article’s trusted status when it passes without a recheck. None of these needs a large program, only a field for the owner and one for the date.

Tooling matters, but only at the margins. Good knowledge management software supports the owner field, the expiry date and the link between a usage signal and a review task. That is why the choice of platform comes after the design, not before it. Knowmax offers these functions in its knowledge platform for contact centers, and it is one option among the vendors a buyer should compare.

What the full cycle costs, and when a lighter one is enough

Six stages with six owners is more process than a small team needs. For example, take a group of a dozen agents on one product, with one subject expert who also writes the articles. That group can run capture, review and retire as one weekly habit, and giving each stage its own owner would only add meetings that nobody wants and nobody would miss. Simpler wins.

The cost also falls unevenly. Capture and review take expert time, but expert time is what a busy queue lacks. A practical rollout starts with the handful of articles agents open most, runs the full cycle on those, and leaves the long tail on a date-only rule. Still, that is a choice about where to spend scarce review hours. Make it openly.

There is a second limit. A knowledge life cycle manages articles, and articles hold only the explicit part of what a team knows. The judgment an agent uses to read a caller never enters the capture stage at all. For that layer, see the notes on explicit knowledge and what falls outside it.

A third limit deserves a mention before any team commits to six stages. The knowledge management life cycle assumes the source of truth is stable enough to review against. In a product that ships weekly, review becomes a standing task rather than an event. The sensible aim then shifts from keeping every article current to keeping the heavily used ones current and labeling the rest by age. Which of the two a team can afford depends on its release pace and its review capacity, so no cycle diagram settles it.

Frequently asked questions