How to Write an SOP: A Step-by-Step Guide With Examples

To write an SOP, pick one task with a clear start and finish, watch the person who does it best, and capture their sequence as numbered steps — one action per step, warnings before the step they apply to, written at the reader's real skill level. Then have someone who has never done the task follow the draft while you watch, fix every point where they hesitate, and publish it with a version number and an owner. That test-and-fix loop is what separates a standard operating procedure people follow from a document that decorates a shared drive.

Step 1: Scope one task, not a department

Most bad SOPs die at conception, by trying to cover too much. "Kitchen operations" is not an SOP; "Weekly deep-clean of the fryer" is. A well-scoped SOP has a trigger ("every Sunday after close", "when a delivery arrives"), a defined end state ("fryer reassembled, test-heated, logged"), and a single role performing it.

If you catch yourself writing "depending on the situation…" more than once, you are probably writing two procedures. Split them.

Step 2: Write it with the person who does the work

The manager knows what should happen. The person on the line knows what actually happens — the pan that sticks, the valve you must open before the other one, the step everyone quietly skips because it is impossible as written. An SOP drafted at a desk and imposed downward gets corrected in the margins or ignored.

The practical method: stand next to your best performer while they do the task at normal speed. Note every action, every tool, every decision point. Ask "why" at each step that looks optional — some are habit, some are load-bearing. Then draft from those notes and read it back to them.

Step 3: Choose the format the task deserves

Not every procedure wants the same shape. Three formats cover almost everything:

Default to simple numbered steps. Use hierarchy only when a step genuinely needs sub-steps, and a decision format only when the branches are real. Complexity in the format should mirror complexity in the task, never exceed it.

Step 4: Draft with one action per step

The mechanics that make instructions followable:

• Start each step with a verb. "Drain the oil", not "The oil should be drained".
• One action per numbered step. If a step contains "and", look hard at whether it is two steps.
• Put warnings before the action, not after. "WARNING: oil may still exceed 80°C (176°F). Wear heat-resistant gloves. 4. Open the drain valve." A caution that arrives after the burn is documentation, not protection.
• Name things exactly. "The red sanitiser bucket", not "appropriate cleaning solution". Precision here is what makes the SOP transferable between people and sites.
• State the end condition. The last step should describe what "done" looks like, so the reader can self-verify.
• Write for the real reader. If your team's shared language is simple English, write simple English. An SOP nobody can comfortably read is a liability with a signature line.

Step 5: A worked skeleton you can copy

Here is the structure, filled in briefly for a fryer clean:

1. Title and ID: Weekly Fryer Deep-Clean — KIT-SOP-04, v2.1.
2. Purpose: Prevent oil degradation, off-flavours, and fire risk.
3. Who and when: Closing kitchen team member; every Sunday after close.
4. Materials: Heat-resistant gloves, goggles, drain trolley, fryer cleaner, filter papers.
5. Steps: Switch off and unplug fryer. Allow oil to cool below 60°C (140°F). Position drain trolley. WARNING: check trolley valve is closed before draining. Open drain valve fully… (and so on, one verb per line, to the end state: "fryer reassembled, filled, test-heated to operating temperature, result logged").
6. Records: Where completion is logged and what evidence is kept.
7. Owner and review date: Kitchen manager; review every 12 months or after any incident.

Every SOP you write can use this seven-part skeleton, whatever the task.

Step 6: Test it on someone who has never done the task

This is the step almost everyone skips, and it is the one that matters most. Hand the draft to a competent person unfamiliar with the task and watch them follow it — silently. Every hesitation, every "wait, which valve?", every glance at you for reassurance is a defect in the document, not in the person. Fix the text, not the reader. Two rounds of this usually turn a plausible draft into a usable procedure.

Step 7: Publish with a version, an owner, and a review date

An SOP without an owner is an orphan; an SOP without a version number breeds arguments about which copy is current. Give each document an ID, a version, a named owner, and a review interval. Keep superseded versions retrievable — when an incident investigation asks "what was the procedure at the time?", you need the answer. And whenever the process changes on the floor, the document changes the same week, or the floor stops trusting the documents.

Pair the SOP with a checklist

An SOP is a teaching and reference document; nobody re-reads two pages mid-shift. Execution needs a companion checklist: the five to ten critical verifications extracted from the SOP, run every time the task happens. The SOP lives in training and on the shelf; the checklist lives in the workflow. The division of labour between them — and when you only need one — is covered in SOP vs checklist, and the craft of writing the checklist side well is in checklist design best practices.

This pairing is also your enforcement mechanism. You cannot verify that someone followed an SOP by asking; you can verify that the checklist derived from it was completed, on time, with the required photo evidence.

Common failure modes, briefly

• The novel. Ten pages, written to impress an auditor, read by no one. Cut until it hurts.
• The desk fantasy. Written without watching the work; contains a step that is physically impossible at station three.
• The orphan. No owner, no review date, quietly wrong within a year.
• The secret. Stored where frontline staff cannot reach it. An SOP locked in a manager's drive does not exist operationally.
• The unenforced ideal. Published, trained once, never verified. Without a recurring checklist attached, drift is guaranteed.

Making the execution layer digital

Writing the SOP is half the job; knowing it is followed at every site is the other half. Task10x handles that second half: the verification checklist derived from an SOP becomes a scheduled digital checklist per location and role, with pass/fail items, required photos, and numeric limits where readings matter. Template version history keeps a record of what the standard was at any point in time, and missed or failed checks surface on a live dashboard the same day instead of at the next site visit.