Cx Knowledge Lifecycle

Knowledge lifecycle governance

Most knowledge bases rot through calendar review nobody completes, not through neglect. An article gets a yearly "review due" date, the reminder fires, someone clicks through unchanged, and the system records it as current. Meanwhile the product changed six months ago and the article customers actually read — because search surfaces it — is wrong.

The prize is not a tidy review log. It is articles that stay correct under the load they carry, with a clear owner when they drift, and a deprecation path that does not 404 customers mid-journey.

The failure modes

Assign ownership before cadence

Every published article needs one accountable owner — a role or team, not a person's name alone. The owner is responsible for factual currency when the underlying policy, product or process changes, not for prose polish.

Orphan detection: articles whose owner role no longer exists, whose owner field is blank, or whose owner has not logged in since the article was last materially edited. Orphans are the highest-risk stale content — nobody receives the alert when the topic changes.

Review triggered by usage and staleness, not calendar alone

Calendar review is a backstop, not the engine. Prioritise review when both are true:

1. Staleness signal — updated_at older than the last known change on that topic, or older than a topic-specific threshold (refund policy: 90 days; a feature overview: tied to release cadence).
2. Usage signal — views, search impressions, agent citations, AI grounding frequency, or contact-after-view rate above baseline.

A stale article nobody reads is housekeeping. A stale article customers and agents hit constantly is an incident waiting to happen — treat it like one.

Suggested priority tiers:

Low-traffic content does not need the same cadence as head articles. Equal calendar review for every article is how teams burn out and miss the ones that matter.

What "review" means

A review is not opening the page. It is:

1. Verify every factual claim against current policy, product behaviour and links.
2. Check findability — do titles and headings use the words customers search?
3. Check duplication — does another article answer the same question differently?
4. Record what changed — updated_at must move only when content or metadata materially changed, not when someone clicked approve.

If nothing changed, say so explicitly in the review log. That is valid — but distinguish "verified unchanged" from "nobody looked."

Deprecation without 404ing customers

Never delete a published article customers may bookmark, that search indexes, or that external sites link to. Deprecation is a controlled wind-down:

1. Mark status — deprecated, superseded, or archived (use your platform's equivalent; do not leave it looking live).
2. Choose canonical successor — one article, not three overlapping replacements.
3. Redirect or prominent banner — old URL resolves to the successor, or shows "This article is outdated — see [link]" above the fold.
4. Update internal references — macros, AI grounding lists, agent shortcuts, onboarding docs. Deprecation that only changes the help centre leaves agents citing the old page.
5. Retain for audit — keep the old body accessible to staff even if hidden from customers.
6. Measure after 30–60 days — contact rate on the topic, search failures for old terms, broken-link reports.

Hard deletion is only for drafts, duplicates never published, or content that was factually harmful and has no legitimate reason to exist.

Governance rhythm

Tie KB updates to change management, not documentation sprints. When policy changes, the article owner is in the same Slack thread as the announcement — not discovering it from a customer ticket three weeks later.

Traps

• Review completion rate as a KPI. Teams game it; wrong articles get marked reviewed.
• Equal ownership of the whole KB. "Support owns the KB" means nobody owns anything.
• Deprecating without checking AI and macro references. The article vanishes from the help centre but still grounds answers.
• Assuming low views means safe to delete. Unused in conversation matching is not the same as unused in reality — check views and agent citations first.
• Publishing a replacement before redirecting the old URL. You now have two live answers and split traffic.

Present results to the user

1. Orphan and unowned article list, with usage tier attached.
2. Priority review queue — usage × staleness ranked, not alphabetical.
3. Proposed ownership map — role per article or section, with gaps named.
4. Review policy — tier definitions, triggers, and what "done" means.
5. Deprecation candidates — with successor, redirect plan and reference check list (macros, AI, internal wiki).
6. Governance calendar — what runs weekly, monthly, quarterly; tied to change management not documentation theatre.