How your business remembers how it works, without asking anyone

What standard operating procedures actually are (and what they are not)

The definition sounds heavier than the thing itself. In practice a standard operating procedure covers one repeating task, fits on roughly one page, and lives in one agreed place, so there is a single source of truth for how the task is done. It is a policy's practical other half: a policy says what you do and why, an SOP says how, step by step.

What trips small businesses up is imagining the opposite. An SOP is not a forty-page manual, not a compliance binder nobody reopens, and not something you write once and never touch again. For most tasks, one clear page is enough, and going much beyond that usually means it will not get read. Procedures like these existed long before ISO 9001 or the Care Quality Commission ever asked for them, so write yours for the business first and let any audit be the bonus.

The opposite shapes are just as easy to spot, and they are the reason SOPs get a bad name.

The cost of running on heroes and inboxes

When nobody has written the task down, the business only knows how it works through the person who happens to do it. That knowledge sits in their head as tribal knowledge, not anywhere you can point to, and it holds up fine right until they are off sick, on holiday, or handing in their notice. A business where one person leaving can stall the whole operation has quietly built itself around a single point of failure. This is key-person dependence, sometimes called the bus factor, and it costs you long before anyone actually leaves.

The quieter signs cost just as much, because they compound weekly rather than arriving as a crisis.

Add these up and the pattern has a name: firefighting instead of progress, inconsistency your customers can feel, and a hero culture that looks like loyalty but is really fragility. It caps how far you can delegate, grow, or one day sell.

None of this means you have done anything wrong. It is what growth looks like before the knowledge catches up, and every part of it is fixable.

SOPs, process documentation, and knowledge bases: what is the difference

Fixing that starts with knowing what you are actually writing, because three terms get used as if they were the same thing. They are not. A standard operating procedure prescribes how one task is done, process documentation describes how a wider workflow fits together, and a knowledge base stores the reference answers people look up when they need a fact rather than a method.

Keep the three apart and each earns its keep: prescribe the task in an SOP, describe the shape of the work in your process documentation, and let reference knowledge live in your knowledge base. One more term worth placing: a work instruction is the finer detail inside an SOP, covering how to perform a single step, where the SOP prescribes the whole task.

How to write an SOP people actually follow

Knowing what to write is one thing; knowing where to start is another. Do not try to document everything at once. Choose your first SOPs by frequency, pain and risk: how often the task runs, how much it hurts when it goes wrong, and what it costs if a step gets skipped. The boring, high-frequency jobs usually win, and they free up the most time once written. You do not need fifty of them either. Most teams get the bulk of the value from their first ten SOPs, because a handful of tasks account for most of the repetition.

Match the format to the shape of the task. A simple linear job wants a checklist or numbered steps. Work that branches, where the next step depends on an earlier answer, reads far more clearly once you map the workflow first and draw it as a flowchart. Anything that happens on screen is often quickest to capture as a short screen recording.

The anatomy of an SOP: a template you can copy

Whatever format you choose, the same skeleton sits underneath it. A usable SOP template has six fields, and getting all six onto the page matters more than any clever layout. Most templates you find online hand you three of them: a title, a list of steps, and a date. The three they leave out are the trigger, the exceptions and the done-criteria, and that is exactly where a real procedure lives.

Finish every SOP with three housekeeping lines: a version number, a last-reviewed date, and the name of whoever approved it. Those tell anyone opening the document whether they can trust what is in front of them.

One worked example of standard operating procedures, start to finish

The template in the previous section gives you six empty fields. Here is what they look like filled in, for a task nearly every business runs: processing a customer refund. This is the example most SOP guides promise and never actually finish, because the interesting part is what happens when the standard path breaks.

Purpose: refund a customer for a returned item correctly and consistently, so every return is handled the same way whoever picks it up.

Trigger: a customer requests a return or a refund.

Owner: the Customer Service Lead, who keeps this procedure current as the returns policy or the payment system changes.

The steps are the ordinary happy path, the version that covers most returns:

1. Verify the order against the customer's reference or email.
2. Check eligibility: within the returns window, and the item in resaleable condition.
3. Authorise the refund.
4. Reverse the payment through the original method.
5. Adjust stock to put the returned item back into inventory.
6. Email the customer to confirm the refund and the amount.
7. Log the return against the order.

Most returns end there. The exceptions are where a real procedure earns its place, because they tell whoever is covering the desk exactly what to do when that path does not apply:

The last two exceptions are about proof and fault, and they decide whether money should move at all.

The done-criteria remove any doubt about whether the task is actually finished:

Keeping SOPs alive, or they rot

Writing the SOP is not the end of the job. Standard operating procedures drift as the work changes: a supplier switches, a screen gets redesigned, a returns rule tightens, and the written version quietly falls behind what people actually do. The real danger is not an out-of-date document sitting unread. It is one that still looks current, so people follow it straight into the wrong thing.

There is a simple way to check whether a procedure still matches reality. Hand it to someone who has never done the task, the way a clean handover would, and watch what happens.

The mechanics that prevent drift are light: give every SOP one named owner, a review date, and a version number, and retire the ones that describe work you no longer do, so the library stays worth trusting. A sensible cadence for a team of five to fifty people is to review high-frequency SOPs every six months, the rest once a year, and any SOP the moment its task changes. Each review is ten minutes of reading the page against how the task is actually done today, then bumping the version number and the last-reviewed date. Getting the team to use them is partly habit and partly design. Habit you build by keeping procedures where people already work, and the most reliable design is to stop relying on memory at all, which is where software comes in.

SOP software, honestly (and the version you cannot skip)

Here is the honest version, because most writing about SOP software is really selling a particular tool. For the majority of small businesses, a shared document in one agreed place does the job: Google Docs, Notion, Confluence or SharePoint, whichever the team already opens. Capture tools like Scribe, Tango and Loom speed the writing up by recording your screen as you work, and dedicated SOP tools exist as a category, but neither is a requirement. Software only starts to earn its place when the shape of the problem changes, which the three tiers below lay out.

That last row is the durable version, and it is where an operations page stops being about documents. When you build the procedure into the software itself, the system walks the person through the task in order and will not let them skip a step, so it runs the same way whoever happens to be at the desk. Documentation relies on discipline; encoding removes the need for it. That is the difference between an SOP you hope people follow and one they cannot get wrong, and it is the version we build. We have built systems that work this way since 2005: quoting, client onboarding, order fulfilment, each with its procedure carried in the software rather than in a document beside it.

Start with one page

A standard operating procedure is how the business remembers how it works: one owned, current page for a single repeating task. Start with the high-frequency, high-pain jobs, let the doer draft and the owner approve, and fill in the exceptions and done-criteria most templates skip. Give each an owner and a review date, or retire it. Starting is cheap: one page is enough to begin.