How to write a standard operating procedure (SOP): a step-by-step guide

← Back to SOPs & Operational Excellence

What is the difference between an SOP, a checklist and a policy?

• A policy says what the organisation has decided and why — for example, "we respond to every complaint personally". It sets the rule.
• An SOP says how a task is done consistently: who does it, in what order, with what inputs and when to escalate. It puts the policy into practice.
• A checklist is a short memory aid used at the point of work to confirm critical items have been done. It often sits inside or alongside an SOP.

On a flight deck these layers are distinct: the operator's policies, the standard operating procedures and the checklists crews read aloud. That is aviation practice, not a structure every business must copy, but separating the three keeps each one short and clear.

How much detail should an SOP contain?

Enough for a competent person who is new to the task to do it correctly, and no more. If a step relies on judgement that only comes with experience, say what good judgement looks like and when to ask for help rather than trying to script every case. Background and rationale belong in a short purpose statement or a linked document, not between the steps.

Step 1: Which activity should you document first?

Choose using three tests: risk (what happens if it goes wrong), repetition (how often it is done) and variance (how differently people do it today). An activity that is high on two or more is a good candidate. I explain this prioritisation in more depth in how to introduce SOPs without creating unnecessary bureaucracy.

Step 2: What must the procedure achieve, and why?

Write one sentence for the objective and one for the promise or risk it protects. This is where Business DNA and Mission Alignment come in: the procedure should express what your organisation stands for, not someone else's template. If you are unsure what that means in practice, start with what Business DNA is and why procedures should be built around it.

Step 3: Who actually does the work today?

Talk to them — ideally watch them. Ask what they do first, what they check, where they get stuck and what workarounds they use. Workarounds are information, not misconduct. In my engagements this is the most important step: your people supply the expertise; I supply the structure.

Step 4: What can go wrong, and what are the exceptions?

List the realistic failure points and the situations the normal flow does not cover. For each, decide whether it needs a step, a warning, an escalation trigger or simply a note to ask a supervisor. This keeps the main flow short while making sure people are not left guessing.

Step 5: How should the steps be written?

• Number them in the order they happen.
• Start each with an imperative verb: "Record", "Confirm", "Send".
• One action per step; split compound steps.
• State precise inputs: which system, which form, which field.
• Mark the few critical steps clearly, so they stand out under pressure.

Step 6: Who is responsible, and when do you escalate?

Name the role responsible for each step, and state the decision rules: what the person may decide alone, what needs a second opinion and what must be escalated, to whom and how quickly. Clear escalation is what prevents a small problem being handled quietly until it becomes a large one.

Step 7: Does it work in a real scenario?

Ask someone who did not write the procedure to follow it on a real or realistic case while you watch silently. Every hesitation, question or improvisation is a fault in the draft. Fix it and test again.

Step 8: Does it serve your mission and meet your obligations?

Review the draft against the promise identified in step 2 and against your policies. Check any legal, regulatory, safety, data-protection or sector-specific requirements that apply to your organisation; these vary by industry and jurisdiction, and specialist advice should take precedence. Mission and vision never outrank safety, legal or ethical obligations.

Step 9: Who approves it, and how is it controlled?

A designated person in your business approves the procedure. I facilitate and structure documentation, but I do not approve clients' procedures. Record the owner, approver, version number, effective date and next review date, and keep one current approved version where everyone can find it. The roles are explained in who should create, approve and manage SOPs, and your Company Operations Hub keeps owners, versions and review dates visible.

Step 10: How do you communicate, train, monitor and improve?

Brief the people affected on what changed and why. Train on the critical steps using realistic scenarios. Then watch whether outcomes actually improve, not just whether the procedure has been read — how to measure operational excellence covers which signals to use. I support six-monthly training, refreshers and updates; material changes to critical procedures should be communicated immediately.

What does a finished SOP look like?

The following is a hypothetical example for illustration only. Names, roles, dates and time targets are invented; your own procedure should reflect your business, your customers and any obligations that apply to you.

Inputs: the complaint details, customer account record, order or job reference, and access to the complaints log.

1. Acknowledge the complaint and thank the customer. Illustrative target: within one working day.
2. Record the complaint in the complaints log with the customer name, reference, channel, date and a summary in the customer's words.
3. Classify the complaint as standard or escalated using the triggers below.
4. Investigate: review the account, the order or job history and speak to the colleagues involved.
5. Decide the resolution within your authority limits, or escalate.
6. Contact the customer personally to explain the outcome. Illustrative target: within five working days for standard complaints.
7. Confirm the outcome in writing and record it in the log.
8. Close the log entry and note any suspected procedure or process cause.

The time targets above are illustrative only; there is no universal correct response time. Set your own based on your customer promise and any obligations in your sector.

• Escalation triggers — refer to the Customer Service Manager the same day if the complaint involves a safety concern, a vulnerable customer, a potential legal claim, a refund above your authority limit, media or social-media attention, or a repeat complaint on the same issue.
• Evidence retained — the log entry, all correspondence, notes of calls and the final written outcome, kept in line with your record-retention policy.
• Exception handling — if the customer cannot be reached, make two further attempts on different days and record each; if the complaint falls outside scope, transfer it to the correct procedure and tell the customer.
• Review criteria — the owner reviews at each scheduled date, after any escalated complaint that revealed a gap, or when a related policy changes.

Is there a simple SOP template I can reuse?

Yes. Copy these fields into your own document and complete each one:

Before approving any draft, run this quick checklist:

• Could a competent new person follow it without asking?
• Does every step start with a verb and contain one action?
• Are escalation triggers specific?
• Has someone other than the author tested it?
• Is there a named owner, approver, version and review date?

Where does this fit in the wider approach?

Writing individual procedures is one part of the methodology: Business DNA, Mission Alignment, SOP Governance, AI SOP Captain and Continuous Improvement. If you would like help applying it to your organisation, you can book a discovery call.

Frequently asked questions

How long should an SOP be?

As short as it can be while still letting a competent new person do the task correctly. Many work well at one or two pages of steps, but length should follow the task, not a rule.

Who should write an SOP?

The people who do the work, supported by someone who can give it consistent structure. A designated person in your business then approves it.

Do you approve the procedures you help write?

No. I facilitate and structure documentation; approval and operating decisions always remain with your business.

Are there legal requirements for SOPs?

Some sectors have specific requirements and others do not. Check what applies to your industry and jurisdiction and take specialist advice where needed.

How often should an SOP be reviewed?

On a schedule proportionate to its risk, and immediately after any material change. I work on a six-monthly training and update cycle.

← Back to SOPs & Operational Excellence