How to update SOPs without a quarterly rewrite marathon

Almost every guide to maintaining documentation arrives at the same recommendation: set a review cadence. Quarterly, biannually, annually, pick one and put it in the calendar. It is the most common advice in this category and it is close to useless, for a reason that is easy to state and hard to unsee.

A calendar has no idea whether anything changed. It fires on a date, and documentation goes wrong on an event. Those two things are uncorrelated, so a schedule can only ever be early, late, or lucky.

Why the quarterly review fails

Run the arithmetic on a quarterly review. A process changes in the second week of the quarter. Your review is scheduled for the thirteenth. That is eleven weeks of people following a document that is wrong, which is the exact failure the review exists to prevent.

Now run the other case, which is more common and does more damage. The review arrives and nothing has changed. You open forty documents, confirm they are fine, and close them. Next quarter, the same. By the third round the reviewer has learned something true: this task usually finds nothing.

So they start skimming. They open each document, glance, and mark it reviewed without running the procedure. Skimming is worse than skipping the review entirely, because the freshness date now says verified on a document nobody verified. You have converted an unknown into a false positive, and false positives are what people act on.

The four triggers that should force an update

Replace the date with events. Four of them cover almost everything that makes a procedure go wrong, and each one is observable at the moment it happens rather than up to ninety days later.

One: the tool changed. Klaviyo rebuilds the flow editor, Gorgias renames a view, Shopify moves the refund control behind a different menu. Screenshots die first and the step order dies shortly after. This trigger is the easiest to watch because the vendors announce it themselves.

Two: the policy changed. The refund ceiling moves from $150 to $200. The return window goes from 30 days to 45. This is the most expensive trigger of the four, because nothing on screen looks different. The document still matches the interface perfectly and quietly gives the wrong answer, which means nobody discovers it by reading. They discover it through a customer.

Three: the team changed. Somebody left, somebody joined, or a task moved between two people. Every procedure that names a person for escalation or approval breaks at this moment, and it breaks silently because the sentence still parses.

Four: the same question was asked twice. Nothing here is cheaper to watch, and nothing is more widely ignored. If two different people asked the same thing in Slack this month, the document either does not cover it or does not cover it findably. Twice is the threshold worth acting on: once is a person, twice is a defect in the document.

The fourth trigger is the only one that reports on how the document performs in use rather than on what changed around it. It is also free, requires no integration, and most teams already have the data sitting in a Slack channel nobody mines.

Edit, rewrite, or re-record

A trigger fires. The next decision is what kind of update this is, and getting it wrong in either direction is expensive: people re-record for a one-word change, or they hand-edit a document whose every screenshot is now obsolete.

The last row matters more than it looks. Teams tend to keep editing one document through three generations of a process until it reads like a set of amendments rather than a procedure. When you find yourself preserving structure that no longer serves the work, the honest move is a new document and an archived predecessor, so the history stays readable and the current version stays clean.

Why re-recording beats editing prose

When a tool changes its interface, the instinct is to open the document and fix the wording. Consider what that task actually is. You are reconciling your memory of the new screen against text somebody else wrote from their memory of the old screen. Two layers of recollection, neither of them in front of the thing being described.

Running the procedure with a recorder on removes both layers. You capture the current screens, the current controls, and the current order, because you are doing the work rather than remembering it. Anything that moved shows up whether or not you were looking for it, which is the part hand-editing reliably misses: you fix the three changes you noticed and leave the two you did not.

The cost comparison is less obvious than it sounds. Hand-editing a twelve-step procedure after a redesign means taking twelve fresh screenshots, cropping them, replacing them in order, and rewriting the text around each one. That is twenty minutes of clerical work at best. Re-running a task you were going to run anyway costs the length of the task, and the capture happens as a side effect.

The ten-minute update

The loop itself is short. Most of the failure in documentation maintenance is not the updating, it is the deciding, which the triggers above have already done for you.

1. Run the procedure once, for real, on live work. Not a rehearsal for the purpose of documenting, because a rehearsal is recollection wearing a costume and will quietly skip the workaround you always use.
2. Compare against the documented version. Note what moved, what disappeared, and what is new. If you have drift detection, this is the step it does for you.
3. Fix what moved and leave the rest. Resist rewriting sentences that are still true. Every line you touch is a line somebody has to re-read.
4. Stamp it. A verified date and a name, so the next reader can tell at a glance whether this has been checked since the thing they are worried about changed.
5. Tell only the people it affects, and only when a decision rule changed. A notification for every screenshot swap trains the team to ignore notifications, which costs you the one that mattered.

That last step is the one teams get wrong in the generous direction. Broadcasting every edit feels like transparency and functions as noise. Reserve the announcement for changes that alter what somebody should do, and let everything else be discovered by the freshness date.

When the update reveals the process is wrong

Sometimes you re-record a procedure and discover that current practice is not an improvement. Somebody invented a shortcut that skips a verification step, and it has been working because the thing being verified has not gone wrong yet.

This is not a documentation task and it should not be handled as one. Writing the shortcut into the SOP converts an undiscussed habit into official policy, and it does so silently, in a document most people will never read closely enough to object to. That is how a control disappears from an operation without anyone deciding to remove it.

Stop and have the conversation instead. Sometimes the shortcut is correct and the original step was wasteful, in which case remove the step deliberately and note why. Sometimes the step exists for a reason nobody communicated, in which case the fix is a sentence in the document explaining what it prevents. Both outcomes are fine. Documenting the deviation without deciding is the outcome that is not.

Wiring the triggers so they fire without you

Triggers only help if something surfaces them. Each of the four has a cheap mechanism.

• Tool changes: subscribe to the changelog or release notes of the three to five tools that carry your highest-volume procedures. Tag each SOP with the tool it depends on, so when an announcement lands you can see in seconds which documents are implicated.
• Policy changes: whoever approves the change owns updating the document, the same day. Not the person who wrote the SOP, who has no way of knowing a decision was made in a meeting they were not in.
• Team changes: put SOP reassignment on the offboarding checklist next to laptop return, and do one pass through each document with the departing person while they still remember the answers.
• Repeat questions: make it a standing rule that the second time a question is asked, the answer goes into the document and the asker gets the link. The person answering is already typing the answer, so the marginal cost is small and it is paid by the person best placed to write it.

None of these requires software. The tool-changelog one benefits from tagging, the policy one is a norm, and the repeat-question one is a sentence in a team agreement. What they share is that each fires close to the moment the document went wrong rather than up to a quarter later.

What good looks like after 90 days

Worth setting the expectation honestly, because the goal is not a perfect library and chasing one is how teams end up back at the rewrite marathon.

After a quarter of this you should have somewhere between five and fifteen updates that happened within days of the change instead of within a quarter. Not more. If a hundred procedures changed in three months, you do not have a documentation problem, you have an operation that is still finding its shape, and documenting it aggressively will waste the effort.

The second thing you should have is a visible set of documents nobody has touched at all. That set is the most useful output of the whole exercise. A procedure that has run repeatedly for three months without generating a single trigger is either genuinely stable, which is worth knowing, or nobody is running it, which means it is a deletion candidate rather than a maintenance one.

Shrinking the library is a legitimate result. Most teams carry procedures they no longer perform, and every one of them dilutes the trust in the ones that matter.