How to Write an SOP Employees Will Actually Follow

Every company has at least one SOP that nobody follows.

It's usually not because the process it describes is wrong. It's because the document itself failed: it's a wall of paragraphs, it was written for an audit instead of a person doing the work, or it went stale the first time the software changed, and nobody updated it. Employees learn, correctly, that the "official" document is less reliable than just asking the person next to them, and the SOP becomes shelfware.

This guide is about writing the other kind of SOP: the one a new hire can follow on their first day, unsupervised, and get the same result an experienced employee would. It covers what makes procedures usable, a repeatable process for writing them, a before-and-after example, a ready-to-use template, and the mistakes that quietly kill most SOPs before anyone even notices.

Who this guide is for

This article is written for:

• Startups and operations managers documenting processes for the first time

• Team leads who keep answering the same question and want to write the answer down once

• New or aspiring technical writers who want a concrete, repeatable method for writing procedures — not just formatting advice

You don't need a technical writing background to use this guide. You need a process worth documenting and about an hour to write the first draft.

Key definitions

A few terms get used loosely in most workplaces. This guide uses them precisely:

SOP (Standard Operating Procedure): A written, step-by-step description of how to complete a specific, recurring task.

Process owner: The person accountable for a procedure being accurate and current; not necessarily the person who performs it most often.

Work instruction: A more detailed version of an SOP, scoped to operating one specific tool or system (e.g., "How to issue a refund in PayPal").

Policy: A high-level rule or position (e.g., "Refunds require manager approval") that an SOP operates within, but doesn't itself explain how to execute.

If you're documenting a broad process with several tools involved, you may actually need one SOP plus several work instructions underneath it. This guide focuses on the SOP layer — the sequence of steps a person follows, tool-agnostic where possible.

Why employees skip SOPs

Before writing a usable SOP, it helps to know exactly what makes an unusable one. In my experience reviewing and rewriting existing company documentation, the same four problems show up almost every time:

1. It was written for compliance, not for use. The goal was "we have a document," not "someone can follow this correctly."

2. It describes instead of instructing. Sentences like "the invoice is then reviewed by the finance team" don't tell the reader what to do.

3. It has no visual anchor. Long blocks of text with no screenshots or checklists force the reader to hold the whole procedure in their head.

4. It's outdated, and nobody noticed. The software changed, the steps didn't, and now step 4 refers to a button that no longer exists.

Every recommendation in the rest of this guide exists to solve one of these four problems.

The anatomy of an SOP people actually follow

Structure matters as much as content. The table below contrasts the traits of SOPs that get ignored with the traits of SOPs that get used.

Every effective SOP, regardless of topic, follows roughly the same skeleton:

1. Purpose — why this procedure exists, in one or two sentences
2. Scope — what it covers, and explicitly what it doesn't
3. Prerequisites — what the reader needs before starting (access, tools, information)
4. Step-by-step procedure — numbered, one action per step
5. Visuals — screenshots or a diagram at points of likely confusion
6. Troubleshooting — the two or three things most likely to go wrong
7. Completion checklist — a final confirmation the task was done correctly
8. Revision history — version, date, author, and what changed

How to write one: a step-by-step process

Use this procedure to go from "nothing written down" to a tested, publishable SOP.

1. Identify the process owner. Before writing anything, name the person accountable for this procedure's accuracy. This is who approves the final draft and who gets asked when something's unclear later.

2. Interview the person who actually does the task. Ask them to walk you through it step by step, in the order they actually perform it — not the order they'd describe it from memory. Ask specifically: "What's the very first thing you do?" and "What do you do when something goes wrong here?" The second question usually surfaces the exceptions a clean, idealised description leaves out.

3. Map the steps before writing prose. Sketch the sequence — including decision points — as a simple flow before you write full sentences. This catches missing steps and disagreements while they're still cheap to fix.

Task trigger
↓
Step 1: Action
↓
Decision point? ──No──→ Step 2a
│
Yes
↓
Step 2b
↓
Task complete

1. Write the steps in active voice, one action per step. Each step should start with a verb and describe exactly one action. If a step contains the word "and" joining two different actions, split it into two steps.

2. Add a screenshot or diagram at every step where the reader could get lost. You don't need one per step — you need one everywhere the interface, environment, or decision isn't obvious from text alone.

3. Test it on someone who has never done the task. Hand them only the document — no verbal explanation — and watch them attempt it. Every point where they hesitate or ask a question is a gap in the SOP, not a gap in the reader.

4. Publish it in the team's single documentation location, and set a review date. A finished SOP that lives in a personal folder isn't finished. See the "Where to store it" note in the template section below.

Example: rewriting a real SOP step

Here's what the difference between an ineffective and effective SOP looks like at the sentence level — this is the single most common fix I make when editing existing procedures.

Before (ineffective):

"Once the client's information has been received, it is entered into the system and then the welcome email is sent out, usually within a day or two."

After (effective):

Step/Action

1. Open the CRM and click New Client.
2. Enter the client's name, email, and company from the intake form.
3. Click Save.
4. Click Send Welcome Email. The email sends immediately — do not delay this step.

The "after" version removes every ambiguity in the "before" version: who does it, in what tool, in what order, and by when. That specificity is the entire difference between a document someone can follow unsupervised and one that requires a follow-up question.

Screenshots and diagrams: what to include

A screenshot earns its place in an SOP when it answers one of these questions for the reader:

• Am I looking at the right screen?
• Which exact button or field do I click?
• What does "done" look like here?

A diagram earns its place when the process branches, involves more than one person, or has a sequence that's easier to see than to read — like the flow shown in the writing process above. If a process has no decision points and only one person involved, you likely need screenshots more than a diagram.

Template: SOP starter checklist

Use this checklist as a template before publishing any SOP.

1. Purpose stated in 1–2 sentences
2. Scope defines what's included and excluded
3. Process owner named
4. Prerequisites listed (access, tools, information needed)
5. Every step starts with a verb and describes one action
6. No step contains "and" joining two separate actions
7. Screenshots or diagrams included at points of likely confusion
8. A troubleshooting section covers the top 2–3 known issues
9. A completion checklist confirms the task was done correctly
10. Tested by someone who has never performed the task, using only the document
11. Version number, date, and author included
12. Published to the team's single documentation location
13. Next review date set

Common mistakes

Conclusion

A good SOP isn't defined by how complete or professional it looks; it's defined by whether a person unfamiliar with the task can follow it and get the right result, without asking anyone a follow-up question. That standard is achievable for almost any process, but it requires treating the SOP as a piece of usability work: interview the real performer, map before you write, use active voice and one action per step, add visuals where they earn their place, and test on someone who's never done the task before you call it finished.

Do that consistently, and you get more than a stack of documents — you get a company that can hand off knowledge reliably, onboard new employees faster, and stop losing critical process knowledge every time someone leaves.