Publish and retire: designing the life of an article

Every knowledge article has a birthday. Very few have a plan for what happens after it.

Most organisations put real thought into how an article gets published. Who writes it, who reviews it, who approves it. Then the article goes live and the thinking stops. Two years later it is still there, still being found by search, still describing a process that changed last spring.

That is not a writing problem. It is a design problem. Nobody designed the second half of the article's life.

Publishing: keep the gate, lose the queue

A review step before publishing is worth having. It catches errors, checks the article makes sense to someone who did not write it, and keeps the knowledge base from becoming a dumping ground.

But the review step is also where good knowledge goes to wait. If every article needs the same three approvals, a quick fix written by an engineer at the end of a shift can sit for a fortnight. By then the moment has passed, and so has the engineer's enthusiasm for writing the next one.

A few questions help keep the gate without building a queue:

• Does every article need the same review, or could a minor update go straight through with a lighter check?
• Who reviews, and do they have time set aside to do it?
• What happens if a review is not done in a set number of days?

Retiring: plan the ending at the start

Retirement is the step most knowledge processes forget. An article that is out of date is not neutral. It is actively misleading, and it is more misleading now that search tools and AI assistants surface articles with confidence.

The simplest fix is to decide the ending when you decide the beginning. Every article goes live with an owner and a review date. When the date arrives, the owner makes a choice: keep it, update it, or retire it.

Retiring should be easy and visible. Move the article out of search, keep a record of it, and make it simple to bring back if someone needs it. People are far more willing to retire knowledge when retiring does not feel like deleting.

Signals that an article is reaching the end

• Nobody has viewed it in months.
• Users keep marking it "not helpful".
• It mentions a system, team or process that no longer exists.
• Its owner has left the organisation.

Any one of these is a reason to look. Two or more is usually a reason to act.

Three questions to take to your next team meeting

• How long does it take an article to go from written to live?
• Does every article have an owner and a review date?
• When did we last retire an article on purpose?

A knowledge base is not a library that only grows. It is a living thing, and living things need a beginning and an end that someone has thought about.

Next step

Share how your team handles publishing and retiring articles in the Knowledge and self-service conversation on ESM's Exchange: https://exchange.esm.institute

Tags: knowledge management, service management, ESM