How to write an SOP (Standard Operating Procedure)

Updated 2026-07-11 · reading time ~5 min

Definition A Standard Operating Procedure (SOP) is a controlled document that describes, step by step, how to perform a repeatable task the same way every time. A good SOP lets a person who has never done the task complete it correctly by following the written steps.

Most SOPs fail for the same reason: they are a wall of prose that assumes the reader already knows the job. A useful SOP is structured, numbered, and assigns every step to a role. Below is the 7-part structure we use, and how to write each part.

The 7 sections every SOP needs

Purpose and Scope — why the procedure exists, who it applies to, and what is explicitly out of scope.
Roles and Responsibilities — each role that touches the process and what they own. For higher-stakes processes, add a RACI map (Responsible, Accountable, Consulted, Informed).
Prerequisites and Required Tools — the access, approvals, inputs, and systems needed before starting.
Procedure — the ordered, numbered steps. This is the heart of the SOP.
Exceptions and Edge Cases — what to do when the normal path breaks, and who to escalate to.
Quality Checklist — a short checklist to confirm the task was done correctly before it is closed out.
Revision History — version, date, and what changed, so the document stays controlled.

How to write the Procedure steps

The Procedure section is where most SOPs go wrong. Follow three rules:

One action per step. If a step contains the word "and," it is probably two steps.
Name the owner. Every step should say which role performs it — "the shift lead," "the IT admin" — not a vague "you."
Estimate the time. A rough time per step tells a new hire whether they are on track and helps you spot bottlenecks.

Write in the imperative ("Open the ticket queue," not "The ticket queue should be opened"). Call out decision points explicitly: "If the refund is over $200, escalate to the finance lead."

Common mistakes to avoid

Fake precision. Do not invent regulation numbers or statistics. If a step depends on a policy, refer to it generically and flag it for the owner to fill in.
No scope boundary. If you do not say what is out of scope, the SOP quietly grows until no one follows it.
No owner. A step with no responsible role will be skipped.
Never revised. An SOP that is never updated becomes fiction. Keep the revision history alive.

Generate a full 7-section SOP from a description →Preview free · one-time from $19 · no subscription

FAQ

How long should an SOP be?

As long as it needs to be and no longer. Most single-process SOPs fit on one to three pages. If it is longer, the process is probably several SOPs.

What is the difference between an SOP and a policy?

A policy states what must be true and why; an SOP states exactly how to do it. A policy says "refunds over $200 need approval." The SOP says who approves them and how.

Do I need a RACI in every SOP?

No. Add a RACI when a process crosses several roles or is audited. For a simple single-owner task, the Roles section is enough.