Most teams have tried writing standard operating procedures at least once. Someone spends a week documenting everything, the documents go into a shared folder, and six months later nobody can find them and half of them are wrong. The problem is rarely effort. It is writing the wrong SOPs in the wrong format, with nobody responsible for keeping them true.
A good SOP is short, specific to one task, and easy to use while actually doing the work. Here is how to write ones that people open.
Decide what to document first
Do not try to document the whole business. Start with the tasks where a missing procedure costs the most. A quick way to rank them:
- Tasks only one person knows how to do. If they are out sick or leave, the work stops.
- Tasks where mistakes are expensive. Billing, payroll, customer onboarding, anything with compliance attached.
- Tasks that are done often by different people. Inconsistency here shows up directly to customers.
- Tasks done rarely. Quarterly or annual work that everyone has to relearn each time.
Five well-written SOPs for the riskiest tasks are worth more than fifty that nobody trusts.
Write it with the person who does the work
The most common SOP failure is a procedure written by a manager describing how the task should work, rather than how it actually works. Sit with the person who does it, or ask them to record their screen while they talk through it. Write down what they really do, including the workarounds.
Then improve it. Documenting a process is often the first time anyone has seen it end to end, and the redundant steps become obvious. That is the moment to fix them, before they are written into the standard. My process improvement framework covers how to do that without disrupting the team.
A simple SOP template
Every SOP should answer the same questions in the same order, so people know where to look. Copy this structure:
- Title. The task, named the way people actually say it. "Onboard a new client", not "Client Lifecycle Initiation Procedure".
- Purpose. One sentence on why the task matters and what goes wrong if it is skipped.
- Owner. The person responsible for keeping this SOP accurate.
- Trigger. What starts the task: a signed contract, the first of the month, a support ticket of a certain type.
- What you need. Access, tools, templates and information required before starting.
- Steps. Numbered, one action per step, starting with a verb. Link to the exact screen, file or template at each step.
- Definition of done. How the person knows the task is complete and correct.
- Exceptions. The common cases where the normal steps do not apply, and what to do instead.
- Last reviewed. The date and who checked it.
Screenshots help for software tasks, but only where they add something. They are also the first part of an SOP to go out of date.
Pick the right format for the task
- Checklist for routine tasks the person already understands, where the risk is forgetting a step.
- Step-by-step instructions for tasks someone might do for the first time.
- Flowchart or decision tree for tasks with branches, such as handling different types of support request.
- Short screen recording for complex software tasks, paired with a written checklist people can follow along with.
Mixing formats is fine. A recorded walkthrough for training plus a one-page checklist for daily use is a common, effective combination.
Keep SOPs current
An out-of-date SOP is worse than none, because people follow it confidently into the wrong result. Three habits keep them accurate:
- Every SOP has an owner who updates it when the process changes.
- Review on a schedule. High-risk SOPs quarterly, the rest at least once a year. Put the review in the calendar.
- Make updating easy. Anyone who spots an error should be able to flag it in seconds, with a comment or a quick message to the owner.
Store SOPs where the work happens, linked from the tool or checklist people already use, rather than in a folder nobody visits. A quick look at whether procedures are being followed is a natural item for a weekly ops review.
Good SOPs are short, specific to one task, written with the person who actually does the work, and owned by someone who keeps them true. Start with the tasks that are risky, rarely done or only known by one person, use one consistent template, pick a format that matches the task, and review on a schedule so nobody follows a procedure that stopped being accurate months ago.
FAQ
What is a standard operating procedure (SOP)?
An SOP is a written, step-by-step description of how to complete a specific recurring task, so it is done the same way and to the same standard no matter who does it.
What should an SOP template include?
A clear title, purpose, owner, trigger, what you need before starting, numbered steps, a definition of done, common exceptions, and the date it was last reviewed.
Which processes should I document first?
Start with tasks only one person knows, tasks where mistakes are expensive, tasks done often by different people, and tasks done so rarely that everyone has to relearn them.
How long should an SOP be?
As short as possible while still being complete. Most good SOPs fit on one or two pages. If one runs much longer, it usually covers more than one task and should be split.
How often should SOPs be reviewed?
High-risk SOPs every quarter and the rest at least once a year, plus whenever the underlying process or tool changes. Each SOP should have a named owner responsible for this.
What is the difference between an SOP and a checklist?
A checklist is one possible format for an SOP. It suits routine tasks where people know the work and only need a reminder of each step. Newer staff or complex tasks usually need fuller step-by-step instructions.
Read next
Want your key processes documented properly?
I help teams find the procedures that matter, write them with the people who do the work, and set up the ownership that keeps them current. See how I work.
Book a Call