How to Write Standard Operating Procedures (SOPs): A Step-by-Step Guide

You have a process that works — but only when the right person runs it. The moment they’re on leave, someone new joins, or the work moves to another site, quality slips and the questions start. A standard operating procedure fixes that by turning “how we do this” into something anyone can pick up and repeat. This guide walks you through what belongs in an SOP, a seven-step process for writing one, and how to keep it accurate long after the first draft.

What is a standard operating procedure (SOP)?

A standard operating procedure is a documented set of step-by-step instructions that describes how to carry out a routine task the same way every time. Its job is to reduce variation between people, protect quality, and make training faster — so results depend on the process, not on who happens to be doing the work.

That single goal — consistency — is the test for every choice you make while writing. If a sentence doesn’t help a real person get the same result in real conditions, it doesn’t belong.

SOP vs. work instruction vs. policy

These three terms get used interchangeably, and mixing them up is the fastest way to write an SOP nobody can use.

• A policy says what the organization requires and why — the rule and its intent (for example, “all refunds over $500 require manager approval”).
• A standard operating procedure describes how a whole process gets done, end to end, and who does each part.
• A work instruction zooms in on a single task within that procedure — the granular “how” for one step (for example, the exact screens to click to issue the refund).

Keep them in separate documents and link between them. A procedure buried inside a policy, or a policy padded with click-by-click detail, ages badly and confuses readers.

What should an SOP include?

Most reliable SOPs share the same backbone. You don’t need every section for every task, but starting from a consistent structure means readers always know where to look:

1. Header — a clear, descriptive title, a document number, and a version. Identifying every document by title, date, and reference number is a baseline control expectation under quality standards like ISO 9001.
2. Purpose — one or two sentences on what the procedure achieves.
3. Scope — what the procedure covers, and just as importantly, what it does not.
4. Roles and responsibilities — who performs each part and who is accountable.
5. Definitions — any terms or acronyms a new reader wouldn’t know.
6. Materials or tools — systems, equipment, or access required before starting.
7. The procedure — the numbered steps themselves, the heart of the document.
8. Revision history and approval — who approved the current version, when it took effect, and what changed.

Name the author and the effective date on every SOP. When something goes wrong six months later, the first questions are always “which version was live?” and “who owns this?” — the header should answer both instantly.

How to write a standard operating procedure, step by step

Here’s a repeatable process you can apply to any SOP, from onboarding a new hire to closing the books at month-end.

1. Define the process and its boundaries

Name the exact process and where it starts and stops. “Handle customer refunds” is too broad; “Process a refund request in the billing tool” is a writable unit of work. A tight scope keeps the document short enough that people actually read it.

2. Gather the details from the people who do the work

Sit with the people who run the process today and watch them do it. They know the shortcuts, the exceptions, and the steps the manual forgets. This isn’t just for accuracy — as the practitioners who study SOP writing put it, “people support what they help create.” Involving the doers early is what turns a procedure from paperwork into something the team defends.

3. Choose the right format for the task

Match the format to the complexity of the work rather than defaulting to a wall of numbered steps:

• Simple steps — a plain numbered list, ideal for short, repetitive tasks with few decisions.
• Hierarchical steps — main steps with sub-steps underneath, so beginners get detail while experienced users can skim the top level.
• Flowchart — the right choice when the process branches on decisions (“if the order shipped, do X; if not, do Y”).

A five-step task doesn’t need a flowchart, and a decision-heavy approval process shouldn’t be forced into a flat list.

4. Write in plain, imperative language

Start each step with an action verb and keep sentences short: “Record the invoice number,” not “The invoice number should be recorded.” Imperative phrasing removes ambiguity about who acts and what they do.

Be deliberate about a handful of high-stakes words. In procedures, “must” is mandatory, “may” grants flexibility, and “should” is only a recommendation — so choose them on purpose. And cut vague qualifiers like “periodic,” “typical,” or “as needed”; they read fine but give no one a consistent instruction to follow.

5. Add visuals where words get heavy

A screenshot, photo, or diagram often replaces a paragraph. Visuals help people who learn by seeing and remove the guesswork from steps that are hard to describe in text. Add them at the exact step they clarify, not in an appendix readers never reach.

6. Test the draft with a fresh reader

Before you call it done, have two kinds of people review it. First, the practitioners who run the process — they catch missing steps and assumptions that don’t hold up. Then a fresh reader who has never done the task: ask them to follow the SOP exactly, step by step, and note wherever they hesitate. Every hesitation is a gap to fix. Testing with someone unfamiliar is the single most reliable way to find the holes you’re too close to see.

7. Approve, publish, and put it under version control

An SOP isn’t live until the right authority has reviewed and approved it. Give it a version number, record who signed off and when, and publish it where the team already works — one findable location, not a file buried on someone’s drive. From here on, changes flow through the same review each time, so the approved version is always the one people see.

Standard operating procedures best practices

A few habits separate SOPs that get used from ones that gather dust:

• One process per document. If you’re tempted to write “and also,” it’s probably a second SOP.
• Explain the why, not just the how. People follow steps more reliably — and improvise more safely when reality doesn’t match the script — when they understand the reason behind them.
• Write for the least experienced person who’ll use it. Detailed enough to eliminate real variation, without micromanaging skilled staff.
• Set a review date. A procedure that’s silently gone out of date is worse than none, because people trust it. Give every SOP an owner and a review cadence.
• Keep one source of truth. Duplicated copies drift apart. There should be exactly one current version, and everyone should know where it lives.

Keep SOPs controlled, current, and auditable

Writing the SOP is the start; the harder part is keeping a growing library accurate as processes change. This is where documentation-management practice — and quality standards like ISO 9001 — draw a line between a document you can edit and a record that proves what happened. Controlled documentation needs to be identified by title, date, and owner; reviewed and approved before it goes live; protected from unintended changes; and traceable through a clear audit trail of who changed what, when.

Doing that in scattered files and email approvals doesn’t scale past a handful of procedures. A purpose-built documentation platform like Sonat is built for exactly this: draft in a familiar editor (or straight from Google Docs), route each change through an approval workflow so nothing publishes without sign-off, and rely on an unlimited version archive to see every past revision and restore any of them. Because everything lives in one single source of truth, your team reads the current, approved version every time — and when you operate across regions, machine translation turns one master SOP into consistent versions in the languages your sites actually use.

The bottom line

A good SOP isn’t a formality — it’s how a process survives the people who invented it. Keep the scope tight, write in plain imperative steps, build it with the people who do the work, and test it on someone who doesn’t. Then treat it as a living document: reviewed, approved, versioned, and kept in one place everyone trusts. Do that, and “the way we do things here” stops living in someone’s head and starts working for the whole team.

Ready to give your policies and procedures a controlled, auditable home? See how Sonat helps teams write, approve, and publish documentation.