What Is an SOP, and When Does a Small Business Actually Need One?

The short answer

An SOP is a written, step-by-step reference for how a specific task should be done, so the outcome doesn't depend on who happens to be doing it. It's worth writing once more than one person does the task or a mistake in it gets costly. It documents a process; it doesn't fix a bad one.

20 Sept 20266 min read

What is an SOP (standard operating procedure)?

Two people on your team quote the same kind of job differently: one adds a rush fee, the other doesn't think to; one mentions a discount for paying upfront, the other never brings it up. A customer talks to both and simply gets two different prices. Nobody did anything wrong exactly, they each just learned pricing their own way, and nobody ever wrote down which way was right.

An SOP is what closes that gap: a defined, repeatable set of instructions for completing a specific task the same way every time, so the outcome doesn't depend on who happened to pick it up. Good SOPs are narrow and specific ("how to quote a standard job" rather than "how sales works") because narrow SOPs stay accurate and get used, while broad ones go stale and get ignored.

The purpose isn't bureaucracy for its own sake. It's consistency: the outcome of a task shouldn't depend on which employee happens to be doing it that day, and knowledge about how to do it shouldn't live only in one person's head.

SOP vs. workflow: what's the difference?

The two are related but answer different questions.

	SOP	Workflow
Answers	"How do I correctly do this one task?"	"How does work actually move through the business, across people and systems?"
Scope	Usually a single task or narrow procedure	Usually a full process, end to end, involving multiple people or systems
Format	Numbered instructions, a checklist	A map: steps, owners, systems, handoffs
Changes when...	The correct way to do the task changes	The structure of the process itself changes

In practice: you map a workflow to see how a whole process runs, then write an SOP for the specific steps within it that need to be done exactly the same way every time, by whoever is doing them.

When should a business standardise a process?

Not every task needs a formal SOP: writing one for something done once a year by the owner alone usually isn't worth the effort. Standardise when you see one or more of these signals:

More than one person does the task, or will soon.
The task is done infrequently enough to be forgotten: quarterly tax steps, annual renewals, rare-but-important exception handling.
Different people currently do it differently, and it's producing inconsistent results or customer experience.
You're about to delegate, hire, or scale: an SOP is what lets a new person do a task correctly without shadowing someone for two weeks.
A mistake in this task is costly: compliance steps, anything client-facing, anything involving money.

If none of these apply, it's usually fine to leave a task undocumented for now. SOPs written "just in case" tend to go stale faster than they get used.

How to write an effective SOP

A good SOP follows a consistent structure and stays short enough that someone will actually read it under time pressure:

Purpose: one sentence on why this task exists and what outcome it produces.
Trigger: what starts this task. "When an order is marked returned," not "periodically."
Step-by-step instructions: numbered, specific, and written at the level of detail a genuinely new person would need. Screenshots or short video help for anything involving software.
Owner: who is responsible for this task by default.
Exceptions: the two or three most common ways this doesn't go as planned, and what to do about each. This is the section most SOPs skip, and it's usually the most useful part.
Where it lives, and review date: the SOP is only useful if people can find it, and only accurate if someone's responsible for checking it periodically.

The most common failure mode is an SOP that's too long and too general: a forty-page "how customer service works" document nobody opens. Narrow, specific SOPs for individual tasks get used; broad ones become shelfware.

Why SOPs don't always solve operational problems

Writing an SOP is a common instinct when something's going wrong, but an SOP only documents how a task is done. It doesn't change the task itself. When an SOP exists and the problem continues, it's usually one of these:

The process behind it is the problem. An accurate SOP for a task with unnecessary steps or unclear handoffs just formalises them. Redesign the process first.
Nobody can find it, or it's too long to use. An SOP that takes ten minutes to locate or read won't be used under time pressure.
It's out of date. A new system or a policy change quietly makes it wrong, and the next new starter follows it faithfully.
Nobody was shown it. Sending a link isn't the same as walking someone through the task once with the SOP in hand.

The first and third are covered in more detail under Common Mistakes below.

How to standardise without creating bureaucracy

Standardisation earns a bad reputation when it's applied everywhere instead of where it matters. A few guardrails keep it useful rather than burdensome:

Prioritise by risk and frequency. Write SOPs first for tasks that are done often and where mistakes are costly. Skip formal documentation for rare, low-stakes tasks.
Keep each SOP to one task. Resist the urge to combine several related tasks into one long document: it's harder to maintain and harder to use under time pressure.
Set a review cadence, and actually assign it to someone. Even a simple "review every six months" note with a named owner prevents silent staleness.
Treat SOPs as living documents, not permanent rules. If someone finds a better way to do the task, the process should be to update the SOP, not quietly work around it and leave the document wrong for the next person.

Where the usual answer falls short

An SOP is your first line of defence, not a bureaucracy exercise

If you've worked in a larger organisation, you may know the "three lines of defence" model (the Institute of Internal Auditors now calls it the Three Lines Model): operational controls (SOPs and the people following them), oversight (management and compliance checking the controls work), and independent assurance (audit). Most SMB owners only ever build the first line, informally, in one person's head. Writing it down doesn't add bureaucracy; it's the same first line of defence a larger business would insist on, just made explicit instead of trusted to memory.

Key takeaways

An SOP documents how to do one specific task consistently; a workflow map shows how a whole process flows across people and systems.
Standardise once more than one person does a task, mistakes are costly, or you're about to delegate or scale: not everything needs a formal SOP.
The exceptions section is usually the most valuable part of an SOP, and the part most commonly left out.
Writing an SOP for a broken process documents the inefficiency; redesign the process first, then write the SOP.

Where the mechanical parts of an SOP end

Writing an SOP is often the moment a business notices how much of a task is mechanical: copy this, send that, update the other system. Some of those mechanical steps can be automated, leaving a shorter SOP that covers only the parts that genuinely need a person.

Common mistakes

Mistake

Writing the SOP from memory instead of watching the task happen

Fix

The person writing an SOP often knows the task well enough to skip details that feel obvious to them but aren't to someone new. Watch the task being done once, or do it yourself, before writing the final version, rather than drafting purely from memory.

Mistake

Letting the SOP go stale

Fix

A process that's automated, or a system that gets replaced, or a policy that changes, quietly makes the SOP wrong until someone notices, usually because a new hire followed it and got the wrong result. An SOP without an owner and a review date is a slowly expiring asset, not a permanent fix.

Written the SOP, and want to know what could run itself?

Bring it to a free discovery call with our Principal Consultant. We'll go through which of its steps are mechanical enough to automate, leaving a shorter SOP that covers only the parts that still need a person.

Book a free discovery call

Next reads

How to Find Process BottlenecksDiagnose whether the real issue is missing standardisation or a structural bottleneck.How to Redesign a Business ProcessFix the process itself before writing the SOP for it.What Is Process Improvement?The broader practice an SOP is one output of.

Frequently asked questions

How long should an SOP be?

As short as it can be while still being specific enough for a genuinely new person to follow correctly: often one page, rarely more than two or three. If it's longer, the task is probably too broad and should be split into smaller SOPs.

Who should write an SOP: the manager or the person doing the task?

Ideally both. The person doing the task day to day usually knows the real steps and the common exceptions; a manager or owner can add context on why the task matters and where it fits into the bigger process.

How often should SOPs be reviewed?

For frequently used, high-stakes SOPs, every six months is a reasonable default. At minimum, review an SOP any time the underlying system, tool, or policy it describes changes.

Do small businesses really need SOPs, or is that overkill?

It depends entirely on the task, not the size of the business. A five-person business with one person handling all client refunds still benefits from a one-page SOP for that task: it's what lets someone else cover it without guessing.