What to include in an SOP comes down to seven parts: scope, trigger, owner, numbered steps, exceptions, where the document lives, and when it gets reviewed. Miss the trigger or the owner and the document becomes reference material nobody opens. Everything else is formatting.
If your last attempt at documenting a process ended up in a shared folder and stayed there, the problem was not discipline. It was almost certainly that nothing in the document told anyone when to open it.
What to Include in an SOP: The Seven Parts
Work through these in order. Each one answers a question someone will otherwise have to ask you.
1. Scope — what this covers and what it does not. One or two sentences. "Covers invoicing for retainer clients. Does not cover project invoices or refunds." Scope is how you keep one document from quietly growing into five.
2. Trigger — the moment this procedure starts. This is the part most procedures skip. A trigger is an event, not a time of day: "a signed proposal lands in the sales inbox", "stock on hand drops below six units", "a client misses a second payment date". Without a trigger, the document has no entry point, so it never gets opened.
3. Owner — one named role, not a team. Write the role, not the person, so the document survives staff changes: "Operations lead", not "Maria". The owner is accountable for the procedure working and for keeping it current. Shared ownership means no ownership.
4. Numbered steps in the order they happen. One action per step, starting with a verb. If a step contains the word "and", it is probably two steps. Aim for a number a person can hold in their head — somewhere between five and fifteen. Beyond that, split the procedure.
5. Exceptions — what to do when the normal path breaks. The exceptions are where mistakes actually happen, and they are almost always the part left out. Three or four lines is enough: what the exception is, who decides, and what the fallback action is.
6. Where it lives — the exact location, named in the document. Not "the drive". The folder, the board, the tab. If the procedure is for work that happens inside a tool, the link to the procedure belongs inside that tool.
7. Review date — a date, not an intention. "Review: first Monday in April" is a date. "Review quarterly" is a wish. Put the date on the document and in the owner’s calendar.
A One-Page SOP Format You Can Copy
Keep the whole thing on one screen. This is the skeleton:
| Field | What goes here |
|---|---|
| Procedure name | Plain language, as people would say it out loud |
| Scope | What it covers, what it excludes |
| Trigger | The event that starts the work |
| Owner | A role |
| Tools needed | Logins, files, templates used |
| Steps | Numbered, one action each, verb first |
| Exceptions | The two or three ways it goes wrong, and who decides |
| Done looks like | How the person knows they finished |
| Lives at | Exact location |
| Last updated / review date | Two dates |
"Done looks like" is the field people add last and value most. Without it, two people doing the same procedure finish at different points, and the gap between those points is where work falls through.
What to Include in an SOP When the Work Has Exceptions
Most real work is not linear, which is why clean procedures feel dishonest to the people doing the job. You have two sane options.
Inline branches. At the step where the path forks, write the fork: "5. Check whether the client is on a retainer. If yes, go to step 6. If no, go to step 9." This works when there are one or two forks.
A separate procedure. When a fork has more than about four steps of its own, it is a different procedure. Give it its own document and link to it from the parent step. One long document that tries to cover every variant is the most common reason a procedure gets abandoned.
What you should not do is write the happy path only and leave the exceptions in your head. That turns every edge case into an interruption for you, which is the exact outcome documentation is supposed to prevent.
Write It From the Chair, Not From Memory
The person who does the job writes the first draft, while doing the job. Not afterwards, from memory.
There is a reason for this. When you write a procedure from memory, you describe how you think the work goes. When you write it while the work is happening, you capture the small steps you stopped noticing years ago — the field that has to be filled in a particular order, the tab that has to be open first, the name you have to check against a list.
Practical version: do the task once with the document open beside you and type each step as you take it. Rough notes are fine. Tidy the wording later.
How the Document Gets Updated
A procedure with no update route rots in about a quarter. Build the route into the document itself.
- The owner gets a review date in their calendar, not just on the page.
- Anyone who hits a step that is wrong writes the correction straight onto the document, or adds a comment. No approval needed for a factual fix.
- A change to the sequence, not just the wording, means the owner tells whoever else runs the procedure. One line is enough.
- Each update bumps the "last updated" date. A document with no date gets treated as untrustworthy, which it probably is.
The point is that corrections should be cheaper than workarounds. The moment it is easier to ask you than to fix the document, you are back where you started.
Why Procedures Get Ignored, and the Fix for Each
| Reason it gets ignored | Fix |
|---|---|
| Too long to read mid-task | One page, one screen, split anything longer |
| No trigger, so nobody opens it | Name the event that starts the work |
| Stored away from the work | Put the link inside the tool where the work happens |
| Written by someone who does not do the job | The doer writes the draft |
| Nobody owns it | One named role, with the review date in their calendar |
| Out of date once, so distrusted forever | Visible "last updated" date and easy corrections |
Run this list against any procedure you already have. Most documentation problems are one of these six, and each has a fix that takes under an hour.
Start With the Procedure That Interrupts You Most
Do not try to document everything. Pick the one task that generates the most questions from other people in a normal week, and write that procedure first. You will feel the difference within days, and that feeling is what gets the second one written.
Then do the next one. Five solid one-page procedures covering your highest-interruption work beat forty half-finished documents by a wide margin.
If you would rather start from a structure than a blank page, the SOP templates page has the one-page format above already laid out, with the fields and exception blocks in place, so you only have to supply the steps. The wider template library covers the surrounding documents — onboarding packs, process trackers and the rest — and the free business growth template download page is a reasonable place to start if you want to test the format on a single procedure before committing to more.
Templates are starting points, not professional advice. Anything in a procedure that touches employment terms, contracts or tax treatment should be reviewed by a lawyer or accountant in your jurisdiction, because the rules differ from one place to another.