How to Write an SOP That Your Team Will Actually Follow

Most SOPs don't fail because they were never written. They fail because they were written poorly.

Too vague to follow without asking questions. Too long to read before starting a task. Written for the person who already knows the process instead of the person who needs to learn it. Stored somewhere nobody thinks to look.

A well-written SOP isn't just a document — it's the difference between a team member who works independently and one who interrupts you every half hour. This guide walks through exactly how to write one that actually works.

Phase 1: Plan Before You Write

The most common reason SOPs end up vague and unusable is that the writer skipped the planning phase and went straight to writing. A few minutes of preparation before you start saves hours of rewriting afterward.

Define the Purpose in One Sentence

Before writing a single step, answer this question: why does this SOP need to exist?

Every SOP should solve a specific problem or close a clear gap. You're seeing inconsistent results. A key team member is the only one who knows how to do something. New hires keep making the same mistake. The answer to "why does this exist" becomes the purpose statement at the top of the SOP, the one sentence that tells your team what this document is for before they read anything else.

Example: This SOP ensures all client invoices are sent within 24 hours of project completion, using the correct template and payment terms.

A well-defined purpose keeps the SOP focused. It also helps whoever is reading it understand why following the process correctly matters, not just what to do.

Decide Who It's For

A SOP written for a senior team member with three years of experience looks very different from one written for a new hire in their first week. Before writing, get clear on your audience.

The most common mistake is writing for yourself, at the level of detail that makes sense to you, assuming context the reader doesn't have. Write for the person who knows the least about this task. If they can follow it without asking questions, everyone can.

Define the Scope

What does this SOP cover and equally important what doesn't it cover? Defining the boundaries prevents confusion about when to use it.

Example: This SOP applies to invoicing for completed service projects. It does not cover recurring retainer billing, which is handled separately.

A clear scope prevents your team from applying the wrong SOP to the wrong situation.

Phase 2: Write the SOP

The Components Every SOP Needs

Not every SOP needs every possible section, but the following components should appear in almost every process document your business creates.

Title. Specific and searchable. A good title tells your team exactly what the SOP covers without opening it. Instead of "Operations Procedure," write "How to Process a Client Refund." Instead of "New Hire Tasks," write "New Hire Onboarding — First Week Checklist."

Purpose. One to two sentences explaining why this SOP exists and what problem it solves. This goes at the very top, before the steps.

Scope. What this SOP covers and what it doesn't. Two to three sentences maximum.

Roles and responsibilities. Who performs the steps, who reviews or approves decisions, and who to escalate to when something goes wrong. Even in a small team, this section prevents "I thought someone else was handling it."

Step-by-step instructions. The core of the SOP. Numbered, clear, one action per step. Written in plain language your team member can follow without stopping to interpret anything.

Linked resources. Every tool, template, form, or external document referenced in the steps should be linked directly inside the SOP. Don't make your team go looking — put it right where they need it.

Owner and review date. Who is responsible for keeping this SOP current, and when it's next due for review. In Notion, you can set this using database properties and the verification feature so reviews happen automatically rather than whenever someone remembers.

Writing the Steps

Use numbered steps. Short sentences. Active verbs. One action per step. If a step involves a decision, document what happens in each scenario. If a step involves a tool, name it and explain what to do inside it specifically.

According to McKinsey research on organizational efficiency, the clarity and specificity of internal process documentation is one of the strongest predictors of whether employees follow procedures consistently — organizations with well-structured, clearly written SOPs see significantly higher compliance rates than those with vague or overly complex documentation.

Here's the practical test: if someone who has never done this task before can follow your SOP from start to finish and produce the correct outcome without asking anyone for help, it's written well. If they get stuck anywhere, that's a documentation gap — rewrite until it holds up independently.

Adding Supporting Resources

Once the steps are written, go back through and look for gaps. Every time the SOP references something external — a template, a form, a tool, a guideline so ask yourself: does that thing exist, and is it linked?

If the step says "send the welcome email," the welcome email template should be linked in that step. If it says "log it in the CRM," and your team member might not know how, embed a short Loom video walkthrough directly in the page. The SOP should be the only place your team member needs to go — everything required to complete the task should be accessible from within it.

This is one of the reasons Notion is so effective for SOP management. Linking, embedding, and organizing resources inside a page takes seconds — and the result is a self-contained process document rather than one that sends your team hunting across multiple tools and folders.

Phase 3: Review, Test, and Maintain

Test It Before You Publish It

Have someone who hasn't done the task before follow your SOP without any additional explanation from you. Watch where they get stuck. Every point of confusion is a documentation gap — not a gap in their ability.

Update the SOP based on what you observe, then test again with a different person if needed. Only publish it once it holds up independently.

This testing step is what separates a working SOP from one that just exists on a page.

Get the Right People to Review It

Before finalizing, have the person who actually performs the task review it for accuracy. They know the shortcuts, the edge cases, and the steps that might seem obvious to someone watching but aren't obvious to someone doing it for the first time. Their input makes the SOP significantly more reliable.

Harvard Business Review's research on workplace communication consistently shows that instructions developed with input from the people who perform the task are significantly more likely to be followed correctly than those written by managers or owners working from memory. 

Assign an Owner and Set a Review Date

An SOP without an owner is an SOP that goes out of date. Assign a specific person — not "the team," not "management" — to be responsible for flagging when the process changes and the documentation needs to be updated.

In Notion, set a review date using the database verification feature. When the date arrives, the owner gets notified. Even a quarterly review of your most critical SOPs is enough to keep your documentation trustworthy and current.

When a process changes, update the SOP the same day, not after. The moment a gap opens between how something is actually done and how it's documented, the manual stops being trusted, and your team stops using it.

Where Your SOPs Should Live

A well-written SOP stored somewhere nobody looks is functionally the same as no SOP at all.

Every SOP your business creates should live inside a single, organized Operations Manual — structured by department or function, searchable, and accessible on any device. Not in a Google Doc folder. Not in a shared drive. In one system your team goes to first whenever they have a process question.

For most small businesses, Notion is the strongest platform for this. It's free for teams of 10 or fewer, works on any device, and is flexible enough to house your entire Operations Manual — SOPs, checklists, guidelines, templates, and training materials — in one navigable hub.

Frequently Asked Questions

What makes an SOP effective? An effective SOP is written for the person who knows the least about the process, not the person who knows it best. It has a clear purpose statement, numbered steps in plain language, linked resources for everything referenced, an assigned owner, and a review date. If someone who has never done the task can follow it without asking questions, it's working.

What's the best way to document SOPs for my business? Start with the process that causes the most repeated questions or the most inconsistent results. Plan before you write — define the purpose, audience, and scope. Write the steps clearly, one action at a time. Add linked resources for everything the reader will need. Test it before publishing. Assign an owner and set a review date. Store it in one searchable, organized system.

How long should an SOP be? As long as it needs to be and no longer. A simple process might need five steps. A complex one might need twenty. The length isn't the measure of quality — clarity is. If your team can follow it without stopping to interpret anything, it's the right length regardless of how many steps it has.

What's the best way to create SOPs in Notion? Create a dedicated SOPs Hub section in your Notion Operations Manual, organized by department or function. Use a consistent page format for every SOP — title, purpose, scope, steps, linked resources, and database properties for owner and review date. Keep everything in one workspace so your team searches once and finds what they need.

What's the difference between an SOP and a checklist? An SOP documents a process — the steps, the context, the decisions, and the resources needed to complete a task correctly. A checklist ensures completion — a list of items to tick off, useful when the order is less important than making sure nothing gets missed. Many strong SOPs include a checklist as one component within a broader process document.

How do I get my team to actually follow SOPs? The SOP has to be easier to use than asking a colleague. That means it's searchable, written clearly, and introduced properly on day one. Leadership modeling the behavior — referring to the manual instead of answering questions directly — is the single most effective driver of adoption. An SOP that's hard to find or hard to follow will be ignored regardless of how well it's written.

How often should SOPs be reviewed and updated? Whenever the process changes — and at minimum reviewed quarterly for your most critical SOPs. Assign a specific owner to each SOP and use Notion's verification feature to set automatic review reminders. Update the SOP the same day a process changes, not after. A document that no longer reflects how things are actually done erodes trust in the entire system.

What if I already have some SOPs but they're not being used? The problem is almost always one of three things: they're hard to find, they're hard to follow, or they were never properly introduced to the team. Audit what exists, rewrite anything that doesn't hold up to the "new hire test," move everything into one organized system, and reintroduce the manual with a proper team walkthrough. Watch our webinar on the topic of getting your team to use your operations manual.

Ready to build SOPs your team will actually follow?

Get the Small Business Operations Manual Template — pre-built structure in Notion, 60+ SOPs ready to customize

Fill out our Custom Inquiry Form — if you'd rather have every SOP written and organized for you