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

You have a process that works. The problem is it only works when one specific person runs it. When they're on vacation, the result changes. When a new hire takes over, the result changes again. A standard operating procedure fixes that — it turns "the way Sara does it" into "the way we do it," every time.

This guide walks through how to write standard operating procedures that people actually follow: how to scope them, structure them, write the steps, test them with a real reader, and keep them current. By the end you'll have a repeatable method you can apply to any procedure in your organization.

What is a standard operating procedure?

A standard operating procedure (SOP) is a written set of step-by-step instructions for carrying out a routine task the same way every time. It captures who does what, in what order, with which tools, and to what standard — so the outcome doesn't depend on who happens to be doing the work.

SOPs matter most for tasks that are repeatable, that affect quality or safety, or that carry a compliance requirement. The payoff is consistency: standardized instructions produce uniform results, speed up onboarding, make responsibility clear, and create the documented evidence that audits and regulations expect. The stakes are real — research on reproducibility has found that fewer than a third of biomedical studies could be reproduced, much of it traced to unclear procedures and inconsistent practice. An SOP is the antidote to that drift.

A quick distinction worth holding onto: a policy says what the rule is and why; a procedure says how to carry it out. SOPs are the "how." They're the operational layer underneath your broader policies and procedures.

When should you write an SOP?

Not every task needs one, and over-documenting trivial work just creates pages nobody reads. Write an SOP when a task is:

• Repeated often — the more frequently it runs, the more a small inconsistency compounds.
• Critical to quality, safety, or compliance — where a wrong step has real consequences.
• Done by more than one person — or about to be handed to someone new.
• Hard to recover from if done wrong — irreversible or expensive to redo.

Before you start from scratch, check whether your team already has a template or an older version. Building on an existing structure keeps your documentation consistent and saves you reinventing a format.

Step 1: Plan the SOP before you write

Good SOPs are gathered, not invented. Start by defining the purpose (what this procedure achieves) and the scope (where it starts, where it ends, and what's deliberately out of bounds). A tight scope is what keeps an SOP from sprawling into a manual.

Then collect the raw material. Interview the people who actually do the task — not just the manager who owns it. Watch the work happen if you can. Note the tools, inputs, decision points, and the small "everyone just knows" details that never made it into writing. Those undocumented details are usually the whole reason the SOP is needed.

Finally, decide who's responsible: an author to draft it, qualified reviewers with real expertise to check it, and an approver with the authority to sign off. Naming these roles up front prevents the document from stalling later.

Step 2: Choose the right SOP format

There's no single correct layout — the best SOP format depends on how complex the task is. A useful rule of thumb based on the number of decisions and the number of steps:

• Simple steps — few decisions, few steps. A plain numbered list.
• Hierarchical steps — few decisions but many steps. Numbered steps with sub-steps (1, 1a, 1b) so detail nests without overwhelming.
• Flowchart — many decisions or branching paths. A diagram showing how the route changes based on conditions.

Match the format to the work, not to a house style. A ten-decision approval process forced into a flat checklist will confuse everyone; a three-step reset wrapped in a flowchart looks absurd.

Step 3: Write the steps clearly

This is where most SOPs live or die. A few principles that consistently separate procedures people follow from ones they ignore:

Use the imperative. Write commands, not descriptions. "Record the weight," not "The weight should be recorded." Commands tell the reader exactly what to do and remove ambiguity about who acts.

One instruction per step. Keep sentences short and put a single action in each numbered step. It's easier to follow, easier to check off, and easier to fix when something changes.

Be concrete and consistent. Use the same term for the same thing throughout — don't alternate between "the dashboard," "the console," and "the panel." Spell out anything that isn't universally known, and limit acronyms to ones your whole audience recognizes.

Balance the level of detail. Include enough that two different people produce the same result, but not so much that an experienced worker feels micromanaged into quitting the page. Aim for the detail a competent newcomer needs — no more.

Put safety where the hazard is. A common mistake is dumping all warnings into a "Safety" box at the end. Place each caution at the exact step where the risk occurs, so the reader sees it in the moment they need it.

Step 4: Structure the full document

The steps are the core, but a complete SOP wraps them in a little context so it's usable and traceable. Across established guidance, the standard elements are consistent:

• Title and identifier — a clear, descriptive title and a logical number for filing and tracking.
• Purpose and scope — what it covers and what it doesn't.
• Roles and responsibilities — who performs, reviews, and approves.
• Materials and tools — anything required to do the task.
• The procedure — the numbered steps themselves.
• Safety precautions — embedded in the steps, and summarized if needed.
• Definitions and references — terms, standards, and related documents.
• Approval and revision history — effective date, version, and a log of changes.

That revision history isn't bureaucratic filler. It's how a reader knows they're looking at the current version, and how an auditor confirms the procedure has been maintained.

Step 5: Test the SOP with a real reader

Here's the step almost everyone skips, and it's the most revealing one. Hand the draft to someone who has never done the task, and have them perform it using only the document — no hints, no "oh, you also need to…" from over their shoulder. Then watch where they hesitate, guess, or go wrong.

Every pause is a gap in your writing, not a failure of the reader. The people closest to a process are blind to their own assumptions; a fresh tester surfaces them instantly. This pilot run is your cheapest quality check, and skipping it is why so many "finished" SOPs generate questions the moment they go live.

Step 6: Review, approve, and publish

Once the draft survives testing, route it through review. Incorporate feedback from your subject-matter reviewers, get agreement from stakeholders, and secure formal approval from the person accountable for the work. Approval is what turns a helpful draft into the official way to do the task.

Then publish it where people will actually look — not buried in a shared drive three folders deep. An SOP only delivers value if the person doing the task can find the current version in seconds, on whatever device they're using.

This is exactly the kind of controlled, auditable workflow Sonat is built for. You can draft procedures in a familiar editor, route them through parallel or sequential approval workflows, keep an unlimited version history so any past revision can be restored, and publish to a fast, searchable, mobile-friendly site — all without technical setup. When the approved SOP and the published SOP are the same single source of truth, you stop emailing around stale copies.

Step 7: Keep SOPs current

An SOP is a living document, not a monument. Tools change, regulations evolve, and teams find better ways to work — and an out-of-date procedure is worse than none, because people stop trusting all of them.

Build maintenance in from the start:

• Assign an owner to each SOP who is responsible for its accuracy.
• Set a review cycle — at minimum once a year, sooner for high-risk or fast-changing work.
• Log every change in the revision history, and archive superseded versions so the current one is never ambiguous.

A predictable SOP review cycle is what keeps your library trustworthy over time, and version control makes the whole thing auditable instead of guesswork.

Conclusion

Writing a good SOP isn't about producing a long document — it's about capturing a process so faithfully that anyone can repeat it. Scope it tightly, gather the real details, write plain imperative steps, test it on a fresh reader, get it approved, publish it where people work, and review it on a schedule. Do that, and your procedures stop living in one person's head and start working for the whole team.

The hardest part is usually not the writing but keeping every version controlled, approved, and findable. If that's where your policies and procedures tend to break down, see how Sonat helps teams author, approve, and publish documentation that stays current.