Sop templates: what belongs in each section

There are two audiences for a standard operating procedure and they want opposite documents. An auditor wants completeness, cross-references, and evidence of control. The person doing the task at seven in the morning with a queue building wants the next action, in order, with nothing in the way.

Write for the second reader. An SOP that the auditor likes and the operator ignores has failed at the only thing it was for. An SOP the operator actually follows will satisfy the auditor, because the evidence of control is that the work is done the same way every time.

Everything below is built around that choice.

What to take away

Before you write: is a procedure the right answer?

Not every problem is a documentation problem. A written SOP is worth the effort when more than one person repeats the task and when doing it differently gives a materially different result. The cost of getting it wrong must exceed the cost of maintaining it.

Long-running procedure systems separate the controlling structure from the individual documents for this reason. That is how the Environmental Protection Agency's quality system documents are arranged.

It is the wrong tool when the task is genuinely judgment-heavy: writing a procedure for something that needs thinking produces a document people follow into the wrong outcome. Pricing a job is the standard example, and the reasoning behind it lives in quotes and estimates rather than in any sequence of steps.

It is also the wrong tool when the real problem is that the task should not exist, or that the system makes the wrong thing easy. Fixing the form is usually cheaper than writing a procedure that tells people to fill it in correctly.

The skeleton

<figure class="inline-figure">
  <img src="/inline/sop-templates-fig1-1280.webp" alt="Diagram of SOP template sections from header through steps to handoff (Sop templates: what belongs in each section)" loading="lazy" decoding="async" />
  <figcaption>The skeleton arranges every SOP into the same blocks, from the header down to the handoff. <a href="https://companyformtemplates.com/image-licence">Image: Company Form Templates</a></figcaption>
</figure>
[TASK NAME, a verb phrase: "Onboard a new supplier",
 not "Supplier Onboarding Procedure"]

Purpose        One sentence. What this achieves and why it matters.
Who does this  Role. Plus any qualification or access needed.
Trigger        The event that starts this. Be specific.
Frequency      How often, or "on trigger".
Time needed    Roughly, so people can plan.
Done looks like The observable end state.

BEFORE YOU START
  Access needed     [systems, permissions, keys]
  Materials needed  [forms, tools, information, equipment]
  Check first       [conditions that must be true, or stop]

STEPS
  1. [One action.]
     -> [What you should see. How you know it worked.]

  2. [One action.]
     -> [What you should see.]

  3. DECISION: [The question]
     If [condition A] -> go to step 4
     If [condition B] -> go to step 7
     If neither -> stop, see Exceptions

  4. [One action.]
     ...

IF SOMETHING GOES WRONG
  [Symptom]  ->  [What to do]  ->  [Who to tell]
  [Symptom]  ->  [What to do]  ->  [Who to tell]
  Anything not listed -> stop and contact [role]

WHEN YOU ARE FINISHED
  Record       [what to log, and where]
  Hand off     [who needs to know, and how]

Owner          [role]
Last verified  [date the procedure was last performed
                against this document]
Version        [n]

The header block is the part people read

Most SOPs are not read from the beginning. Somebody arrives at one already partway into a task, or picks it up to check one thing. The header has to let them work out in ten seconds whether this is the right document and whether they can do it.

Writing a step so it cannot be half-done

One action per step. The moment a step contains "and," it can be partially completed and nobody can tell. Split it.

Start with the verb. "Open the supplier record." Not "The supplier record should then be opened," which hides who acts. The federal plain language guidelines on word choice make the same argument about every kind of instruction.

Say where. Screen, menu, form, physical location. A step that assumes the reader already knows where they are is a step for someone who does not need the procedure.

Give a confirmation. After each meaningful action, say what the reader should now see. This is what separates a procedure from a list of intentions: it lets somebody notice they are off track at step 3 rather than at the end.

Make decisions explicit. Where the path branches, write it as a decision step with the question and every branch, including the branch where neither condition holds. Buried conditionals in the middle of a paragraph are how people end up in the wrong half of a process.

Include the negative instruction where it is earned. "Do not approve while the status is still pending" belongs in the procedure if somebody has ever done it. If nobody has, it is clutter.

Number the steps and never renumber silently. People refer to steps by number in conversation and in incident reports. When you insert a step, note the change in the log.

Watch out for steps that are really policy. "Ensure the request is appropriate" is not a step. Either give the test that makes it decidable, or route it to a person whose job is that judgment. Where the rule itself is what you are writing, it belongs in a policy document that the procedure points at.

The section that keeps the procedure honest

Most SOPs describe the path where everything works. Real work is mostly the other paths, and a document that covers only the clean run gets abandoned the first time something is unusual.

The "if something goes wrong" section does not need to be exhaustive. It needs three things:

Where a failure has a consequence (money moves, a customer is affected, something becomes unsafe), say so in the step rather than in a separate risk register nobody in the moment will consult.

Keeping it true

An SOP starts accurate and decays. The system gets an update, a team reorganizes, a workaround becomes the normal route, and the document stays where it was. The decay is invisible because people stop consulting a document they have learned is wrong, so nobody reports it.

Three habits that hold it together:

Verify by performing. At review time, someone follows the document exactly, doing the real task, and marks every point where the document and reality diverge. Reading it does not work: a reader fills in gaps from their own knowledge without noticing.

Let the person doing the work fix it. If changing an SOP requires a committee, the SOP will be wrong and the work will be right, and everybody will follow the work. Make small corrections easy and log them; reserve approval for changes that alter what the procedure achieves or who is accountable.

Log what changed, not that it changed. "Updated" tells a reader nothing. "Step 6 now requires the second approval before, not after, the transfer" tells them which of their habits is now wrong.

Set the review trigger to an event, not just a calendar date: a system change, a supplier change, a process incident, a new person struggling with it. Calendar reviews find nothing when nothing has moved and arrive too late when something has.

Testing a new procedure before you publish it

Hand it to someone who has never done the task, and watch them do it. Do not help. Do not explain. Write down every point where they hesitate, ask a question, or do something you did not intend.

Every hesitation is a defect in the document. This test takes an hour and finds more than any amount of review, because it measures the only thing that matters: whether the document works without its author standing there.

Two extra things to watch for: steps the tester performs in a different order than written, which usually means the written order is wrong, and steps they skip without consequence, which usually means the step is unnecessary.

Length

An SOP that runs long has usually absorbed material that belongs elsewhere: policy, background, justification, or a second procedure. Split those out.

The useful discipline is that the steps should fit on what the operator can see at once: a screen, a page, a laminated card. If they do not, the task is probably two tasks, and dividing it at the natural handoff produces two documents people will actually use.

Before you release it

Where a procedure ends in a document going out to a customer, the wording of that document is its own problem, and the invoices and receipts page covers the one most procedures end at. The covering note that carries it follows the rules in business letters.

Common questions