Every growing business has a few processes that live entirely in one person's head. How the monthly close actually gets done. Which vendor needs a PO and which does not. The exact steps to run payroll without breaking something. It works fine until that person is on vacation, gets promoted, or quits, and suddenly no one can close the books or pay a bill correctly. That is the risk undocumented back-office work quietly builds up, and it is entirely avoidable.
The answer is standard operating procedures, but most SOP efforts fail because they produce documents nobody reads. Here is how to write ones that survive turnover and actually get used.
Start with what hurts most if it breaks
Do not try to document everything at once. Start with the processes that are both critical and concentrated in one person. In the back office that is usually the monthly close, payroll, accounts payable, invoicing and collections, and bank reconciliations. If any of those can only be run by one individual, that is where you write first. The test is simple: if this person did not show up tomorrow, what would break, and how fast?
Write for a competent stranger
A good SOP assumes the reader is capable but has never done this specific task in your business. That means naming the exact systems, logins, and reports, not just "reconcile the accounts." Spell out the trigger (when does this happen), the steps in order, the tools used, who to hand off to, and what done looks like. Screenshots and short screen recordings do more than paragraphs. The goal is that someone new could follow it and produce the same result without asking.
Keep them short and specific
Nobody follows a twenty-page SOP. The most-used procedures are checklists: a sequence of concrete steps with the occasional note on why a step matters or what commonly goes wrong. If a process is genuinely long, break it into smaller linked procedures rather than one wall of text. Short and current beats thorough and ignored.
Make updating them part of the work
The reason SOPs rot is that they are written once and never touched again, so the first time reality differs from the doc, people stop trusting it. The fix is to make updates cheap and expected. Store SOPs somewhere editable and searchable, not in a PDF buried in a drive. When a process changes, updating the SOP is part of finishing the change, not a separate project. A quick note of who last reviewed it and when tells the next reader whether to trust it.
Use them to onboard, which tests them
The best proof that an SOP works is handing it to a new hire and watching them run the process from it alone. Every place they get stuck or have to ask is a gap in the document, and you fix it on the spot. This turns onboarding from weeks of shadowing into a repeatable, faster process, and it keeps the SOPs honest because they are used the moment someone joins.
The payoff
Documented back-office processes do more than reduce key-person risk. They make it possible to delegate work you have been holding onto, to catch when a step is being skipped, and to hand a clean, auditable process to a lender, buyer, or new controller. The business stops depending on any single person's memory, which is exactly what you want as you grow.
- Document the critical, single-person processes first: close, payroll, AP, invoicing, reconciliations.
- Write for a capable stranger: exact systems, steps, handoffs, and what done looks like.
- Keep them short, searchable, and editable, not buried PDFs.
- Update the SOP as part of changing the process, and note who reviewed it last.
- Onboard from them, and fix every gap you find.
Building a back office that does not depend on any one person is a core part of what our controller team sets up for growing companies.