Writing SOPs your team will actually follow

A standard operating procedure (SOP) is a written description of how a task is done in your business. Most businesses that try to write SOPs end up with a folder of long documents that nobody opens. The problem is rarely effort. It is usually format, location and ownership. This guide covers all three.

Which tasks need an SOP

You do not need an SOP for everything. Write one when a task is:

Repeated. Weekly invoicing, monthly reports, onboarding a client.
Shared. More than one person does it, or someone covers it during holidays.
Risky. Mistakes cost money, upset customers or create security problems.
Rare but important. Year-end tasks, renewing a domain, or removing a departing staff member's access. People forget how to do these between runs.

Skip tasks that are simple, done by one person who is happy doing them, and low risk.

What a good SOP contains

Keep a consistent structure so people know where to look.

Does your SOP have all nine parts?

0 of 9 done

Title. Name the task the way people talk about it: "Send the monthly client report", not "Reporting procedure v3".
Purpose. One sentence on why the task matters.
When. The trigger or schedule: "every Monday", "when a new order is marked paid".
Who. The role responsible, and who covers when they are away.
Before you start. Access, files or information needed.
Steps. Numbered, one action per step.
What done looks like. How the person knows they have finished correctly.
If something goes wrong. Common problems and who to ask.
Owner and last reviewed date.

Saved in this browser only.

Writing the steps

The steps are the part people actually read, so most of your effort goes here.

One action per step. "Open the order and check the shipping address" is two steps.
Start with a verb. Click, open, check, send, copy.
Name things exactly as they appear on screen. If the button says "Fulfil items", write that.
Add screenshots for screens. One clear screenshot can replace a paragraph. Crop it to the relevant part.
Explain the why for steps that look optional. People skip steps they do not understand. "Check the VAT number. Invoices without one get rejected by some clients' finance teams" will be followed.
Use checklists for repeat tasks. For something done daily or weekly, a checklist is often better than a document.
Record a short video if it helps. A two-minute screen recording with narration is a good companion to written steps, but should not replace them. Text is searchable and easier to update.

Who should write them

The person who does the task should write the first draft, because they know the real steps and the workarounds. Then have someone who does not do the task follow it exactly. Every place they get stuck is something to fix. This test is the single best quality check for an SOP.

The manager's job is to review for risk and consistency, not to rewrite it in their own words.

Where to keep them

An SOP nobody can find does not exist. Pick one home and link to it from where the work happens.

In a project management tool, attach or link the SOP to the recurring task. See Choosing a project management tool.
In a shared drive or wiki, use a clear folder structure by department or process, and a single index page.
Avoid personal drives and email attachments. They go missing when people leave.

Keeping them current

SOPs go stale quickly when software or suppliers change. Build in upkeep:

Give each SOP an owner. Their name goes on the document.
Review on a schedule. Every six or twelve months for most; sooner for anything tied to software that updates often.
Make updating easy. Anyone who spots an error should be able to suggest a change in a comment.
Update when you change the process. Make "update the SOP" part of agreeing any process change.

Common mistakes

Writing for an auditor instead of a colleague. Long introductions and formal language bury the steps.
Covering too much in one document. Split long procedures into several SOPs that link to each other.
Writing it once and never testing it. Untested SOPs miss steps the writer does without thinking.
No version date. People cannot tell if they are reading something current.
Treating SOPs as a substitute for training. They support training. New staff still need someone to walk them through the first time. See Onboarding a new staff member.

Frequently asked questions

How long should an SOP be?

As short as it can be while still letting someone new complete the task correctly. Many good SOPs fit on one or two screens. If yours is much longer, it probably covers several tasks.

Can we use AI to write SOPs?

AI tools can turn rough notes or a recorded walkthrough into a tidy first draft, which saves time. They cannot know your real steps, so the person who does the work must check every step, and you should still run the "someone new follows it" test. Avoid pasting passwords or customer data into AI tools.

What about passwords in SOPs?

Never write passwords in an SOP. Refer to the entry in your password manager instead. See Password managers.