How to Write SOPs Your Team Will Actually Follow

By Lisa González, Certified EOS Implementer® and co-author of Process! (The EOS Mastery Series). Updated June 14, 2026.

An SOP your team follows is a short, usable document that captures how the work actually gets done, written with the people who do it, stored where they already work, and backed by training and accountability. The format matters less than the fit. If it is hard to find or slow to use, it gets skipped.

I'm Lisa González, Certified EOS Implementer® and co-author of Process!, the official EOS book on the Process Component. I have watched hundreds of teams write careful SOPs that sit on a shelf. The fix is rarely better writing. It is building the document and the followership at the same time. Here is how to do both, in seven steps.

Step 1: Start with the processes that break most often

Do not document everything. Pick the five processes that cause the most rework, the most questions, or the most dropped balls. Write those first. Momentum comes from fixing real pain, not from completeness.

Common mistake: trying to document the whole company at once. The project stalls, and nothing gets used.

Step 2: Write it with the person who does the work

Sit with the person who runs the task. Capture how the work actually happens, including the shortcuts and the workarounds. Write with them, not about them. People follow a procedure they helped build.

Common mistake: a manager writing the SOP from memory. It describes the work they imagine, not the work that happens.

Step 3: Capture the 20 percent that drives 80 percent of the result

Record the major steps only. Aim for one to three pages. Start each step with an action verb so it reads as an instruction. Detailed checklists and screenshots live a level below, and only where the cost of an error justifies them.

Common mistake: writing a procedure manual. The longer it is, the less it gets opened.

Step 4: Store it where the work already happens

Put the SOP one click from the task, inside the tools your team already uses. Findability is what separates an SOP that gets used from one that gets improvised around. If the document is harder to find than the work is to wing, your team will wing it.

Common mistake: burying the SOP in a shared drive nobody opens.

Step 5: Train the team and explain the why

Walk every affected person through the SOP. Explain why it exists and what breaks when it is skipped. A procedure nobody was trained on is a procedure nobody follows.

Common mistake: emailing the link once and assuming the team will read it.

Step 6: Build compliance into your accountability rhythm

Name an owner for each SOP. Put process compliance on a scorecard. Give feedback when a step is skipped, and recognition when the process is followed well. Followership is a leadership habit, not a one-time rollout.

Common mistake: an SOP with no named owner. When the work changes and the document does not, the team learns it cannot be trusted.

Step 7: Review and update on a schedule

Review each SOP at least once a year, and the moment the process changes. An outdated SOP is worse than none, because it teaches your team that the documentation is wrong. Stamp each one with an owner and a review date.

Common mistake: writing it once and never touching it again.

What to do when the team still will not follow it

Treat non-followership as data, not defiance. Ask why. The usual answers are the four causes above: the document does not match reality, it is too slow to use mid-task, nobody was trained, or there is no consequence either way. Each one points to a specific fix. We work the cause, not the symptom.

Frequently asked questions

Why do employees not follow SOPs?

Usually one of four reasons. The document does not match how the work really gets done, it is too slow to use mid-task, nobody was trained on it, or there is no consequence either way. Each is a leadership issue with a fix, not a discipline problem.

How long should an SOP be?

One to three pages for a core process. Capture the major steps with a few sub-points each. If it runs longer, you are documenting at too low a level and should move the detail into a checklist.

Who should write the SOP?

The person who does the work, with the process owner reviewing it. People follow procedures they helped build. Documentation written at them tends to get ignored.

Where should we store SOPs so they get used?

One central, searchable place that sits inside the tools your team already uses. The goal is one click from the task. Buried SOPs get skipped.

How often should SOPs be updated?

At least once a year, and immediately when the process changes. Give each SOP an owner and a review date so it stays trustworthy.

Want a facilitator who has done this hundreds of times? I work with leadership teams to get core processes documented, simplified, and followed. Book a discovery call.