Short answer Automate a type of change only when the evidence comes from the product itself, the edit is easy to undo and a mistake would be low-risk; a screenshot refresh on an unchanged flow is the classic case. Keep a person on billing, permissions, security, legal and data-deletion content, and on text your team wrote. Start by reviewing everything, and let a change type apply on its own only after a run of approvals without edits.
Every release creates documentation work, and not all of it is the same kind. Some is mechanical: a new screenshot of an unchanged screen, a label that went from one word to another. Some needs a person who understands the customer, the pricing or the legal weight of a sentence. Trouble starts when both get the same treatment, whether that’s reviewing every screenshot by hand or letting a tool rewrite billing articles unsupervised.
This guide gives you five questions for sorting changes, a starting policy for common change types, and a way to move a type from review to automatic without losing control of it.
How do you decide what to automate?
Decide by type of change, not article by article. Releases produce the same kinds of change again and again, so a policy per type saves more effort than a fresh judgment per edit. For each type, ask five questions.
1. How strong is the evidence?
How do you know the product changed? A change observed in a replay of the current build is strong evidence. One inferred from code is weaker: a merged pull request doesn’t prove the change is deployed, or show what each role sees. A single customer report is a lead, not evidence. Only observed changes are candidates for automatic handling. Our guide on why re-indexing isn’t verification covers what an observed check involves, and our homepage shows the four evidence labels on a sample article.
2. How easy is it to undo?
Swapping a screenshot back or restoring a label takes one step, and little is lost while the mistake is live. Deleting or merging articles, changing URLs or restructuring a section can break inbound links, bookmarks and search results, and is much harder to reverse cleanly.
3. How far does it reach?
This is the blast radius: how many articles and readers one change touches. A wrong edit to a rarely read article affects a few people. The same mistake repeated across dozens of articles, or on the pages most customers read, affects many. Wide reach doesn’t rule out automation, but it means a change type needs a longer track record first.
4. Who gets hurt if it’s wrong?
This is audience risk. A reader who follows a wrong navigation step gets lost and tries again. A reader who follows a wrong instruction about billing, plans, permissions, security, privacy or data deletion might be charged, lose access, expose data or delete something they can’t get back. Content in these areas stays with a person, however routine the edit looks.
5. Who wrote the text?
A sentence someone on your team wrote, such as a tip, a warning or a nuance learned from support conversations, carries knowledge a replay can’t see. Treat it as protected text. If it mentions something that changed, flag it for its author instead of rewriting it.
Put together: a change type is a candidate for automation only when the evidence is observed, the edit is easy to undo, the topic is low-risk and no team-written text is involved. Blast radius then decides how long a track record it needs.
Common change types and how to handle them
Here’s a starting policy for the changes releases produce most often, using three handling levels:
- Automatic once routine Can apply automatically once proven routine. It starts in review; after a run of approvals without edits, it applies on its own, and revert stays available.
- Review, usually quick The edit is small and the evidence is attached, so a person checks one against the other before it publishes.
- Always needs a person The decision needs context the product can’t show: money, access, legal meaning, or what to tell customers.
| Change type | Handling | Why |
|---|---|---|
| Screenshot refresh, same flow A restyled sidebar; steps and labels unchanged | Automatic once routine | Observed in a replay, no text changes, and the previous image can be restored in one step. |
| UI label rename “Invite teammates” becomes “Add members” | Review, usually quick | Mechanical and observed, so a good candidate to promote. Where the old label appears in text your team wrote, that text is flagged, not rewritten. |
| Moved navigation path A setting moves to Settings › Members | Review, usually quick | Confirm the new path for each role that uses it; admins and members may see different menus. |
| New required step Choosing a region is now required before creating a workspace | Review, usually quick | The replay shows the step. A person checks that it applies to every role and plan, and whether readers need to know why. |
| Behavior change New projects are now private by default | Always needs a person | The steps may still work while the outcome differs. What it means for existing customers is a judgment call. |
| Removed feature or deprecation Legacy exports retire at the end of the quarter | Always needs a person | Someone decides whether to delete, redirect or keep the article with the alternative. Deleting breaks links and removes answers people still search for. |
| Plans, pricing and permissions Audit logs move to a higher plan; only owners can export them | Always needs a person | Mistakes cost customers money or access, and the source of truth is often a pricing page or contract, not the interface. |
| Security, privacy and legal Two-factor setup, data retention, closing an account | Always needs a person | The wording carries legal and security meaning. Involve whoever owns the policy. |
| New article from a support gap “How do I export to CSV?” keeps returning no results | Always needs a person | Someone decides whether it deserves an article, where it belongs, and what to do about steps that couldn’t be verified. |
Adjust the policy to your product. A team in a regulated industry may keep label renames in review permanently; a team that ships frequent visual polish may promote screenshot refreshes early. Revisit it as your track record grows.
Start with full review, then earn autonomy
Start with every change in review, even the obvious ones. The first releases show you what the drafts look like, where they go wrong and what your own standards are. They also give you a baseline to measure against.
Then promote change types one at a time. A type is ready to apply on its own when:
- It’s narrowly defined. “Screenshot refresh where the replay passed and no text changed” is a type. “Small changes” is not.
- It has a run of approvals without edits, across more than one release. Set the number before you start, for example ten in a row, so the decision isn’t made on instinct.
- Its evidence is observed, not inferred from a code change.
- Every automatic change stays reversible. Each one keeps its evidence and can be reverted.
Write the policy down
Give each promoted change type a short written policy, so anyone on the team can see what applies on its own, under which conditions, and how to undo it. For example:
- Change type
- Screenshot refresh, same flow
- Applies when
- The replay passed and no text in the article changed
- Excludes
- Billing and security articles
- Promoted after
- Ten approvals in a row without edits, across three releases
- Undo
- Revert restores the previous image
- Back to review if
- Any automatic change is reverted, or the area is redesigned
- Owner
- Documentation lead
Some exclusions survive promotion. High-risk topics and team-written text stay in review whatever the track record. You can also scope autonomy by area: screenshot refreshes might apply on their own everywhere except billing articles.
Autonomy can be taken back, too. If anyone reverts an automatic change, or a product area is redesigned, move that type back to review until it earns trust again. Skim the automatic changes after each release: it takes less time than reviewing them, and tells you whether the policy still holds.
Why batch changes by cause?
One product change rarely touches one article. In the sample review queue on our homepage, renaming “Invite teammates” to “Add members” touches three articles and four screenshots. Reviewed article by article, that’s the same decision made several times, possibly in different ways.
Batching by cause groups every proposed edit under the product change that caused it. You review the cause once: what changed, the evidence, and a representative edit. Approve it, and the decision applies to every affected article and screenshot. Anything that doesn’t fit the pattern gets its own decision; in the sample, a teammate’s tip that mentions the old label is flagged for her instead of rewritten.
Split a batch when a cause crosses a risk boundary. If the same rename appears in a navigation article and a billing article, approve the navigation edits together and send the billing one to whoever owns billing content. The cause is shared; the risk isn’t.
What you gain:
- Fewer decisions. One per cause, not one per edit.
- Consistent wording. The same rename reads the same way in every article.
- A clear trail. Every edit points back to the release or check that caused it.
- Targeted reverts. If a batch turns out to be wrong, you know exactly which edits belong to it.
- Cleaner promotion data. Approvals are counted per kind of cause, which is the unit you promote.
What should you measure?
Record a baseline for a release or two before you automate anything, then track the same measures afterward. Compare against your own baseline, not someone else’s numbers.
| Measure | What it tells you | Watch for |
|---|---|---|
| Accepted corrections | Whether proposed changes are worth a reviewer’s time | Many rejections in one change type: fix the rule before you automate it |
| Approved without edits | Which change types are ready to promote | The same manual fix, made again and again |
| Reviewer minutes per release | Whether the review load is falling | Falling minutes with rising reverts suggests rubber-stamping |
| Automatic changes later reverted | Whether autonomy was earned | Any revert: move that type back to review |
| Unverified steps | How much of the help center was actually checked in the product | A sudden rise can mean the test account lost access or the environment changed |
| Answers that still escalate | Whether customers now get what they need | Retrieval, instructions and escalation rules also shape answers, so measure separately |
Two cautions. First, don’t make the share of automatic changes the goal; a higher share means little if reverts rise with it. Second, don’t read escalations as a verdict on the documentation alone. Better sources help an AI support agent answer correctly, but retrieval, its instructions and its escalation rules matter too. To see the effect of a round of fixes, ask the same agent a fixed set of real customer questions before and after, and compare the answers.
Where HelpCenter.AI fits
HelpCenter.AI is built around this way of working. It replays the flows your articles describe in your app with a test account, links GitHub release changes to the articles and screenshots they affect, and proposes block-level edits and re-rendered screenshots with the evidence attached. Reader and support signals, such as searches that return nothing, help decide what to check first.
Each proposal carries a confidence phrase rather than a percentage: routine, worth a look or needs judgment. Proposals are batched by cause, so one approval covers every article a change touched. Text your team wrote is protected: flagged, never silently rewritten. Everything starts in review; once a kind of update has proven routine, you can let it apply on its own, and you can revert anything.
Approved updates publish to HelpCenter.io, and you can export Markdown and llms.txt. HelpCenter.AI is in early access with assisted onboarding, and the usual first step is an audit of your existing help center. See how HelpCenter.AI checks, proposes and publishes updates, or our comparison with AI support agents and docs platforms.