Most SOPs are written too early, in the wrong format, for the wrong audience. Then they sit unread until a project manager updates them once a year because the calendar reminded them to.
That is not how operating procedures earn their keep. A useful SOP is short, specific, written for one role, and revised when the work changes. The work of building useful procedures is upstream of writing them, it is deciding which procedures are worth documenting in the first place.
This post is the protocol for that decision and the format that follows from it.
Why Most SOPs Fail
Three patterns to watch for.
Pattern 1: SOPs written before the work has stabilized. A founder reads a book about systematizing the business and decides to write SOPs for everything. The SOPs are written based on how the work has been done in the past. Within three weeks, the work has changed because the business is still figuring itself out. The SOPs are now wrong, but no one updates them, because updating documents is no one's favorite task. Future hires inherit a stack of obsolete instructions and quietly stop following them.
The fix: SOPs are written for stable work, not for evolving work. If the procedure is still changing weekly, it is too early to document.
Pattern 2: SOPs written for the wrong audience. The SOP for "respond to customer email" is written by the founder, in the founder's mental model, in shorthand the founder understands. A new hire reads it, does not understand half the implicit context, and either improvises or asks for clarification. The SOP did not save the time it cost to write.
The fix: SOPs are written for the person who will execute them, not for the person who already knows the work. Specifically, written for a competent person who is encountering the procedure for the first time and has no other context.
Pattern 3: SOPs written in a format no one can use. A 12-page document for what should be a 1-page checklist. A flowchart for what could be a numbered list. A video walkthrough for what could be a written sequence (or vice versa). The format mismatch makes the SOP harder to consult than just asking someone.
The fix: format matches the use case. Repeated short tasks → checklists. Multi-step procedures → numbered sequences. Decision trees → flowcharts. Skill demonstrations → videos.
When to Write the SOP
Three conditions, all of which should be true before documentation is worth the time.
Condition 1: The procedure has run at least 5-10 times the same way. Before that, the work is still being figured out. Documenting prematurely locks in a specific version that may not be the best version. After 5-10 reps, the steps have stabilized enough that documentation reflects something durable.
Condition 2: The procedure will run again in the foreseeable future. A procedure that runs once a year is rarely worth documenting in detail, by the time it runs again, you will have forgotten the document, the document will be out of date, and you will rebuild it from scratch anyway. Procedures worth documenting run at least monthly, ideally weekly.
Condition 3: Someone other than you will execute it. The strongest case for an SOP is that you intend to delegate the work. If the procedure will only ever be run by you, a private checklist or even mental routine may be enough. SOPs cost time to write; they pay back when they replace your supervision.
If all three conditions are true, the SOP is worth writing. If any one is false, hold off, write a brief private note instead, and revisit later.
What to Document, What to Leave Intuitive
Not every part of a procedure needs to be documented. The line between "specify" and "leave to judgment" determines whether the SOP is useful or burdensome.
Specify:
- Exact sequence of steps when order matters
- Specific decision criteria (e.g., "if order value > $500, route to sales lead; else self-service")
- Hard quality standards (e.g., "no email response after 3 PM Friday goes out before Monday at 9 AM")
- Required information at each step (e.g., "include customer name, order ID, issue category")
- Dependencies on other systems or roles
Leave intuitive:
- Tone and voice (better to define brand voice once, reference everywhere)
- Soft judgment calls that depend on context (e.g., "decide whether to escalate based on situation")
- Anything that varies meaningfully customer to customer
- Tasks that require taste or aesthetic judgment
The test: if the procedure can be executed by a competent person reading the SOP cold, the right things are specified. If the SOP requires the executor to make judgment calls, those calls are correctly left intuitive.
SOP Format That Actually Gets Used
The format that survives is the format that can be consulted in 30 seconds.
One page maximum for most procedures. If it does not fit on one page, the procedure is probably two procedures and should be split.
Numbered steps, in order, with verbs.
Decision points called out explicitly with the criteria written.
A revision date at the top so anyone can see when it was last updated. SOPs that have not been revised in 6+ months should be reviewed for accuracy before assumed correct.
A single owner named at the top, even if multiple people execute it. The owner is the person responsible for keeping it current.
A useful SOP looks something like:
Customer Onboarding Email Sequence Owner: Operations Lead. Last revised: 2026-04-15.
- Within 1 hour of payment, send Welcome Email (template W-01) with the calendar link.
- If no booking within 48 hours, send Follow-up Email (template W-02).
- If no booking within 7 days, escalate to founder for personal outreach.
- Once booked, mark account as ONBOARDED in CRM and assign to delivery queue.
Decision points:
- If customer requests refund before booking, route to billing, do not continue sequence.
- If customer is enterprise tier, skip step 2 and go directly to founder outreach.
That is enough. A new hire can execute this on day one. The founder can audit it in 30 seconds. Updates take five minutes.
When to Skip the SOP
Some work resists documentation, and trying to force it produces overhead without benefit.
Highly creative work. A copywriter's process for finding a headline does not benefit from a 6-step SOP. The work is too contextual. What helps is a brief: voice guidelines, audience description, the goal of the piece. The execution is judgment.
Complex decision-making. A senior person evaluating whether to take on a particular client cannot follow an SOP for that decision. They are integrating dozens of signals. What helps is a decision framework or a list of considerations, not a procedure.
One-off projects. Each one is different enough that documenting one teaches little about the next. Project plans replace SOPs here.
Work the founder still loves doing. If the founder has not delegated something and is not planning to, an SOP is overhead. The founder's mental model is the SOP.
The general principle: SOPs serve repeated, role-bound, executable-by-someone-else work. Other kinds of work need different tools.
How to Maintain Them
The single biggest reason SOPs fail is that they go stale and no one updates them.
Three habits that prevent staleness.
Habit 1: Update at the moment the procedure changes. The right time to update an SOP is the same week the procedure changes, not the next quarterly review. The friction is much lower in the moment, and the SOP stays accurate without dedicated maintenance time.
Habit 2: Quarterly audit of the SOP library. Once per quarter, the operations owner spends 30-60 minutes scanning the SOPs and flagging any that look stale. The signal is usually the revision date, anything more than 6 months old gets a quick check.
Habit 3: Make "fix the SOP" part of the executor's job. The person executing the SOP is the person who will encounter the gaps and inaccuracies first. Empowering them to update the SOP directly (rather than escalating) is what keeps documentation alive. SOPs that can only be updated by the founder or the owner are SOPs that drift.
The Cost-Benefit Test
Before writing any SOP, run the cost-benefit test:
Cost: time to write × times to update = total maintenance investment
Benefit: time saved per execution × frequency of execution × number of people executing = total leverage produced
If the benefit clearly exceeds the cost, write it. If they are roughly equal, skip it. If the cost exceeds the benefit, definitely skip it.
A 30-minute SOP that saves 5 minutes per execution, runs 50 times per year, executed by 3 people, produces:
- Cost: 30 minutes initial + 30 minutes annual update = 60 minutes/year
- Benefit: 5 × 50 × 3 = 750 minutes/year saved
A 12.5x return. Worth writing.
A 30-minute SOP that saves 2 minutes per execution, runs 12 times per year, executed by 1 person, produces:
- Cost: 30 minutes initial + 30 minutes annual update = 60 minutes/year
- Benefit: 2 × 12 × 1 = 24 minutes/year saved
A 0.4x return. Not worth writing.
The math kills most SOP candidates. That is the point.
What This Produces
An operation that has the right SOPs and skips the wrong ones runs differently from one that has documented everything or nothing.
Within 30 days. The team experiences less interruption from "how do I do this" questions on the procedures that are actually documented. The procedures that should not have been documented are not, saving the time of writing them and the friction of maintaining them.
Within 90 days. Onboarding new hires takes less time, because the SOPs that exist are useful and the work that is judgment-based is named as such (rather than being expected to come from a document).
Within a year. The SOP library has been pruned at least once. Some procedures that seemed worth documenting turned out not to be, and were retired. New procedures have been added as the business stabilized in new areas. The library reflects the actual operation, not the operation as it existed two versions ago.
Across years. The business can scale to additional people without the chaos that comes from undocumented work or the bureaucracy that comes from over-documented work. The middle path, document what repays itself, leave the rest to judgment, is what makes operations actually scalable.
Production becomes possible when each system has a job and that job is understood. SOPs are the operational version of that understanding for repeated, role-bound work. Useful for what they are designed for, costly when applied to work they were not designed for.
That is the protocol. Three conditions before writing. Specify what matters, leave judgment to judgment. One-page format. Update at the moment of change.
The SOPs that survive are the ones that earn their keep on the math.
The Seven Figure Framework. An email series on positioning, metrics, and execution for founders ready to scale. Free.