Standard Operating Procedures (SOPs) are written guides that describe how a recurring task in your business gets done, step by step, in enough detail that someone other than you could follow them. They aren't the same as policies (which describe what's allowed) or checklists (which are usually a subset of an SOP). A good SOP captures the sequence, the inputs, the outputs, and the small judgement calls that turn a generic task into one done your way.
For a solo founder or a small team, the value of SOPs isn't compliance — it's leverage. The first time I write down how I run a client onboarding, the SOP feels redundant; the second time I do an onboarding, it saves me twenty minutes; the third time, it's good enough that an assistant or a contractor could run most of it without me. Multiplied across the recurring work in any service business, the time saved is what frees up the hours that go into higher-value work.
I write SOPs in the format that matches the task. Sequential, low-judgement work (like a publishing checklist) gets a numbered list. Decision-heavy work (like client triage) gets a flowchart with branches. Anything visual or interface-driven (like a recurring report build) gets a short Loom video alongside the text — most teams retain visual instructions better than written ones, and the recording is faster to make than a screenshot-by-screenshot writeup.
The one rule I hold firmly is that SOPs need an owner. An undocumented process is fragile; a documented process that nobody updates becomes wrong, which is worse than not having it at all.