How To Create Standard Operating Procedures That People A…

The standard operating procedure that lives in a binder in a back office serves one purpose: it makes you feel like your business is organized.

It doesn’t actually organize anything.

I’ve walked into hundreds of businesses where the SOP manual sits on a shelf, untouched, while the work happens completely differently on the ground. The procedures say one thing. The team does another. The founder has no idea because they’re not looking.

An SOP only works if people actually follow it. And people only follow it if it’s simple, visual, embedded in their daily workflow, and actually makes their job easier.

This article is about how to build SOPs that people don’t just read — they use.

Why Traditional SOPs Fail

Let’s start with why 90% of operating procedures end up as expensive paperweights.

You hire a consultant or spend your own time documenting everything. You write 47-page procedures. You include edge cases. You cover scenarios that happened once. You make it comprehensive.

Then you print it. Bind it. Hand it to your team.

And nothing changes.

Why? Because you just handed them a textbook, not a tool. It sits in a drawer. When someone needs guidance, they ask a coworker. When there’s a conflict about how something should be done, people default to what they’ve always done.

The procedure wasn’t bad. The format was.

A manager I worked with spent three weeks documenting the sales process. 52 pages. Every step. Every contingency. It was thorough. It was impressive. It was also completely ignored.

When I asked the sales team why they weren’t following it, they said: “We tried. But when we’re on a call with a client, I can’t exactly flip through a 52-page manual. Also, it doesn’t match how we actually work.”

The SOP was written to document what should happen. Not what actually works.

If it’s not working, change it. Most people interpret this as making the SOP more detailed or more enforced. Wrong. It means changing the format, the medium, or the approach entirely.

The Three Requirements for SOPs That Actually Work

An SOP only gets followed if it meets three criteria simultaneously. Miss one and it dies.

1. It’s actually simpler than the current process.

Your team has a way of doing things now. Maybe it’s inconsistent. Maybe it’s inefficient. But it works for them.

When you give them an SOP, it has to be simpler than what they’re currently doing. If following the SOP takes more time or effort than their current approach, they won’t follow it.

I worked with a customer service team that was handling tickets in a chaotic way. No consistency. No tracking. The manager created a 15-step procedure to standardize everything. It was thorough. It was also painful.

Following the SOP meant more clicks, more forms, more steps. The team ignored it and went back to their ad-hoc approach.

We rebuilt it. Same outcome (standardized, tracked tickets). But we reduced it to 5 steps using their existing tools more efficiently. Suddenly, they followed it. Because it made their job easier, not harder.

2. It’s visual, not written.

Words are slow. Pictures are fast. When you have a moment to remember something, you don’t want to read paragraphs. You want to look at a diagram or a flowchart.

The most effective SOPs I’ve seen are mostly visual. A flowchart showing decision points. Screenshots with annotations. Videos walking through the process. Maybe some text for detail. But mostly visual.

Think about why IKEA instructions work. They don’t use paragraphs. They use pictures. You can follow them without reading a single word.

Your SOPs should work the same way.

A client in healthcare had a complex intake process. Multiple forms. Different paths depending on patient condition. They’d tried written SOPs. Didn’t work. Too many steps, too many exceptions, too much reading.

We converted it to a visual flowchart. “Is the patient new or returning? If new, go left. If returning, go right. Does patient have insurance? If yes, here’s the form. If no, here’s a different form.” Simple visual pathways.

Compliance went from 60% to 92% in two months. Not because people suddenly cared more. Because they could follow the process without thinking hard.

3. It’s embedded in the actual workflow.

The SOP shouldn’t exist separately from the work. It should be part of how people do the work.

If you’re using a project management tool, the SOP should be in the project management tool, not in a separate document. If you’re using a CRM, the workflow should be built into the CRM. If you’re using spreadsheets, the process should be documented in the spreadsheet itself.

The worst approach is handing someone a document and saying “follow this while you work in a different system.” You’re asking them to context-switch constantly.

A sales team I worked with had beautiful SOPs for the sales process. They were printed and laminated. But the team used a CRM (Salesforce). The procedure wasn’t in Salesforce. It was hanging on the wall. So people would half-remember it and do their own thing in Salesforce.

We moved the SOP into Salesforce itself. As part of the pipeline setup, each stage had a checklist and guidance embedded right there. When a salesperson moved a deal to the next stage, they saw the SOP for that stage automatically.

Compliance jumped. Not because people were more disciplined. Because the process was in the tool they were already using.

The SOP Creation Process That Works

Here’s how to build SOPs that people actually follow.

Step 1: Document what people actually do (not what should happen).

Don’t sit in your office and write what you think people should be doing. Go watch them work.

Spend time in sales calls, in customer service conversations, in operations. See how they actually handle situations. Where do they make decisions? Where do they struggle? What workarounds do they use?

Most founders are shocked by this exercise. The gap between what they think people do and what people actually do is massive.

When you build SOPs based on fantasy (what should happen) instead of reality (what actually happens), people won’t follow them.

Step 2: Identify the outcome, not the procedure.

An SOP isn’t about the steps. It’s about the outcome. What are we trying to achieve?

If the outcome is “consistent customer handoff,” the procedure is a means to that end. Not the goal itself.

When you focus on the outcome, you can sometimes simplify the procedure radically. Or use a different process entirely.

I worked with a team that had an 11-step customer onboarding process. Very detailed. The outcome they wanted was “customer knows how to use the product and we have verified they can complete at least one transaction.”

When we focused on that outcome, we realized four of the steps weren’t moving toward it. They were just things the founder thought should happen. We cut them. The process still achieved the outcome but in 7 steps instead of 11.

Step 3: Create a visual representation first.

Don’t write the SOP. Draw it.

Use a flowchart. Use a simple diagram. Use screenshots. Use a video. Show the actual steps, the decision points, and where people need to deviate.

Only after you’ve visualized the whole thing should you add supporting text.

Step 4: Test it with the people who will use it.

Before you finalize anything, have the team walk through it.

“Here’s the new process. Can you follow it? Where is it confusing? Where does it not match how you work? What’s missing?”

Most SOPs fail because the creator doesn’t actually verify that people can follow them. You write it. You print it. You assume it works.

Test it first. In real conditions. Watch someone use it and see where they get stuck.

Step 5: Make it living and visual in the workflow.

Put it in the tool where work happens. Not in a separate document. Not in a manual.

If you use Notion, create a process wiki. If you use Slack, pin the visual flowchart. If you use spreadsheets, embed the instructions right in the cells. If you use a CRM, build the workflow directly into the system.

The more friction between the SOP and the work, the more friction there is between the work and following the SOP.

The Video-First SOP Revolution

Here’s something I’ve discovered that’s radically effective: video SOPs.

Not long videos. Not training videos. Short, focused videos (2-4 minutes) showing exactly how to do a specific task. Recorded on screen. With narration. No production quality necessary.

Why do video SOPs work better than written ones?

Because they match how people actually learn. We’re visual creatures. We learn by watching more easily than by reading.

A client created a 15-minute training video on their sales process. It showed the actual CRM, the actual emails, the actual conversations. New salespeople watched it once and got it.

Previously, they’d spent hours in training meetings going through the written SOP. Half the team was confused. Now, a 15-minute video communicates it faster and more effectively.

The barrier to entry is low. Any manager can record their screen, talk through the process, and share it. No production team. No fancy editing. Just clarity.

If you have more than five people on your team, you should have at least five video SOPs covering your core processes.

Common SOP Mistakes to Avoid

Too detailed. You document every possible exception. You make it comprehensive. You make it unusable. People can’t figure out what actually matters.

Solution: Document the 80% case. Have a process for exception handling (escalate, ask the manager). But the main SOP should be simple.

Outdated immediately. You spend months perfecting the SOP. By the time it’s ready, the process has changed. It’s no longer accurate.

Solution: Update as you go. Make SOPs living documents. When you change a process, update the SOP immediately. Not after a month. Not after a year. Immediately.

Not visual enough. You’ve written paragraphs. You’ve made it detailed. People don’t read it because it’s a wall of text.

Solution: Convert everything to visual format. Flowcharts, screenshots, diagrams, videos. Text should be supporting, not primary.

Doesn’t actually make work easier. The SOP exists to satisfy the manager that things are documented. It doesn’t actually help people do the work better.

Solution: Ask the team. Does following this make your job easier or harder? If harder, change it. If it’s not working, change it.

The Measurement Question

How do you know if your SOPs are working?

Not by whether they exist. By whether they’re being used.

Track these metrics:

Consistency of output. Do all customers go through the same process? Do all deals move through the same stages? Is the experience consistent?

Reduction in errors. Are people making fewer mistakes now that the process is documented and clear?

Faster onboarding. How long does it take a new team member to be productive? Should be much faster if they can follow an SOP instead of learning through osmosis.

Fewer questions. Are people asking you how to do things less often? That’s a sign the SOP is answering questions.

Time saved. Is the team able to do more in the same amount of time because the process is more efficient?

If these metrics aren’t moving, your SOP isn’t working. Go back to the team. Figure out why. Fix it.

Focus Determines Direction

Focus determines direction. When you create an SOP, your focus is on either documentation or direction.

Most founders focus on documentation. “I need to document how we do things so people follow a consistent process.”

That’s backwards. The focus should be on direction. “How do I make it so obvious what to do that people naturally do it right?”

Documentation is the artifact. Direction is the goal.

When you build SOPs with that focus, everything changes. You’re not trying to document procedures. You’re trying to make the right way obvious and easy.

Success leaves clues. The clue in every business with strong execution is this: people follow the process, not because they’re forced to, but because the process is so obvious and helpful that it’s easier than doing their own thing.

Your First SOP Project

Pick one process that’s broken or inconsistent right now. Not the most important one. The one that’s causing the most friction.

Follow the steps above:

1. Observe how it’s actually being done.

2. Define what outcome you’re trying to achieve.

3. Design a simple, visual version.

4. Test it with the people who will use it.

5. Embed it in their workflow.

6. Measure whether it’s working.

You’ll have a working SOP in three weeks that people actually follow.

Then scale this approach to your other critical processes.

The business that wins isn’t the one with the thickest SOP manual. It’s the one where people naturally do the right thing because the process is so clear and helpful that it’s the path of least resistance.

Build for that.