Quarterly KB review

The cheapest way to keep a help center accurate is a steady review cadence. Not perfect, not comprehensive — just steady. This recipe describes the loop the Atender team uses internally and recommends to tenants: once a quarter, walk the oldest articles, decide what to keep, what to update, and what to retire. An hour or two per quarter beats a six-month overhaul.

The problem this solves

Articles age. The feature they describe changes. The screenshot they reference gets redesigned. The phrasing your customers use shifts. Without a review pass, articles describing yesterday’s UI sit unchanged on the public site, AI agents retrieve them, and customers get the wrong answer.

The fix isn’t a quarterly project — it’s a checklist. The review is fast when you do it; expensive when you let it slip.

What you need

• A user role that can edit Knowledge Base articles.
• An hour blocked on your calendar (more if your KB is large).
• Optionally: a colleague who owns the feature each article describes, so you can ping them on uncertain calls.

The loop

1. Pick the oldest articles

Sort articles by lastReviewedAt ascending, or by article creation date if a review timestamp isn’t tracked yet for your tenant. The 10–20 oldest articles are your review batch.

A larger KB needs more articles per pass — 100-article KBs walk 20 per quarter; 1,000-article KBs walk 50–100. The goal is to cycle every article in roughly a year.

2. For each article, decide

Open the article. Read it as if you were a new customer hitting the page for the first time. One of three outcomes:

• Still accurate — Mark reviewed. The article keeps its content; only the review timestamp bumps.
• Needs an update — Set status to needs-review, write a short note in the body or summary about what’s wrong, and assign or message whoever should rewrite it.
• Retire — The feature is gone or replaced. Set status to archived.

The mark-reviewed step uses the dedicated endpoint at POST /api/v1/kb/articles/:id/mark-reviewed. It only updates the timestamp — it doesn’t round-trip the article body, so concurrent edits are safe. The in-app editor doesn’t yet expose this as a button; for now, mark-reviewed runs via the API, or you can edit the article and save it (which counts as a re-publish).

3. Walk the rest

Repeat for each article in the batch. Twenty articles takes about 30 minutes at a steady reading pace. Most articles fall in the “still accurate” bucket — the review is mostly confirming, occasionally flagging.

4. Hand off the needs-review pile

The articles you flagged as needs-review are invisible to customers and to AI retrieval immediately. They sit in the editor’s filter view for the person who’ll rewrite them. Either:

• You rewrite them yourself, set back to published, and the cycle closes.
• The feature owner does the rewrite. Ping them with the list — five articles to update by next week — and check back the following review.

The needs-review status is a temporary state, not a parking lot. Articles that sit there for two quarters are signal: either they’re not actually broken (set back to published) or the feature is gone (set to archived).

What to look for in each article

A 60-second checklist per article:

• Does the screenshot match what’s on screen today? If the UI has been redesigned, the screenshot is stale.
• Are the menu paths and button labels accurate? “Settings → Knowledge Base” might be “Settings → Knowledge” now.
• Does the article describe a feature that still exists? Features sometimes get rolled into other features or removed entirely.
• Does the language match how customers actually talk about this? Watch for jargon that drifted out of customer vocabulary.
• Are external links still live? Linked docs sometimes move or get deleted.

If three or more of those are off, the article needs a real rewrite, not a tweak.

Tooling to make this easier

The recipe gets easier with a small dashboard. The pattern Atender’s roadmap describes:

• A SuperAdmin view that lists articles by lastReviewedAt, oldest first.
• Counters for “articles with 0 views in the last 90 days” — likely candidates for archive.
• A “mark reviewed” button that calls the dedicated API endpoint.

Until that ships, the manual flow above works. The cheapest version of the dashboard today: a CSV exported from /api/v1/kb/articles, sorted by lastReviewedAt, opened in a spreadsheet.

Why quarterly

Three months is short enough that the world hasn’t changed too much, and long enough that the review doesn’t feel like noise. Monthly reviews tend to find nothing changed and get skipped. Annual reviews surface so many issues that they get postponed indefinitely.

The cadence to actually run is the one that survives. Pick a recurring calendar slot, attach the link to your KB admin view, and run it.

What changes after the loop

Right after a review pass:

• The needs-review filter has a fresh pile of articles waiting for rewrites.
• Customers are seeing fewer stale articles, because retired content has moved to archived.
• The review timestamps cluster around “today” — which means the next quarter, the same articles will fall to the bottom of the sort and won’t show up until they age again.

Over time the oldest-articles list becomes a moving frontier. Every quarter trims the leading edge; over a year, every article in the KB has been touched at least once.