An article can have a recent edit date and still tell customers to use a button that moved. The useful question isn't “when did someone edit it?” It's “when did someone last confirm that the steps work for the customers who see it?”
Build one review queue
Start with ten Zendesk articles that show up in saved replies or answer repeat questions. For each, record the article URL, owner, audience, and the exact task a reviewer should try. Give billing, access, and other high-consequence topics an explicit review interval. A rarely used but risky article can deserve attention sooner than a popular overview.
If your setup includes Zendesk article verification rules, start with a small set of articles and review intervals. Use Needs verification as the queue. If you don't have those controls, the same process works in a shared spreadsheet with a review date. A reminder gets the article in front of an owner; it doesn't verify the content.
Review the article against a real task
| Trigger | What to check | Done when |
|---|---|---|
| Three chats mention a missing button | Try the documented steps with the affected role and plan. | The article states who sees the button and what to do if they don't. |
| A release renames a setting | Find the old name in the article, translations, and macros. | The canonical article uses the correct labels and links still work. |
| A policy is due for verification | Ask the policy owner whether any dates, exceptions, or audiences changed. | The published rule matches the current policy, or the owner has confirmed it is unchanged. |
Keep tickets and private evidence in Zendesk. Put a short, sanitized description in the review queue. Publish the fix, open the article as a customer, then verify it in Zendesk using the appropriate publishing permissions. If an article is redundant, pick the replacement and update the links before retiring it.
Keep the queue small enough to finish
Reserve a weekly review slot and start with the three articles doing the most harm. Track overdue high-risk articles and same-topic repeat contacts, not just the number of articles marked verified. Add release-driven reviews as soon as the rollout is scheduled rather than waiting for the next reminder.
Use the release checklist when something changes, or prepare your Zendesk knowledge for chatbot answers if the article also powers messaging. If you're considering a new public site but want to keep the queue, see the Zendesk migration guide.
If no existing article answers the repeat question, create a Zendesk article request rather than marking the review done.