How to write a standard operating procedure

An SOP exists so that a task produces the same result regardless of who does it. The test is brutal and simple: hand it to someone who has never done the job and watch them try. Every place they hesitate is a defect in the document, not in them.

Most SOPs fail because they were written by the person who already knows the process, who therefore cannot see the twelve things they do automatically.

Before you write

Watch the task being done, or do it yourself while writing down every action including the ones that feel too obvious to mention. Where is the file kept? What is the login? What do you do when the field is greyed out?

Define the boundaries. Where does this procedure start and where does it stop? An SOP with fuzzy edges gets used for situations it was never designed for.

Identify who does it. The steps you write for a trained technician differ from those for a new starter.

The structure

Title and identifier. A number and a version, because you will revise this.

Purpose. One or two sentences: what this procedure achieves and why it matters. Include the consequence of getting it wrong — it changes how carefully people read.

Scope. What is covered and, explicitly, what is not.

Roles. Who performs it, who approves, who is notified.

Prerequisites. Access, permissions, equipment, materials, training, safety requirements. Everything needed before step 1.

The procedure. Numbered steps, one action each, in order.

Exceptions and troubleshooting. What to do when the expected thing does not happen. This is the section that separates a usable SOP from a decorative one.

Records. What must be logged, where, and for how long.

Revision history. Version, date, what changed, who approved.

Writing the steps

One action per step. If a step contains "and", consider splitting it.

Start with the verb, in the imperative. "Open the intake form." Not "the intake form should be opened" and not "you will need to open".

Be specific about the object. Not "click the button" but "click Submit for review at the bottom right".

Put the condition before the action. "If the total exceeds ₦500,000, route to the finance manager." A reader who meets the condition halfway through an action has to reread.

Say what success looks like. "The status changes to Pending approval." This lets someone confirm they are on track instead of continuing wrongly for six steps.

Warn before, not after. A caution about deleting data goes above the step, not below it.

Use a decision table or a short flow description when branching gets complex — nested "if" steps become unreadable at about three levels.

Keeping it usable

Short sentences. Plain words. Present tense. Consistent terminology — pick one name for each thing and never vary it, even when repetition feels clumsy. Synonyms are a virtue in prose and a defect in procedures.

Number steps so they can be cited in conversation and in incident reports. Keep screenshots to a minimum: they are useful and they go stale faster than any other element.

Testing it

Give it to someone who has not done the task, and watch without helping. Note every pause, question and wrong turn. That list is your revision.

This is not optional. An untested SOP is a draft, however carefully written.

Common mistakes

Assumed knowledge — the biggest one by far. No prerequisites section, so the reader gets three steps in before discovering they need access they do not have. No troubleshooting. Steps that combine several actions. Vague verbs like "process" and "handle". No version control, so three versions circulate. Writing it once and never revising it after the system changes. Screenshots of a UI that no longer exists.

Practical tips

• Write it while doing the task, not from memory.
• Read it aloud as instructions to an imaginary person; the gaps become audible.
• Put the version and date in the header of every page.
• Review on a schedule, not when someone complains.
• Store it where the work happens, not in a documents folder nobody opens.