Why Your Team Isn’t Using Your SOPs and How to Fix It

People say, you know, we've taught Joe what the widget is and how to put it on; so why can't Joe do it?

I hear stories like this all the time: a leader explains the task, someone writes the SOP, and the employee gets trained. Yet mistakes, questions, or missed steps still happen.

Leaders often think they've given their team everything needed, but the team still doesn't follow the process.

Before you assume someone isn't trying, check what resources they really have. Teaching what to do is only part of helping them succeed. They also need the right tools, clear expectations, simple instructions, and support for situations not covered in training.

You might be focusing on the wrong thing. Instead of checking if the document actually helps people do the work, you may just be making sure the SOP exists. It's easy to count how many processes you've documented. You can have someone write them up, get them approved, and then check them off a list.

But it's harder to tell if the instructions are truly useful. To find out, watch someone use them and see where they get stuck.

A standard operating procedure can be accurate but still hard to follow. It might explain the usual process but leave out the decisions people make along the way. It may also assume the reader knows where to find a file, which system to use, or what 'review for accuracy' actually means.

Someone who has followed the SOP for years can fill in those gaps without thinking. But someone new to the task doesn't have that experience.

That's why saying "we have an SOP for that" doesn't really answer the main question: can the person doing the task actually use the SOP to get the right result?

Start with what GOOD looks like

Before you explain the steps, define the desired outcome.

Handling a customer order might seem simple, but what does doing it right actually mean? Does the customer get a confirmation? Should inventory be checked first? Who checks the delivery date? What if some information is missing?

An SOP should set a clear standard. When an order is finished, the quantities and shipping information should be correct, the delivery date should be agreed on, and a confirmation should be sent to the customer.

If people know the desired result, they can check their work against it. They can also make better decisions when things don't go exactly as planned.

If it helps, give an example of a finished task, a correct result, or a common mistake. It's more helpful to say 'check your work against this example' than just 'make sure it's correct'.

Look for the friction between the steps.

Imagine the SOP tells Joe to attach a widget with a certain tool. Joe understands the instructions, but he can't get the tool because only his supervisor has the key, and the supervisor is in a meeting. More training won't open the cabinet.

The same thing can happen in office work. For example, a process might tell someone to update a record but not give them the right permission. It might require consent but not say who gives it. Or it could tell people to use the current template, even though three versions are saved in different folders.

These gaps can turn a simple task into something hard to finish.

Before changing an SOP's wording, consider the context around the work. Are the right tools and information available? Can the employee make the needed decisions? Does the next person know when it's their turn? These things affect how well business processes work. A task can stall even with clear instructions if the rest of the process isn't complete.

Put the instructions where the work happens.

It might be quicker to ask a coworker than to search through folders for the SOP. Over time, this becomes the usual way of working, and the document gets used less and less.

Make sure the latest instructions are easy to find when people need them most. You could link them to the task, add a checklist to the project template, or put a quick reference by the workstation.

The format should fit the task. For repeated tasks, use a checklist. If there are many possible outcomes, use a decision guide. If the task uses unfamiliar software, include screenshots with the instructions. Give enough detail for people to complete the task correctly, and arrange the information so they can easily find what they need.

Explain what to do when the usual process changes.

Many SOPs assume the task will always be complete, accurate, and on time. Employees then have to figure out the exceptions on their own. What should Joe do if the widget doesn’t fit? What should the account manager do if the customer asks for something outside the agreed scope? What happens if an approval is delayed?

A good standard operating procedure should point out common exceptions and explain what to do. It should also clearly show which decisions an employee can make and when to ask for help. Instead of saying 'Ask your manager if there's a problem,' which is vague, it's better to give a clear escalation point. This helps employees know when to ask for help, and managers know why an issue was sent to them.

You can't predict every situation, but you can give people a reliable way to handle things when they're not sure what to do.

Test your SOP with someone who uses it.

Pick a task that often causes questions, delays, or rework. Have the person responsible do the task by following the current SOP.

Watch for moments when they pause, leave the document, ask a coworker, or use information that's not written down. Find out what they need in those moments.

If someone says, “That’s what the document says, but here’s how we actually do it,” there might be a good reason for the difference or a shortcut that causes problems elsewhere. Either way, it's worth checking out.

Update the process based on what you find. Assign someone to keep it updated, and test it again during real work. Check the results: Can the person finish the task accurately? Are handoffs clearer? Are there fewer repeated questions and mistakes? These things show the SOP’s value better than just ticking a training box.

Build processes your business can grow with

When building scalable business operations, start with the ongoing work that still needs someone to explain the missing parts.

Every undocumented decision, unclear handoff, or hard-to-find tool gives the team another reason to ask an experienced employee or leader for help. As the business grows, these requests can slow things down.

Good standard operating procedures share that knowledge and turn it into a repeatable way of working. They give people the context, access, and guidance they need to take ownership.

Employees still need to take responsibility, but it's just as important to make sure the system supports the results you want. Instead of asking 'Why can't Joe do it?', ask 'What does Joe need to do it well, and have we actually given it to him?'

Find out where your team is getting stuck. Click here to take the Zero-Blame Leadership Diagnostic.