SOP Maintenance: Keeping Agency Documentation Current

I already wrote the guide to building an agency procedure library: four constraints that make a document usable, and the five processes worth documenting first. If you are not sure your agency needs one yet, that question is answered separately in what actually signals you need SOPs. If you would rather someone else build and run the maintenance system below for you, that is covered under SOP consulting.

This piece assumes you already have documents that were correct on the day you wrote them. It answers a narrower question: what happens to a correct procedure a month later, once the work underneath it has moved and the page has not. Who owns each procedure, and what happens when someone ignores one anyway, is a real question and a separate one from what is covered here. This is about the document itself: why it goes stale, what should trigger a fix, how you track what changed, and how you retire one honestly.

Why do procedures go stale in the first place?

A procedure does not go stale because someone stops caring. It goes stale because the work it describes keeps changing while the document stays a snapshot, not a mirror. Three things move independently of the page: the tool a step lives in gets updated, a client asks for something the procedure never anticipated and someone improvises on the spot, or a team member finds a faster route and quietly starts using it instead. None of that feels like an event worth logging. It feels like Tuesday. The gap widens one small deviation at a time until the next person reads the document exactly as written and produces a result nobody currently gets that way.

A calendar review catches this eventually, but eventually is doing a lot of work in that sentence. A quarterly review looking at a document that has been wrong for eleven weeks has already cost eleven weeks of someone either following bad instructions or, more often, quietly ignoring the document and asking a colleague instead. The second outcome is the expensive one, because it teaches people the library is decorative.

What should trigger a review, instead of a date on the calendar?

Four events do more work than any recurring calendar task, because each is the moment the drift actually happened, not a fixed point weeks or months later when someone finally opens the document again.

• The tool changes. Whenever a platform a procedure is built around ships a UI change, renames a field, or removes a button the procedure names, review that document the same week, not at the next scheduled pass. Any step that names a specific click path is fragile by construction, so treat a tool update as an automatic trigger rather than something someone might get to.
• A client complains about something the procedure was supposed to prevent. Read the complaint as diagnostic data before treating it as a relationship problem to smooth over. Something in the process let this through, and the document needs a fresh read this week, complaint in hand, not filed under apologize and move on.
• A new hire hesitates. Every new hire following a procedure for the first time is a free, unbiased test nobody else can run, because they are the only person with no memory of how the task actually gets done. If they stop and ask a question the document should have answered, that is not a training gap. That is the document failing its one job. Log where they hesitated and fix the line.
• You redesign the process on purpose. This is the trigger agencies miss most, not because it is subtle but because the redesign decision usually gets made out loud, in a meeting or a chat thread, and updating the document afterward is assumed rather than assigned. Treat the redesign and the document edit as one decision, not a decision followed by paperwork someone will get to.

Any one of these should move a procedure to the top of the queue faster than its scheduled review date ever will. The calendar review still has a job: it catches slow drift nobody reported, the kind that creeps sideways over months without a single sharp moment to notice. Keep it. Just do not mistake it for the mechanism that catches most of what actually breaks a procedure.

How do you version a procedure without a full version-control system?

You do not need Git for a five-step onboarding checklist, but you need more than a single date at the top saying when the document was last touched. A date tells a reader the page was edited. It does not tell them what changed, or whether the change matters to the step they are about to do. Three habits cover the gap without any new software.

• One location, no copies. The moment a procedure exists in two places, the tool it lives in and a pinned message someone made for convenience, you have two documents that will drift apart independently and nobody will notice which one lost. Delete the copy the day you find it.
• A one-line change note, not just a date. Under the date, one sentence: what changed and why. Updated step four, client now approves creative in the shared drive instead of by email. A reader deciding whether to trust the document can read that in three seconds. A bare date tells them nothing except that somebody touched the page at some point.
• Superseded, not silently overwritten. If the platform keeps version history, rely on it. If it does not, keep the last two or three change notes stacked at the bottom of the document as a short running log. Nobody should be able to open a procedure and find zero trace that it used to say something different. That trace is what tells a reader the document is actively maintained, not untouched since launch.

None of this is heavy. Lightweight versioning is not a paper trail for its own sake. It gives the next reader enough to decide, in the time it takes to read one line, whether they are looking at the current version of the truth or an old one nobody cleaned up.

How do you retire a procedure honestly?

Every agency accumulates procedures for work it no longer does. A service gets discontinued, a tool gets replaced, two overlapping checklists get merged into one. What happens to the old document at that point decides more than most agencies realize.

The dishonest version is the common one. The document just sits there, unedited, because nobody wants to formally close out something already dead. It stays searchable and linked, and eventually someone new finds it, follows it, and produces work for a process that no longer exists. The person who hits that mistake stops trusting the next document they open too, because they now know the library contains documents that lie.

Retiring honestly costs almost nothing. Mark the document retired, with a date, and one line saying why: replaced, merged, or the work simply does not happen anymore. If replaced or merged, point to where the current version lives. If the work genuinely stopped, say so plainly rather than leaving the reader to guess. Then move it out of wherever people actually search when trying to get a task done, so it does not surface next to documents that are still true. Do not leave a retired procedure sitting in the same list as active ones with no visible difference between them.

What is the smallest maintenance rhythm that actually holds?

Everything above is event-based, which solves the biggest problem with a purely calendar-based review: most drift is triggered by something, not by time passing on its own. But an event-based system only works if someone can tell whether the triggers actually fired and got acted on, and that needs one more habit sitting underneath the other four.

Keep a short running log, separate from the procedures themselves, of trigger events as they happen: a tool changed on this date, a client raised this complaint on this date, a new hire hesitated at this step on this date, a process got redesigned on this date. Each line gets one more field: was the procedure updated, yes or no, and if not yet, by when. Once a month, or every two weeks if the agency moves fast, the only maintenance task is reading that log and closing the open lines. That is a five-minute task, not a review meeting, because the actual reading already happened when the trigger fired.

Anything lighter than a logged trigger and a scheduled check on whether it was closed relies on someone simply remembering, and memory is the exact failure mode that put the agency in this position to begin with.

So what does an untrusted procedure actually cost?

A stale procedure does not fail quietly and stay contained to the one task it describes. The first time someone follows a document exactly and gets a wrong or embarrassing result, they rarely conclude that one document happened to be out of date. They conclude the library cannot be trusted, and go back to asking a colleague or improvising, the exact behavior the library existed to replace. A procedure nobody trusts is worse than no procedure at all: you spent the hours writing it and ended up with a worse outcome than if you had never started, a team that has learned to skip the one place the answer was supposed to live.

My basis for the system above is twelve years running delivery operations inside marketing agencies and 92 completed engagements. Ask any consultant selling you a maintenance system for the same before you take their word over an article like this one.

Where to start

A fresh read tends to catch which of your current procedures would survive the four triggers above, the ones you are too close to see are already wrong. That is part of what the Agency Ops Audit checks alongside the rest of your delivery operations: $1,500 fixed, two weeks, a written 90-day roadmap and a 60-minute readout call. If the honest answer is that the whole library needs rebuilding rather than maintaining, a retainer starts at $3,000 a month, and rebuild work is quoted at a fixed price per workflow. Either way, the version that works is the one where the habit outlives the person who set it up.