Guide · Updated
How to keep your help center up to date
A help center stays up to date when updating it is part of shipping, not a project you get to later. For a small SaaS team that ships every week, that means a short routine on every release, a clear owner, a review cadence for the articles that matter most, and automation for the parts a person shouldn't have to remember.
Why do help centers go out of date?
Help centers go out of date because every release creates docs work and nothing assigns it. The engineer who shipped the change knows what moved; the person who maintains the docs finds out from a confused customer weeks later. Multiply that by a weekly release schedule and the help center falls behind permanently. That slow gap has a name, What is documentation drift?, and it's the default outcome unless you design against it.
The second reason is quieter: the product grows, customers ask new questions, and nobody writes the articles for them. A help center can be accurate and still incomplete.
What does an up to date help center actually mean?
An up to date help center passes three tests, and most teams only think about the first one.
| Test | Question | How you check |
|---|---|---|
| Accurate | Does every article match the product today? | Compare with recent releases and the code |
| Complete | Does it answer what customers actually ask? | Read tickets, failed searches, assistant misses |
| Findable | Can customers reach the answer in their own words? | Search for questions the way customers phrase them |
A help center that's accurate but incomplete still generates tickets. One that's complete but uses your internal vocabulary still fails the customer who searches for “late fee” when the article says “overdue automation”.
What should happen to the docs on every release?
On every release, list the changes a customer would notice, find the article each one affects, and update or write it before or right after the release goes out. It takes ten minutes when the release is fresh and an hour of detective work a month later.
| Change in the release | Docs action |
|---|---|
| New feature | New article, or a section in an existing one |
| Renamed setting or label | Edit every article that mentions the old name |
| Moved button or page | Update steps and screenshots |
| Changed limit or default | Update the number everywhere it appears, including billing articles |
| Removed feature | Remove or redirect the article, explain the alternative |
| Bug fix that changes behavior | Update the article if it described the old behavior |
| Internal refactor | Nothing |
Publish release notes in the same pass. A changelog entry that links the updated article closes the loop for customers who noticed the change.
Who should own the help center on a small team?
One person should own the help center, even if they don't write every word. On a team of five, that's usually the founder or whoever answers support. Ownership means deciding what gets written, approving changes, and noticing when something drifts.
Everyone else contributes in a narrow, cheap way: engineers mark customer facing changes in their pull requests (see A pull request checklist for docs), and whoever answers tickets flags questions the docs couldn't answer. The owner turns those signals into edits. Without one owner, docs become everyone's job, which means no one's.
How often should you review help articles?
Review on a cadence matched to how fast each kind of article changes, not all at once. A full audit every quarter is too slow for a weekly release cycle and too much work to keep doing.
| When | What to review | Time it takes |
|---|---|---|
| Every release | Articles the release touched | 10 to 30 minutes |
| Weekly | Unanswered questions, failed searches, “not helpful” votes | 20 minutes |
| Monthly | The 20 most viewed articles | About an hour |
| Quarterly | Everything else: merge duplicates, archive the obsolete | Half a day |
The weekly review finds what's missing; the release review keeps what exists accurate. Together they cover both halves of the job.
What should you update first?
Update the articles where being wrong costs the most: high traffic, high stakes, or both. A small error in your most viewed setup guide does more damage than a large error in an article three people read.
- Getting started and setup articles, because every new customer reads them.
- Billing, plans, and limits, because customers make money decisions from them.
- The articles your assistant cites most, because they shape most answers.
- Articles touched by the last release.
- Everything else, by traffic.
If your help center shows views per article and your assistant shows citations per article, those two lists are your priority order.
How do you keep screenshots and videos current?
Use fewer of them, and make the text carry the instructions. Screenshots and videos are the first thing to go stale and the most expensive to redo, so put them where they add the most: complex screens and visual concepts, not every click.
- Write steps in text first; add a screenshot only when the screen is genuinely confusing.
- Crop tightly to the relevant area, so unrelated UI changes don't date it.
- Avoid screenshots of fast changing areas like navigation and dashboards.
- Keep videos short and focused on one task, so one UI change doesn't invalidate a ten minute tour.
- When a release changes a screen, search your help center for articles that show it.
What can you automate, and what should stay human?
Automate the noticing and the first draft; keep the judgment human. Software is good at reading every merged pull request, matching changes to articles, spotting questions the docs couldn't answer, and drafting the edit. People are better at deciding what to say, in what tone, and whether a change is worth documenting at all.
| Automate | Keep human |
|---|---|
| Detecting which articles a code change affects | Approving every change before it's public |
| Drafting the edit with the change as evidence | Deciding what not to document |
| Collecting unanswered questions into ranked gaps | Tone, examples, and product decisions |
| Drafting the missing articles | Answering edge cases and exceptions |
| Keeping translations in step | Final review of anything legal or billing related |
How does usedocs keep a help center up to date?
usedocs runs the routine above for you. Connect GitHub and every merged pull request or release is screened; when it changes something an article describes, usedocs proposes the edit with the change attached. A scheduled check reads every live article against the code. Questions the assistant couldn't answer, “not helpful” votes, and imported tickets become ranked gaps with drafted articles.
Everything waits in one review queue, nothing goes live without approval, and Doc health shows which articles match the code. It's one plan, $99/mo, with a 7 day free trial, no credit card.
FAQ
How often should a SaaS help center be updated?
On every release for the articles the release touched, weekly for new questions, and monthly for the most viewed articles.
Who should maintain the help center on a small team?
One owner, usually the founder or whoever answers support, with engineers flagging customer facing changes in their pull requests.
Should we hire a technical writer?
Not before you have a routine. A writer helps once there's more to write than the owner can handle, but the release routine and ownership have to exist first.
How do I know my help center is out of date?
Tickets that quote an article, “not helpful” votes after a release, and searches for new feature names that return nothing are the clearest signs.
Can a help center update itself?
Partly. Tools can detect changes and draft edits and missing articles; a person should still approve each change before it goes live.
Use usedocs for this
usedocs proposes edits when merged pull requests change what customers read, drafts the articles customers ask for, and keeps both in one review queue.