SOP means standard operating procedure. The definition, in one sentence: a document that sets out how a recurring task gets done, including what starts it, who does each part, the steps in order, and what to do at the points where the answer changes the path.
A useful SOP answers those four questions and nothing more. Anything else in the document, the background, the rationale, the org chart, belongs somewhere a reader is not standing in the middle of the task.
Note the word recurring. A one-off project does not need an SOP; it needs a plan. SOPs, plural, are for the things that happen repeatedly and need to happen the same way each time, whoever is on shift. Most organisations end up with dozens of them, which is why where they live matters as much as how they are written.
What does SOP mean in business?
In a business context, an SOP is the written answer to "how do we do this here". It is not a rule and not a goal: it is the agreed sequence for a task that recurs, written so that the person doing it for the first time reaches the same outcome as the person who has done it a hundred times.
The business case for having them is narrower than it sounds. An SOP earns its keep in exactly three situations: when the person who knows the process is unavailable, when someone new has to perform it, and when getting it wrong is expensive. If none of those apply to a task, writing a procedure for it is administration rather than operations.
What does SOP stand for?
SOP stands for standard operating procedure. Each word is doing work: standard because the point is that it happens the same way every time, operating because it describes work being performed rather than policy being stated, and procedure because it is a sequence rather than a principle.
It is worth knowing the neighbouring terms, because using the wrong one produces a document that fails in a predictable way:
- A policy states a rule and why it exists. An SOP states the steps that satisfy it.
- A work instruction covers one task at one station, in much more detail. An SOP spans roles.
- A process is what actually happens. An SOP is the written description of it.
- An operations manual is the organised collection of your SOPs plus the context that makes them navigable.
Why they matter, concretely
The generic answer is consistency. The specific answers are more persuasive:
- When someone leaves, the process does not leave with them. This is the reason most teams finally write them, usually a fortnight too late.
- New hires become useful faster, because the answer to "how do we do this" is a document rather than an interruption.
- Mistakes get cheaper. A documented process can be corrected once, in one place, rather than re-explained to each person who gets it wrong.
- Diligence and audits ask for them. An investor is pricing key-person risk; an auditor is testing whether the control you described actually operates.
- They make delegation possible. You cannot hand over a task that only exists in your head.
What separates an SOP people follow from one they ignore
Most SOPs fail for the same three reasons, and none of them are about formatting.
- The steps are too vague to act on. "Log the request" is not a step. "Support Lead creates a ticket in the Zendesk Onboarding view" is.
- The exceptions are missing. Real processes have thresholds and edge cases, and a document that only covers the happy path stops being useful exactly when someone needed help.
- It went stale and nobody noticed. An SOP that is quietly wrong is worse than none, because people follow it.
The fix for the first two is detail and decision branches. The fix for the third is a review date with a named owner, so going stale becomes a visible event rather than something discovered by someone confidently doing the wrong thing.
How long should one be?
As long as the process and no longer. If it runs past roughly fifteen steps, check whether it is actually two procedures joined at a handoff, which it usually is. Splitting them and linking beats one document nobody finishes.
Writing your first one
Pick the process that would hurt most if the person who does it were unavailable tomorrow. That is almost never the most complicated one; it is usually something mundane with an external deadline attached.
Then do not start from a blank page. Either work from a finished template for a similar procedure, or click through the process once and let the steps be written from what you actually did. The blank page is the reason most SOP projects stall in week one.