Search for how to write an SOP and you will get a dozen templates. Templates are not the bottleneck. Plenty of teams have a beautifully formatted document that nobody follows, because the steps are vague, the exceptions are missing, and it has not been true since the tool changed in March.
Here is what actually makes the difference.
The four parts an SOP needs
Strip away formatting preferences and every usable procedure has the same four components.
1. A trigger
The specific event that starts the process, including who notices it. Not "invoice processing" but "when a supplier invoice arrives in the accounts inbox". A reader needs to know whether this document applies to the situation in front of them right now, and a title alone rarely tells them.
2. Roles
Who does each step. Job functions, not people's names, because names go stale the moment someone changes team. If a step does not name who performs it, it will end up being done by nobody or by two people.
3. Numbered steps, in order
One action per step. Numbered so people can say "I'm stuck on step 4", which is a far more useful sentence than "I'm stuck somewhere in the middle".
4. What to do when the answer changes the path
This is the part almost every template omits, and the part that decides whether the document survives real use. More below.
Write steps that cannot be misread
The most common failure in SOP writing is a step that is perfectly clear to the person who wrote it and ambiguous to everyone else. Three rules fix most of it.
Start with who, then the verb
Write "Finance Manager uploads the invoice to Xero", not "the invoice is uploaded" and not "upload the invoice". Passive voice hides the actor, and a bare imperative assumes the reader knows it is their job. Subject-first removes both problems.
One action per step
"Create the folder and share it with the team" is two steps. Compound steps get half-completed, and a reader who is interrupted between the two halves has no way to record where they stopped.
Name the actual tool and the actual place
"Log the request" is not a step. "Support Lead creates a ticket in the Zendesk Onboarding view" is. If a step could be satisfied in three different systems, it will be, and then your data lives in three places.
Handle the forks, or the SOP breaks exactly where it matters
Real processes are not linear. They fork: the client is on the enterprise plan or they are not, the approval comes back yes or no, the payment clears or it bounces. A step that says "check whether the invoice is over 5,000" and then continues in a straight line has stopped being followable precisely at the point where the reader needed help.
Two ways to handle it properly.
- Make the decision its own step, phrased as a question, with each answer pointing at a specific step number. "Is the invoice over 5,000? If yes, go to step 7. If no, go to step 9."
- If a whole branch is substantial, split it into a separate procedure and link to it. One document trying to cover four significantly different paths becomes unreadable.
Branches also need to be allowed to point backwards. A rejected item that gets corrected and resubmitted goes back through the same review step. People often duplicate the review step rather than loop, which then means two copies drift apart.
Put exceptions on the step they apply to
Exceptions, approval thresholds, and known failure modes belong on the specific step they affect, not in a general notes section at the bottom. Nobody reads the bottom of a document while executing step 3.
If a caveat genuinely applies to the whole procedure, for example "this only applies to enterprise-tier clients", it goes at the very top where it can prevent someone starting the wrong process, not at the end where it tells them they just wasted an hour.
Document the prohibitions, not just the correct action
If your team knows never to reply to client feedback by email because everything must go through the portal, write that down. Documenting only the correct action assumes the reader will not think of the wrong one, and the wrong one is usually the more obvious move.
This is one of the highest-value additions to any SOP and one of the most commonly skipped, because the person writing it stopped considering the wrong option years ago.
Decide who approves it before you need to
An SOP that anyone can edit silently is not a source of truth, it is a wiki page. At minimum: someone other than the author reads a change before it goes live, and you can see what changed.
It does not need to be heavy. One reviewer who is not the author catches most errors. The rule that matters is that the author cannot approve their own change, because self-review finds very little.
Set a review date, because it will go stale
Every SOP has a shelf life. The tool gets a new interface, the threshold changes, the team reorganises. An SOP that is quietly wrong is worse than none, because people follow it.
So give each one a review cadence and an owner. Quarterly for anything touching a system that changes often, annually for stable procedures. The point is that going stale becomes visible instead of being discovered by someone doing the wrong thing confidently.
A working checklist
- Name the trigger event and who notices it.
- List the roles involved, as functions rather than names.
- Write numbered steps, subject-first, one action each, naming real tools and real locations.
- Turn every fork into a decision step with each answer pointing at a specific step.
- Attach exceptions and failure modes to the step they affect.
- Write down the prohibitions, not just the correct path.
- Have someone who has never done the task perform it from the document.
- Fix every question they had to ask.
- Assign a reviewer who is not the author.
- Set a review date and an owner.
The shortcut worth taking
Everything above is about quality, and none of it addresses the real reason SOPs do not exist: the person who knows the process is the busiest person on the team, and writing is slow.
That is the specific problem Sendabrief solves. Click through the process once and every click becomes a numbered step with a screenshot. Or explain it out loud for two minutes. Or upload the document that half-covers it. You get a structured first draft with a trigger, roles, numbered steps, and decision branches, and your job becomes correcting a draft instead of facing an empty page. Reviewing is much faster than authoring, which is why it actually gets done.