How to Write an SOP People Actually Follow: A Step-by-Step Guide

What is an SOP, and what is it not?

A standard operating procedure (SOP) is a short written description of how a repeatable piece of work gets done: who does it, in what order, to what standard, and how you check it was done right. The US Environmental Protection Agency's long-standing guidance on preparing SOPs frames them as a core part of a quality system, because they make routine work consistent no matter who performs it.

An SOP is not a policy (which says what must be true, such as 'all refunds over a set limit need approval') and it is not a training course (which builds understanding and skill). It sits between the two: the practical instructions someone opens while doing the job. If a capable person can't open your SOP and follow it, it isn't doing its job, however polished it looks.

For small and growing teams, SOPs do three practical things. They take knowledge out of one person's head, so the business doesn't stop when that person is on leave. They make delegation possible, because the standard is written down. And they give you a baseline to improve from, since you can't tell whether a change is better if nobody agreed what 'normal' was.

Which processes should you document first?

The most common mistake is documenting what's easy to describe rather than what's costing money. Start by listing every repeatable process you can think of (aim for 30 or more, walking through a typical week, month and year), then score each from 1 to 5 on four factors.

A simple formula that works well in practice is: frequency multiplied by impact, plus knowledge risk counted twice, plus current pain. Frequency and impact are multiplied because a risky process done daily compounds its risk every day. Knowledge risk is doubled because it is the one that hurts without warning: the day your only payroll person resigns is the wrong day to start writing things down. Work on the top three first and ignore the rest until they're done.

Some important processes are hidden because nobody ever named them. Listen for phrases like 'ask Denise, she knows how', 'we usually...', 'it depends' and 'I'll just do it myself, it's quicker'. Each one points to a process that lives in one person's head, often with a high knowledge-risk score. Also watch for the founder bottleneck: if one person is listed as the owner of more than about a third of your processes, your SOP list is really a delegation plan, and the most valuable documents are the ones that let that person hand work over safely.

How do you map a process before writing it?

Experienced people often can't describe their own work from memory because so much of it has become automatic. Before writing steps, get the whole process onto one page. The SIPOC table, a tool from the Six Sigma tradition described by ASQ, lists Suppliers, Inputs, Process, Outputs and Customers.

Start by agreeing two boundaries: the start trigger (for example, 'signed order received') and the end point ('customer confirms delivery and invoice is sent'). Then write five to seven high-level steps as verb-noun pairs, followed by the outputs and who receives them, and finally the inputs and who supplies them. This order, starting in the middle, is usually quicker than going strictly left to right.

If several roles are involved, add a simple swimlane view: one row per role, with each step placed in the lane of the person who does it. Every time work crosses between lanes is a handoff, and handoffs are where work waits, gets dropped or gets done twice. Map what really happens today, workarounds included. If you document an ideal process while people keep doing the real one, the SOP will be ignored.

What should an SOP include?

A usable SOP has seven parts. Keep the structure the same across your library so people always know where to look.

• Header: title, SOP number, version, owner role, approver role, effective date and next review date.
• Purpose: one or two sentences on why the process exists and what goes wrong without it.
• Scope: what's covered, what isn't, and where to look for the exceptions.
• Roles: role titles rather than personal names, with decision limits for anyone who approves.
• Inputs and tools: the information, systems, access and templates needed before starting.
• Steps: numbered, one action per step, each starting with a verb, with decisions clearly marked.
• Checks and records: how the person confirms the work is right, what gets saved where, which measure shows the process is working, and a short revision history.

How do you write SOP steps that are easy to follow?

The fastest reliable method is to capture first and write second. Sit with the person who does the work for about twenty minutes, with their permission recording the screen if it's computer-based. Note one rough line for every action, and write 'DECISION' each time they make a judgment call. Ask 'why did you do that?' whenever something looks like a habit or shortcut; that's often where an unwritten rule is hiding.

Then turn the rough lines into steps using a few rules. Each step contains one action and starts with a verb. Locations are exact ('save to Clients > [Name] > 01 Onboarding', not 'save the file'). Standards are specific ('reply within four working hours', not 'reply promptly'). Avoid the passive voice: 'the form should be completed' hides who completes it. Where the process branches on two or more conditions, use a small decision table instead of a paragraph of 'in some cases'.

Add a brief reason only where people are likely to skip a step. For example, a step to confirm a supplier's bank details by phone is easier to follow when it says that payment-change requests by email are a common route for invoice fraud. With capture notes in hand, many people can produce a full first draft in about an hour of focused work.

Should an SOP be a checklist or a step list?

Match the format to the work. Linear tasks that are the same every time suit numbered steps. Tasks with many items to confirm, where order matters less, suit checklists. Heavily branching work suits decision tables or a one-page flowchart. Physical or on-screen techniques often work best as a short video plus a one-page summary.

Checklists deserve special mention because the evidence for them is unusually strong. A study published in the New England Journal of Medicine in 2009, covering eight hospitals in cities including Toronto, New Delhi, Manila, London and Seattle, reported that after a surgical safety checklist developed with the World Health Organization was introduced, the death rate fell from 1.5% to 0.8% and inpatient complications from 11% to 7%. The checklist didn't teach skilled people anything new; it made sure known steps happened every time.

In a business setting, keep checklists short (roughly nine items or fewer), tie them to a specific pause point such as 'before sending' or 'before sealing the box', and put them exactly where the work happens.

How do you test an SOP before rolling it out?

A draft isn't finished until someone who doesn't know the process has used it. This newcomer test is the step most often skipped and the one that matters most.

• Choose a competent person who has never done this task: a recent hire, or someone from another team.
• Give them the SOP and a real or realistic task. Ask them to follow it exactly and only ask questions if completely stuck.
• Watch silently and note every hesitation, wrong turn and question.
• Afterwards, ask: 'Where did you have to guess?'
• Fix every gap, then approve version 1.0 and record it in your SOP register.

How do you keep SOPs up to date?

Every SOP library starts to decay the day it's finished, because systems, people and clients keep changing. Three habits keep it alive: one named owner per SOP (a role with a current person in it), a review cycle based on risk (six months for high-risk or fast-changing processes, twelve for stable ones), and simple change rules.

Keep a register listing every SOP with its owner, version, status, last review date and next review date, and spend thirty minutes a month chasing anything due. Trigger an early review after a system change, a new regulation, an audit finding or a significant error. Only the owner edits the SOP; anyone can suggest changes; version numbers go up for every change; and the people affected get a two-line message saying what changed and when it takes effect.

Pair each important SOP with one outcome measure (is the process delivering?) and one process measure (is the SOP being followed?), and run small improvement tests using the Plan, Do, Check, Act cycle that ASQ describes. If you want an objective read on how well your team judges improvement opportunities, AssessAll's Lean & Continuous Improvement Judgment assessment is a useful starting point, and Jobulary for Teams can turn the results into individual development plans. If you'd like everything in one place, Bodhih's Run It Like a System kit includes an SOP master template, a SIPOC process map, a RACI matrix, two worked SOP examples and an Operations System workbook with a scored process inventory, SOP register and KPI tracker.