How to create an SOP (and why most teams never finish one)
Most SOP projects die in a shared doc somewhere. Here is what separates the teams that actually finish their documentation from the ones that keep planning to.
Published · by The Sendabrief Team
Most operations teams have a standing intention to document their processes. Fewer than half ever do. The gap is not ambition: it is friction. Writing an SOP from a blank page requires the people who are busiest doing the work to stop and narrate it. This guide covers the seven sections every good SOP needs, the most common failure points, and how to cut the time it takes to produce a finished document from two hours to under five minutes.
Why most SOPs never get written
The problem is not that people do not want documentation. It is that the people who could write the SOP are the same people who are too busy to write it. The senior operator who runs the refund process, the account manager who knows the client onboarding flow, the tech lead who handles the deployment checklist: all of them have the knowledge. None of them have ninety minutes to spend on a Notion page.
The second failure is structural. Most SOP projects start with a template and a deadline, then stall when the first person asked to fill in the template cannot find two uninterrupted hours. Unfinished documentation is not better than no documentation: it is a liability, because the next person to look for it finds a half-completed draft and assumes it is wrong.
The third failure is maintenance. Even when an SOP gets written, it frequently goes stale within six months because no one is assigned to update it and no process exists to flag when a step changes.
The seven sections every SOP needs
Good SOPs share a consistent structure. Teams that improvise their format end up with a library of incompatible documents, each organized differently, all hard to search.
Section 1: Title. One line, written in plain English, that describes exactly what the procedure covers. Not 'Client Process' but 'How to onboard a new client from signed contract to kickoff call.'
Section 2: Trigger. The event or condition that starts the procedure. 'When a new contract is marked Closed Won in the CRM' or 'When a support ticket is escalated to Level 2.' Without a trigger, nobody knows when to use the SOP.
Section 3: Owner. The role (not the person) responsible for ensuring the procedure runs. Roles persist when individuals leave. List the person in a separate implementation note if needed, but the SOP owns the role.
Section 4: Steps. Numbered, ordered, written in imperative voice. Each step does exactly one thing. If a step has sub-steps, indent them. Keep each step to one sentence where possible.
Section 5: Roles per step. Tag each numbered step with the role responsible for completing it. This is the difference between a checklist and an SOP. Role tagging surfaces handoffs, clarifies accountability, and makes it obvious when a process depends on someone outside the immediate team.
Section 6: Decision points and exceptions. List the conditions under which the standard path branches and what to do in each case. This is the most consistently skipped section. It is also the section that determines whether the SOP survives contact with reality.
Section 7: Review cadence. State who reviews the SOP and how often. Quarterly is a reasonable default. Without this section, every SOP eventually becomes a historical artifact that people stop trusting.
How to actually get the SOP written
The fastest path to a finished SOP is not to write it. It is to say it. Record a 10 to 15 minute walkthrough of the process on a Zoom or Google Meet call, then convert that recording into a structured draft. The recording captures what someone would actually say when explaining the procedure, including the edge cases and exceptions that never make it into a blank-page draft.
If no recording exists, two faster alternatives produce the same structured output. First: type a plain-English description of the process in bullet points or half-sentences, as if explaining it to a new hire in a Slack message. Most operators can do this in five minutes. Second: click record in a browser tab and describe the process out loud for one to three minutes. Both inputs produce a structured seven-section SOP without writing from a blank page.
The output needs one round of editing, typically five to ten minutes. The structure, step ordering, role assignment, and decision point capture come from the source material. The editor's job is to verify accuracy and add any context the source missed.
The editing checklist
Once a draft exists, run through five checks before publishing. First: does every step have a clear owner role? Second: is the trigger specific enough that anyone on the team would know when to use this SOP without asking? Third: are exceptions and decision points documented, or does the SOP assume the happy path only? Fourth: is each step written in imperative voice with a single action per step? Fifth: is there a named reviewer and a review date set in the next 90 days?
A draft that passes these five checks is ready to ship. Do not wait for it to be perfect. An SOP that is 90% correct and published is more valuable than a 100% correct SOP sitting in a draft folder.
Where to store SOPs
Store SOPs where your team already searches. If the team lives in Notion, publish SOPs in Notion. If the team uses Confluence, publish there. The format matters less than the discoverability. An SOP nobody can find is not a useful document.
If you are starting a documentation system from scratch, prioritize searchability and version control over visual design. A searchable plain-text SOP with version history is more useful than a beautifully formatted document that nobody can find when the process breaks at 11pm.
The one infrastructure decision worth making early: assign a single owner for the documentation library. Not a team, a person. Documentation systems maintained by committees drift. Documentation systems maintained by one accountable owner tend to stay current.
Frequently asked
What is the right length for an SOP?
Long enough to be unambiguous, short enough to be read. Most SOPs should fit on one to two pages. If a procedure requires more than fifteen numbered steps, it is probably two procedures that should be documented separately.
What format should I use for an SOP?
The seven-section format in this article works for most operational processes: title, trigger, owner, steps, roles per step, decision points, and review cadence. For highly visual or software-specific procedures, add annotated screenshots after the numbered steps.
How often should SOPs be reviewed?
Quarterly is a reasonable default. High-velocity processes (weekly cadence, frequent tool changes) warrant monthly review. Stable processes (annual filing, hardware setup) can be reviewed every six months. The key is to name a reviewer and set a calendar reminder, not to pick the theoretically correct interval.
Can I generate an SOP automatically?
Yes. Sendabrief converts meeting recordings, chat screenshots, transcript exports, typed plain-English descriptions, and live browser voice recordings into structured SOPs that follow the seven-section format. The output is a draft that typically requires five to ten minutes of editing rather than ninety minutes of writing.
Who should own the SOP writing process?
The person who runs the process writes the first draft, because they have the content. An operations lead or team lead reviews and publishes, because they have the standards context. Maintenance responsibility goes to whoever owns the process long-term. Those three roles are often one person on a small team; on a larger team, separate them explicitly.