How to create SOPs a founder actually maintains
Do not write SOPs from memory. Record yourself doing the task once, have the person who will own it write the first draft from the recording, then approve it. A usable SOP has seven parts: purpose, trigger, inputs and access, numbered steps, quality bar, escalation rule, and definition of done. Anything longer than one screen per task is a document nobody will open.
The seven parts
- Purpose — why this exists and what breaks without it
- Trigger — the exact event that starts it
- Inputs and access — data, tools, logins, templates
- Steps — numbered, each starting with a verb
- Quality bar — what good looks like, measurably
- Escalation — the named exceptions that come back to the founder
- Definition of done — the evidence that it is finished
The recording trick
Documentation feels impossible because founders imagine writing. Do the task once while recording your screen and narrating. The person who will own it converts that into the draft. Your job shrinks to a ten-minute review, which is a job you will actually do.
Keeping SOPs alive
An SOP without an owner and a review date rots within a quarter. Put a name and a review month at the top. The rule that works: whoever runs into an outdated step fixes it in the moment and notes the change.
How many you need
Fewer than you think. Cover the five recurring tasks that consume the most founder hours. Ten excellent SOPs beat forty abandoned ones.
Common follow-up questions
Video or written?
Written steps with a linked recording. Written is scannable and searchable; video carries the nuance for the first run.
Who owns SOP quality?
The person doing the work owns the draft and updates; the founder owns approval of the quality bar and escalation rules.