How to Write an SOP: A 7-Step Method With a Copyable Outline

Writing standard operating procedures is one of those tasks that looks like a writing problem but is actually a knowledge-extraction problem. The hard part isn't formatting a document — it's getting an accurate procedure out of the head of the person who does the task, onto a page, in a form the next person will actually use.

This guide is the method: seven steps from scope to version control, a literal SOP outline you can copy, and the mistakes that turn SOPs into shelfware. If you'd rather start from a pre-built structure, the SOP template library has ready-made outlines for common procedures.

Before you write: the one-sentence test

Every SOP should be able to complete this sentence: "After following this document, a trained [role] will have [outcome], verified by [check]."

"After following this document, a trained line cook will have cooled the soup from 135°F to 70°F within 2 hours, verified by the logged thermometer reading."

If you can't complete the sentence, you don't know what you're documenting yet. If the sentence needs the word "and" three times, you're writing three SOPs.

How to write an SOP in 7 steps

Step 1: Define the scope — one task, defined edges

Pick a single task with a clear start and end. "Closing the kitchen" is a category; "cleaning and filtering the fryer at close" is an SOP. Write down explicitly what's out of scope, because scope creep is how a 1-page procedure becomes a 9-page manual nobody opens. A good scope statement fits in two sentences.

Step 2: Define the audience — and their day-one knowledge

Decide who this is for and what they already know. An SOP for a trained pharmacy technician can say "perform the rights check"; an SOP for a first-week retail hire has to spell out where the key is kept. Every writing decision downstream — vocabulary, step granularity, how many photos — flows from this. When in doubt, write for the newest qualified person who will ever perform the task unsupervised.

Step 3: Gather the knowledge from the person who does the task

This is the step most SOPs skip, and it's why most SOPs are fiction. Do not write the procedure from memory at a desk. Instead:

• Watch the task being performed by the person who does it best, and take timestamped notes.
• Ask them to narrate while doing it. The throwaway comments — "you have to jiggle this valve or it sticks" — are the most valuable content in the entire document.
• Ask the negative questions: What goes wrong here? What did the last new hire mess up? What would you never do?

The person who performs the task supplies the content. You supply the structure. An SOP written by a manager without observing the work gets identified as fiction by operators in about thirty seconds, and it takes the credibility of your whole documentation program down with it.

Step 4: Choose the SOP format

Match the format to the task, not to a corporate template:

• Step-by-step list — linear task, under ~10 steps, no decisions. (Fryer filtering, badge provisioning.)
• Hierarchical — long task where experienced staff need only top-level steps but new staff need sub-steps. (Equipment changeover, month-end close.)
• Flowchart — the task branches. If you're writing "if" more than twice, switch. (Incident triage, returns handling.)
• Checklist — verification rather than production; used during the task. (Opening/closing, pre-shift inspection.)

Step 5: Draft using a standard outline

Here's a complete SOP outline you can copy into any document. It's the same skeleton used across food service, manufacturing, and IT — trim what you don't need, but keep the header, procedure, and revision history no matter what:

# [Task Name] — SOP

**Document ID:** SOP-[DEPT]-[NUMBER]
**Version:** 1.0
**Effective date:** YYYY-MM-DD
**Approved by:** [Role, name]
**Review due:** YYYY-MM-DD

## 1. Purpose
One or two sentences: what this procedure accomplishes and why it exists.

## 2. Scope
What this SOP covers. What it explicitly does NOT cover.

## 3. Responsibilities
- [Role]: performs the procedure
- [Role]: verifies completion
- [Role]: owns and maintains this document

## 4. Materials & prerequisites
- Equipment, tools, PPE
- System access or credentials required
- Conditions that must be true before starting

## 5. Procedure
1. [One action per step. Start with a verb.]
2. [Include the acceptance criterion where it matters:
   "until the gauge reads 15–18 psi", not "until ready".]
3. [Flag safety-critical steps: ⚠ WARNING before the step,
   never after.]
...

## 6. What can go wrong
| Symptom | Likely cause | What to do |
|---------|--------------|------------|
|         |              |            |

## 7. References
Related SOPs, work instructions, regulations, or training videos.

## 8. Revision history
| Version | Date | Author | Change summary |
|---------|------|--------|----------------|
| 1.0     |      |        | Initial release |

Drafting rules that matter more than any template:

• One action per step. "Remove the filter and rinse it and inspect the gasket" is three steps wearing one number.
• Start every step with a verb. "Turn off," "Verify," "Record." Not "The operator should ensure that…"
• Put warnings before the step they protect. A warning after the step is an incident report.
• Write measurable endpoints. "Until clean" is an opinion; "until rinse water runs clear" is a criterion.
• Keep it short. If the procedure takes 90 seconds, the SOP shouldn't take 10 minutes to read. Aim for one page; two is the ceiling for a single task.

A worked example: five steps done right

Here's the difference the drafting rules make, using the opening of a fryer-filtering SOP. First, how these procedures usually get written:

One sentence, three actions, no criteria, warning buried mid-sentence. Now the same content written to standard:

Same knowledge, but now each line is checkable, the warning arrives before the danger, and a new hire can put a finger on exactly where they are in the procedure. Notice step 2 includes the typical wait time — that's the kind of detail you only get from step 3 of the method, watching the person who actually does the task. No manager writing from memory knows it's 45–60 minutes.

Step 6: Test it on a new hire

The draft isn't done until someone who has never performed the task completes it using only the document — no coaching, no gestures, the author standing silent with a notepad. Every hesitation, every "wait, which valve?", every step performed out of order is a defect in the document, not in the tester. Fix, then test again with a different person. Two clean runs and you're ready for approval.

This test takes 20 minutes and catches what no review meeting ever will. It is the single highest-leverage step in the whole process, and the one most often skipped.

Step 7: Approve, version, and schedule the review

Get a formal sign-off, assign the document ID and version 1.0, and — critically — put a review date on the document now (annual is the norm in regulated industries; two years is a sensible ceiling anywhere). Withdraw any older drafts floating around. From here, every change means a version bump, a line in the revision history, and retraining for anyone qualified on the old version.

Version control sounds bureaucratic until the first time someone follows a stale printout. The printed copy taped inside the cabinet from three revisions ago isn't a convenience; it's a defect.

Common mistakes when writing standard operating procedures

Writing from the office instead of the floor. Covered above, but it's the number-one cause of SOPs that don't match reality, so it bears repeating.

Documenting the ideal process instead of the real one. If the official process has a workaround everyone uses, either fix the process or document the workaround. An SOP describing a process nobody follows is audit bait.

Burying the procedure in preamble. If the steps start on page 3, nobody reaches them. Header, purpose, scope in half a page — then steps.

Vague quantities. "Some sanitizer," "a while," "regularly." Every vague quantity is a decision you've delegated to the least experienced person on the worst day.

No failure section. Real procedures go wrong. A short "what can go wrong" table turns a panicked new hire into someone following step 6b.

Writing it once and walking away. An SOP without a scheduled review decays silently. The process changes, the document doesn't, and compliant employees become the ones doing it wrong.

Perfectionism before publication. Teams sit on a 90%-accurate draft for months hunting for edge cases. Ship version 1.0, let the new-hire test and real use surface the gaps, and fix them in 1.1. A published imperfect SOP improves; an unpublished perfect one doesn't exist.

When to turn a written SOP into a video

Some procedures fight the written format no matter how well you draft them. Turn the SOP into a short video when:

• The task is physical and visual. Knife grip, patient transfer, pallet stacking — three sentences of description equal two seconds of footage.
• Correct and incorrect look similar in text. "Wipe in one direction" reads trivially; seeing it done wrong then right is what sticks.
• Your audience won't read. High-turnover, first-week, non-native-language staff consume a 20-second clip at rates a binder never sees.
• The same demo gets repeated live. If a shift lead demonstrates the same procedure to every new hire, that demonstration should be recorded once — as the standard, not as one person's version of it.

The pattern that works: keep the written SOP as the controlled document, and generate one 15–30 second clip per critical step for training. With Pellucida's SOP-to-video pipeline, you paste the SOP text, the AI plans a scene-by-scene storyboard, and you edit every scene prompt before anything renders — so the clip matches your procedure, not a generic version of it. The output is a finished MP4 with narration and subtitles, ready for the LMS or a looping break-room screen.

Start with a template, not a blank page

The fastest way to write your first SOP is to not start from zero: grab the matching outline from the SOP template library, spend your effort on steps 3 and 6 (knowledge capture and the new-hire test — the two steps that determine whether the document is true), and ship version 1.0 this week. A short, accurate, tested SOP beats a comprehensive one that never leaves draft.