The way to write a standard operating procedure is to interview the person who does the work, pick a granularity, draft the steps in imperative voice, and pressure-test the exceptions before you let the document out the door. The Microsoft Style Guide formalizes most of the drafting rules. Software documentation teams worldwide use it. ISO 9001:2015 §7.5 and FDA 21 CFR 211.100 set the compliance floor for regulated industries. Everything else is craft.
Most "how to write an SOP" articles list the same 7 admin steps and call it done: identify the process, gather stakeholders, outline, draft, review, approve, maintain. That is a table of contents, not a writing guide. None of it tells you how to get the knowledge out of the operator's head. Or how to put it on the page. The next operator has to run it without calling for help.
This guide walks through the writing craft. The interview techniques. The granularity calls. The format choices. How to handle exceptions in prose without drawing a flowchart in your sentences. How to run a review cycle that produces a document people will actually follow.
What an SOP is and is not
A standard operating procedure documents the agreed way a recurring activity is performed by a qualified role, so that any qualified person can produce a consistent outcome. ISO 9001:2015 replaced the older term "documented procedure" with "documented information" in clause 7.5. Organizations got latitude on format. The underlying job did not change. The job is to make tacit knowledge transferable.
An SOP is not a policy. It is not a process map. It is not a work instruction down to the keystroke. Each artifact has a different audience and a different shelf life. Confusing them is one of the most common reasons SOP libraries rot.
| Artifact | Scope | Audience | Format | Authority |
|---|---|---|---|---|
| Policy | Organization-wide rules and intent | All staff, auditors | Short prose, signed | Approved by leadership |
| SOP | One recurring activity, one role | Qualified practitioner of that role | Numbered steps with context | Approved by process owner |
| Work instruction | One task within an SOP, one operator | Operator at the workstation | Granular steps, photos, tolerances | Approved by SOP owner |
| Process map | End-to-end flow across roles | Managers, auditors, new hires orienting | Flowchart or swimlane | Approved by process owner |
Vocabulary here follows ISO 9000:2015 conventions and decades of consistent practice in regulated industries. Write a document that is 60 percent prose explanation and you have written a policy. Document individual button clicks on equipment and you have written a work instruction. Keep them as separate documents. Link between them.
For a deeper definition and history, see our companion piece on what is a standard operating procedure?.
The SME interview
The single biggest determinant of SOP quality is whether you actually watched someone do the work. A writer drafting from a wiki page and a Slack thread produces a document that passes review. It then fails the first time a new hire opens it. The missing piece is tacit knowledge. Tacit knowledge is what the SME does automatically and never thinks to mention.
Schedule 45 to 60 minutes. Ask to record audio. If the work is physical, schedule the interview at the workstation, not in a conference room. If the work is software, share screen and have the SME execute a real instance while you watch.
Bring these 10 questions and ask them in order:
- Walk me through the last time you ran this process end to end. Start from the moment you knew it needed to happen.
- What triggers this procedure? How do you know it is time to start?
- Who else is involved, and at what points do you hand off or wait for them?
- What does success look like? How do you know the output is good?
- Where do people new to this role get stuck on their first 2 or 3 attempts?
- Tell me about the last time this went wrong. What happened, and what did you do?
- Are there variations you handle differently depending on context? Which contexts, and what changes?
- What tools, accounts, or permissions do I need before I start?
- What is the cost of doing this badly? Is the failure visible immediately or does it surface later?
- If I shadowed you doing this once a week for a month, what would I see you do that is not written down anywhere?
Question 6 and question 10 do the heavy lifting. They surface the exceptions and the tacit moves. A SME asked "what are the steps" recites a sanitized procedure. A SME asked "what happened the last time it went wrong" hands you the failure modes. Those belong in the SOP as warnings, branch points, or prerequisites.
Record. Transcribe. Highlight any sentence where the SME says "usually," "most of the time," "unless," or "except when." Those are branch points you must resolve in the draft.
Granularity - how detailed is detailed enough
Granularity is the call that separates good SOPs from bad ones, and it gets almost no airtime in the standard advice. The right granularity depends on the expertise of the reader and the cost of a missed detail.
A useful heuristic: write at the granularity where the next operator can succeed without asking a question. Not one level finer. Over-specifying is not safer. It produces documents readers skim, then ignore. That is worse than no document at all.
| Reader expertise | Step granularity | Approximate length | Example |
|---|---|---|---|
| Novice, first exposure | Each click, each container, each sensory check | 15 to 30 substantive steps, with photos | New hire reagent prep in a lab |
| Practitioner, knows the tools | Each decision point and non-obvious action | 5 to 12 steps with brief context | Releasing a software hotfix |
| Expert, knows the process variations | Narrative with explicit branch points | 1 to 2 pages of prose with a checklist | Incident response triage |
If your draft exceeds 12 substantive steps for a practitioner audience, split the SOP. The split falls along natural boundaries: a setup procedure, an execution procedure, and a teardown procedure. Give each one its own document and a parent process map showing the order. Splitting pays off when one phase changes. You republish one SOP, not the monolith.
If the procedure is simple enough that a 5-line checklist would do, write the checklist. An SOP is overhead. Spend it only where the cost of variance justifies it.
Choosing a format
The format question is usually framed as "step-by-step versus hierarchical versus flowchart versus checklist." That framing hides the real decision. The decision is whether the reader is executing or deciding. Match the format to that.
- Numbered imperative steps when the reader is executing a defined sequence. This is the default for production work, lab procedures, deployment runbooks, and onboarding tasks.
- Narrative paragraphs with embedded callouts when the reader is making decisions and needs context. Incident response, judgment calls in customer support, editorial review processes.
- Tables for parameter sets (values, tolerances, equipment settings) that the reader scans rather than reads.
- Photos and screenshots where the image is faster than a sentence. A photo of correctly seated equipment beats three paragraphs describing the click and the seat.
The Microsoft Style Guide is the cleanest published reference on numbered-step formatting. Its rules generalize beyond software. One action per step. Complete sentences starting with an imperative verb. State the location before the action. Do not overwhelm the reader with more than 10 steps in one procedure. Cap a single numbered procedure at 7 to 9 steps. Past that, reach for a sub-procedure or a heading break.
Drafting
Three rules carry most of the load.
Imperative voice, one action per step. "Open the valve" not "the valve should be opened" and not "open the valve and then check the pressure gauge and record the reading." If a step has more than one verb, it is more than one step.
Preconditions go up top. A block at the start of the SOP lists what the reader needs before step 1: tools, permissions, materials, completed prerequisite procedures. This is where the answer to interview question 8 goes. Bury a precondition inside step 4 and readers arrive at step 4 with the wrong tool.
Acceptance criteria go at the end of each step or at the end of the procedure. The reader needs to know what success looks like. "Verify the pressure reading is between 40 and 45 psi" is an acceptance criterion. "Adjust as needed" is not.
For voice and tense, default to second person present: "Run the report" not "the operator runs the report" and not "the operator will run the report." Passive voice is acceptable only when the actor is genuinely unknown. "Samples are routed to the lab" is fine if anyone in the chain could route them. "The valve is opened" is not. Somebody opens that valve. The reader needs to know it is them.
Exceptions and branching, in prose
The hardest part of writing an SOP is handling the cases that break the happy path. Three patterns work. One pattern does not.
The patterns that work:
- If/then callouts inline. After a step, drop a short conditional in a visually distinct block. "If the device does not appear in the list within 30 seconds, restart the discovery service and return to step 3." Keep the condition first and the action second so a skimming reader sees the trigger before the response.
- Exception sub-steps. When a step has 2 to 4 variants, use sub-steps "3a. If the customer is on the legacy plan, route to billing. 3b. If the customer is on the current plan, route to support. 3c. If the customer is unauthenticated, request verification before either route." This works up to 4 branches. Past that, you need a separate decision aid.
- Pre-condition lists. When the procedure has 2 distinct entry conditions that lead to fundamentally different paths, do not write one SOP with a fork in it. Write two SOPs that share components and link to a parent map.
The pattern that does not work is a prose flowchart. "Check the gauge. If it reads above 50, then check the secondary valve, but if that valve is also above 50, you should escalate, unless it is between 4 PM and 8 PM in which case page the on-call." Readers cannot execute this. They give up and call the SME. That is exactly the situation the SOP was supposed to prevent.
If your branching logic exceeds 4 conditions or 3 levels of nesting, pull the decision out. It belongs in a separate decision aid: a small table, a real flowchart, or a runbook. Have the SOP reference it. This is also the natural use case for conditional content in a structured authoring system. One SOP source publishes role-specific or region-specific variants without forking the document.
The review cycle
A review that consists of "I emailed it to three people and two replied LGTM" is not a review. A useful review has three checkpoints and one mechanical step.
The three checkpoints:
- Process owner review. Confirms the procedure as written matches the agreed method. Owner has authority to require changes.
- Second operator read-aloud test. A qualified practitioner who did not write the SOP reads it out loud and executes it. Every place they hesitate, ask a question, or improvise is a defect. Fix it.
- Compliance or QA review where applicable. For regulated work, the quality unit signs off on the document and on changes. FDA 21 CFR 211.22 puts this responsibility on the quality control unit for pharmaceutical manufacturing.
The mechanical step is recording who reviewed, when, and what they changed. Without that record you cannot prove the SOP was current at the time of an incident. Proving exactly that is why regulators require written procedures.
Review cadence should be keyed to risk tier:
| Risk tier | Example | Review cadence | Off-cycle triggers |
|---|---|---|---|
| High — safety, regulatory, financial control | Drug manufacturing batch release, financial close, clinical trial enrollment | Annual at minimum | Any incident, audit finding, equipment change, regulation update |
| Medium — operational with customer impact | Customer escalation handling, production deployment | Every 12 to 18 months | Tooling change, repeated failures, role redesign |
| Low — internal, low blast radius | Onboarding checklists, internal wiki maintenance | Every 18 to 24 months | Substantive complaints, organizational change |
For SME review specifically, getting an outside expert into a CMS account is real friction. Reviews get skipped over it. Token-based review links that work without login remove that friction. The SME clicks a URL and comments inline. Topicary supports this pattern. It has measurably lifted review completion rates in the teams we have watched adopt it.
Publish, version, and maintain
Stamp every SOP with effective date, version number, document owner, and review-due date. Distribute through a single system that can withdraw the prior version when a new one publishes. Email and file shares do not count. Readers keep the old PDF on their desktop. You will have no way to prove what was current.
Our SOP template sets out the standard sections in a form you can copy: purpose, scope, preconditions, procedure, exceptions, acceptance criteria, revision history. For domain-specific models, SOP examples by industry collects representative documents from healthcare, manufacturing, and software operations.
Common mistakes
The defects below appear in roughly half of the SOP libraries we have audited. Each pairs a representative bad pattern with a concrete fix.
- BAD: "Ensure the valve is in the open position." FIX: "Open the valve."
- BAD: "Run the migration script (note: this requires database admin access and a pre-approved change ticket and you must coordinate with the on-call DBA)." FIX: Move the requirements to a preconditions block at the top. The step is "Run the migration script."
- BAD: "Review the report and take appropriate action." FIX: Define appropriate. "If the variance exceeds 2 percent, file an incident report. Otherwise, file the report in the monthly archive."
- BAD: A 14-step numbered procedure with 3 branches inside step 7. FIX: Split at step 7. The first SOP ends with "Determine routing per the routing matrix." The branches become 3 short SOPs or rows in a decision table.
- BAD: "See Appendix C for exception handling." FIX: Put the exception inline as an If/then callout where it occurs. Appendices that hide branches are appendices nobody reads.
- BAD: "Reviewed by John, March 2023." FIX: "Reviewed by J. Park (Process Owner) and S. Liu (QA) on 2023-03-14. Next review due 2024-03-14." Names, roles, dates, and the next due date.
- BAD: An SOP that opens with 3 paragraphs of background on why the process exists. FIX: One sentence of purpose. The rest belongs in the policy document the SOP implements.
- BAD: Screenshots that show a UI from 2 versions ago. FIX: Either re-take on every UI change, or remove the screenshots and describe the action in words. Stale screenshots are worse than no screenshots. Readers trust them and act on the wrong information.
When an SOP is overkill
Not every recurring task earns an SOP. Writing, reviewing, approving, and maintaining a document costs real time. That time competes with the work itself. For a 5-person startup running a one-off vendor onboarding, a Notion checklist with the 6 steps is enough. Add a Slack channel for questions. For a 200-person manufacturing line, that same approach is malpractice.
The deciding factors are recurrence, cost of variance, and audit exposure. Say the task happens twice a year. Getting it wrong costs a half-day of rework, and no auditor will ever ask. Write a checklist and move on. Now say the task happens daily. A mistake costs a recalled batch or a regulatory finding, and an auditor will absolutely ask. You need a full SOP with a real review cycle.
A structured authoring system pays off for teams managing 50 or more SOPs. It pays off again when regulated and unregulated work sit side by side across product lines. You get shared components for common warnings and conditional content for role-specific variants. The procedure keeps a single source regardless of how it publishes. For background on when that level of tooling makes sense, see what is a CCMS?.
FAQ
How long should an SOP be?
It depends on the task's risk profile and the reader's expertise. A reagent-handling SOP for a lab tech can run 4 to 6 pages with photos. A reset-the-router SOP for a new hire might be 12 lines. The Microsoft Style Guide warns against overwhelming readers with more than 10 steps in a single procedure, and that holds outside software too. If a single SOP exceeds 2 screens, the granularity is wrong or the scope is two procedures glued together.
What is the difference between an SOP and a work instruction?
An SOP defines the agreed way a recurring activity is performed by a qualified role. A work instruction describes the granular task steps inside that activity, typically for one operator on one piece of equipment. ISO 9001:2015 dropped the word "procedure" in favor of "documented information," but the hierarchy still maps: policy sets direction, SOP sets the method, work instruction sets the keystrokes.
Do I need an SOP for everything?
No. Use an SOP when the task is recurring, the cost of variance is real, and a qualified person could still get it wrong without guidance. For a one-off task at a 5-person startup, a Notion checklist or runbook is sufficient. Regulators decide for you in regulated industries — FDA 21 CFR 211.100 requires written procedures for production and process control in pharmaceuticals, and there is no opting out.
On what schedule should I review an SOP?
Tie cadence to risk. A safety SOP in a regulated manufacturing line gets reviewed annually and re-approved on every equipment change. An internal onboarding SOP can survive 18 to 24 months between reviews if no one complains. Always trigger an off-cycle review on incident reports, audit findings, and any change to the underlying system the SOP describes.
Should an SOP use numbered steps or narrative paragraphs?
Numbered steps for any task where order matters and a reader will execute step by step. Narrative for decision-heavy work where the reader is choosing between paths and needs context to choose well. Mixing both is allowed and frequently correct — a numbered procedure with a short narrative preamble explaining when to run it.
Who should write the SOP — the SME or the technical writer?
Neither alone. A SME writing solo produces a document only they can read. A writer working from a wiki page produces a document that misses what only the SME knows. The working pattern is a writer interviewing the SME, drafting, then walking the draft back to the SME and a second operator for a read-aloud test.
Sources
- Microsoft. "Writing step-by-step instructions." Microsoft Style Guide, 2026. https://learn.microsoft.com/en-us/style-guide/procedures-instructions/writing-step-by-step-instructions
- U.S. Food and Drug Administration. "21 CFR 211.100 - Written procedures; deviations." Code of Federal Regulations, current edition. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211/subpart-F/section-211.100
- U.S. Food and Drug Administration. "21 CFR 211.67 - Equipment cleaning and maintenance." Code of Federal Regulations, current edition. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211/subpart-D/section-211.67
- International Organization for Standardization. "ISO 9001:2015 - Quality management systems — Requirements (Clause 7.5 Documented information)." 2015. https://www.iso.org/standard/62085.html
- International Organization for Standardization. "ISO 9000:2015 - Quality management systems — Fundamentals and vocabulary." 2015. https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:en