Building an SOP library that survives staff turnover

The test an SOP library actually has to pass

Almost every firm I meet already has a folder called something like “Processes” or “SOPs.” Ask to see it and there is usually something in there — a few Word documents, a slide deck from an old training day, a wiki page nobody has opened since it was written. Ask the harder question and the folder stops being reassuring: if the person who wrote each document left tomorrow, could someone who has never done that job pick it up and produce a client-ready result, unaided? Almost never, and it is worth being honest about why.

Most of what firms call an SOP is a note written by the person doing the job, for the person doing the job. It skips the steps that feel obvious to them, because everything feels obvious once you have done it four hundred times. It assumes context a stranger does not have — which screen, which field, which folder, which of three similarly-named clients. It reads as a reminder, not an instruction. That is a perfectly useful document. It is just not the document that survives a resignation, and confusing the two is how a firm ends up believing it is covered when it is not.

The library that actually survives turnover is built to one test, applied to every document in it: hand it to someone who has never done this job, give them no verbal help, and see whether the output is something you would be comfortable a client received. Everything below is really just how to pass that test on purpose, rather than finding out you failed it during a notice period.

What to document, and what to leave alone

The instinct once a firm decides to take this seriously is to document everything, which is how SOP projects die. Twenty processes that are genuinely written down and kept current beat two hundred that were drafted in one enthusiastic month and never touched again. The question that sorts one from the other is not “is this important” — almost everything in a firm feels important — it is two narrower questions asked together: how often does this run, and how many people can currently run it without help.

That top row is the whole exercise. A process that runs every month and lives in one person’s head is the one that turns a resignation into a crisis, because the gap shows up immediately and repeatedly, not once in a while. Month-end management accounts for the retained client book, payroll for the awkward clients, the VAT reconciliation nobody else touches, the year-end file review one manager always does — these are usually a shorter list than owners expect, often fifteen to twenty-five processes even in a firm of thirty or forty people, because most day-to-day compliance work already has more than one pair of hands on it. Finding that list is most of the exercise described in how to build SOPs in an accountancy practice; this piece picks up from there and is about making the ones you choose actually hold when someone leaves.

The format that survives someone else picking it up cold

Format is where most SOPs quietly fail, because a document can look thorough and still be useless to a stranger. A page of paragraphs describing how the VAT return process “generally works” reads well and transfers almost nothing — the reader has to reconstruct the sequence, guess at the order, and infer what happens when something is unusual. A numbered checklist forces the writer to decide the sequence, which is exactly the discipline a narrative lets them avoid.

An SOP that will actually survive a handover has five things in it, in this order, every time:

• What triggers it. Not “how to do the VAT return” but “on the 3rd of every month, for these clients.” A process with no stated trigger relies on someone remembering it exists.
• Numbered steps, not prose. Each step is one action: which system, which exact field or menu, what you type or click. If a step says “check the figures look right,” that is not a step, it is the writer’s judgement left out of the document by accident.
• What “done” looks like. The specific, checkable output — a filed return with a reference number, an emailed report, a status changed in the practice-management system — so a manager can tell whether the process actually ran without asking.
• What to do when it is not standard. Every process has a handful of recurring exceptions the person who wrote it knows by heart and a stranger does not. List the three or four that come up most, and who to ask about anything else.
• Where things live. The exact folder, template name or system screen, not “in the usual place.” This single point causes more stalled handovers than any other, because “the usual place” was never written down anywhere except in the leaver’s memory.

None of this needs to be long. A well-built SOP for a recurring compliance process is usually one to two pages. If it runs longer than that, the process itself is probably too big for one document and should be split at its natural stages.

One owner, and the trigger that actually forces an update

A document with no name attached to it goes stale within a year, because everyone assumes someone else is keeping it current. Every SOP needs exactly one named owner, printed on the document itself, who is responsible for it being right — not for doing the work personally, but for the document matching reality.

The harder problem is the review trigger, and most firms get this wrong in the same way: they schedule a calendar review, quarterly or annual, and it is the first thing to slip when the firm gets busy, which is most of the time. A calendar review asks “has anything changed?” when nobody has a reason to think hard about the answer. The trigger that actually works is event-based rather than date-based: the SOP must be reviewed and re-confirmed the moment the software changes, the moment the process itself changes, or the moment the person who owns it hands in their notice. That last one is the point of this whole piece. A resignation should trigger a mandatory review of every SOP that person owns, completed before their last day, not after it — because after it, the only person who can confirm the document is accurate is no longer in the building.

Ownership also has to move on the same day the person leaves, not drift for a few weeks while nobody quite decides. Naming the successor owner in the same conversation as the leaving date keeps the document from becoming an orphan, which is the state most stale SOPs are actually in — not wrong on purpose, just nobody’s job any more.

A worked example: what one resignation costs, with and without a tested library

The figures below are illustrative — an invented fourteen-person firm, not a client of ours — costed at £150 an hour for owner or manager time, consistent with the other worked examples on this site. A semi-senior who has run the monthly management accounts process for eighteen retained clients, entirely from memory, resigns with four weeks’ notice.

£6,700 on a single departure, and this is one process out of the fifteen to twenty-five a firm this size typically depends on. None of that saving comes from the leaver behaving any differently. It comes entirely from whether the document existed and was actually current on the day it was needed — which is why “we have SOPs” and “our SOPs work” are different claims, and only the second one is worth anything. This is the sharper, process-level version of the same arithmetic in how to reduce key-person risk in your firm; that piece finds where the firm is exposed, this one is about making sure the fix actually holds when tested.

How to test it before you need it to work

The only honest way to know whether an SOP will survive a departure is to make someone who has never done the job try to use it while the person who wrote it is still there to notice where it breaks. Twice a year, pick two or three of the highest-risk SOPs on the register and hand them to someone unfamiliar with that role — a new starter during induction is the natural moment, because you need to train them anyway. Give them the document and nothing else, time how long it takes, and note every point where they stop and ask a question. Each question is a gap in the document, not a gap in the person, and it is far cheaper to find on a Tuesday afternoon than during a real handover with a client deadline attached.

This does double duty. It is a genuine test of the library, and it is also the fastest way to onboard a new team member into a process, which is the same discipline covered from the client side in how to onboard clients consistently. A firm that runs this test on even a handful of processes a year builds a library that gets more accurate over time instead of quietly rotting, which is the normal fate of documentation nobody ever opens again after it is written.

Where it lives

An SOP that is accurate but stored somewhere nobody looks does exactly as much good as one that was never written. It needs to live next to the work, ideally inside or linked directly from your practice-management system at the point the job template is opened — see how to choose practice-management software if that system is not yet doing this job for you — rather than in a shared drive folder that only gets opened when someone remembers it exists. If finding the SOP takes longer than doing the task from memory and hoping, people will keep doing it from memory, and the library becomes decoration.

What not to do

• Do not turn it into a one-off project during a quiet month. A library written in a burst and never touched again is stale within a year and nobody notices until it is tested by an actual departure.
• Do not let the person doing the job write it entirely alone. They will skip exactly the steps that are obvious to them, which are precisely the steps a stranger does not know. A short review by someone outside the role catches most of this in ten minutes.
• Do not confuse a policy with an SOP. A policy says what should happen — “invoices are reviewed before sending.” An SOP says exactly how, step by step, in enough detail that two different people produce the same result.
• Do not wait for a full library before testing anything. Test the first three well before writing the next twenty. A firm that documents everything and tests nothing has built an expensive folder, not a working system.

Do this month

• List every process that runs at least monthly and is currently held by one person. This is the priority list, and it is usually shorter than it feels.
• Rewrite the top three as numbered checklists with a trigger, an owner, and what “done” looks like — not as prose.
• Put a named owner and a review trigger on every existing SOP you already have, even the imperfect ones, so review stops depending on a calendar reminder nobody actions.
• Run the stranger test on one of them this month. Whatever they get stuck on is the next thing to fix.
• Make “review every SOP this person owns” a mandatory step on your leaver checklist, completed before the last day — not an afterthought once they are gone.

A library built this way is smaller than most firms expect and does more work than most firms expect from it, because the point was never the number of documents. It was always whether the firm keeps running, at the same standard, on the day someone who mattered walks out the door. If you want a quicker read on how exposed your own firm is right now — documentation included — the free Firm Operating Scorecard scores ten operating dimensions in about three minutes and shows you where to start.