How to write an SOP

A Standard Operating Procedure, or SOP, is a written description of how to perform a recurring activity. A useful SOP does more than satisfy an auditor. It makes execution less dependent on one person, shortens onboarding, reduces avoidable variation and creates a stable base for improvement.

What this guide is for

This guide helps an SME write SOPs that people actually use. That is the only meaningful criterion.

Most company SOPs are written for certification, quality archives or compliance folders. They live far from the work. A useful SOP is different: it is a working tool. It sits where the activity is performed, uses the language of execution and helps a person complete the work without guessing the intent.

When to use it

Use an SOP when a recurring activity produces different results depending on who performs it.

Use it when onboarding depends entirely on shadowing the person who already knows.

Use it when rework repeatedly comes from avoidable omissions.

Use it when critical know-how lives in one person’s head and needs to become transferable.

Use it after stabilising an improvement. The SOP prevents the process from sliding back into old habits.

Do not use an SOP for low-frequency, high-variability activities where expert judgement is the real control. In those cases, principles and training matter more than procedure. Also do not treat an SOP as a substitute for training. It transfers what can be codified; tacit knowledge still requires practice and supervision.

Before starting

Three conditions matter.

First, choose the right activity: recurring, performed by more than one person now or in the future, and costly when variation appears. Start where the pain is highest.

Second, decide who writes it. The correct answer is not the quality office and not only the manager. The person who performs the activity must write it or dictate it, with facilitation. A SOP written away from the workplace usually describes the nominal process, not the real one.

Third, fix the format before writing. One or two pages maximum per activity. Imperative verbs. One step per line. Photos or screenshots where an image replaces ten lines.

Operational sequence

Step 1 — Observe the real execution twice.

Before writing, watch the activity performed by two different people, or by the same person at two different times. Write down the steps as they occur. Differences between the two executions are the first discovery: they are the variation the SOP must reduce.

Step 2 — Write the step sequence with the performer.

Run a one-hour session where the work happens. The performer describes the steps; the facilitator writes them using imperative verbs: check, enter, attach, verify, stop, escalate. A step deserves a line if it can be done wrong. If one line hides three possible errors, split it into three steps.

Step 3 — Mark critical points, not everything.

A useful SOP is not flat. It highlights the three to five points where error is expensive: the field that creates downstream rework if wrong, the check that cannot be skipped, the condition that requires escalation. For each critical point, write why it matters.

Step 4 — Define the expected output.

At the end of the SOP, describe what “done well” looks like: completeness criteria, final check, required evidence, acceptable variation and escalation condition. This turns the SOP into a personal quality gate before the work moves downstream.

Step 5 — Test it on someone who does not know the activity.

Ask someone unfamiliar with the activity to perform it using only the SOP, while the author observes without explaining. Every hesitation, question or error is a defect in the text, not in the person. Correct the SOP and repeat if needed.

Step 6 — Publish it where the work happens and name an owner.

The SOP must live at the point of use: printed near the activity, linked inside the tool, pinned in the shared folder or attached to the relevant form. It also needs an owner. The owner updates it when the process changes and reviews it periodically with the people who use it.

Expected output

The expected output is one or two pages for one activity: title, purpose in one line, numbered imperative steps, critical points with reasons, expected output, owner and last review date.

The observable test is simple: within a few weeks, people consult it. If nobody does, the SOP is wrong, too far from the work, or the activity was the wrong one to standardise.

Mistakes to avoid

Do not write the SOP away from the work.

Do not document everything. Proliferation creates archives, not standards.

Do not use uniform detail. Critical steps must stand out.

Do not write in quality-manual language when the user needs operating language.

Do not skip testing on a non-expert.

Do not leave the SOP without an owner. Orphan SOPs age silently and lose authority.

Example

A 28-person technical installation company has a recurring problem at job start. Site surveys are performed by four technicians, and the information returned is inconsistent. Around 30% of jobs require a second survey or create surprises later.

The SOP is written in two hours with the two most experienced technicians. It contains 14 steps, four of them marked critical: measure access points, attach required photos, check access constraints, and confirm one recurring ambiguous requirement with the customer contact.

Each critical step includes the reason. The SOP is tested on the youngest technician. Three hesitations become three corrections to the text. The final version becomes a checklist and a digital form. The technical manager is the owner, with periodic review.

After six months, second surveys fall from 30% to 8%. Onboarding time for the next technician is cut in half because the company finally has something to hand over besides informal shadowing.

MARTRO connection

In MARTRO’s reading, the SOP is where legibility becomes material. Process mapping makes the flow visible. The SOP stabilises the critical steps inside that flow.

Its value depends on fidelity to reality. Many companies have “standards” that exist only in certification documents. The gap between archived procedure and real work is one of the typical gaps between what the company believes it does and what it actually does.

Next step

If SOPs exist but outcomes still vary, the problem may be upstream: nominal process vs real process, process mapping or rework.

If the goal is to make concentrated knowledge transferable, the SOP is only one part of the work. The broader concept is organisational capability.

If the activity is still unstable, stabilise before standardising. If software is being considered to enforce the routine, first assess whether the ERP or tool is premature.

Frequently asked questions

How long should an SOP be? One or two pages for one activity. If it is longer, it is probably covering too much scope or mixing procedure with training material.

Who should write the SOP? The person who performs the activity, supported by someone who can structure the text. SOPs written far from the work usually describe the nominal process.

Should the SOP include every detail? No. Include steps that can be done wrong and critical points where error is costly. Excess detail hides what matters.

How do we know if the SOP works? Test it on someone who does not already know the activity. If they hesitate, the SOP needs revision.

How often should SOPs be updated? Whenever the process changes, and at least through a light periodic review with users. A stale SOP damages trust in all procedures.