How to Write Standard Operating Procedures (SOPs): A Step-by-Step Guide

If you've ever watched a senior employee leave and take half your company's institutional knowledge with them, you already understand why standard operating procedures matter. SOPs aren't bureaucratic paperwork. They're the operating system that lets your business produce consistent results regardless of who's doing the work, what day it is, or whether the founder is in the building.

According to a McKinsey analysis of operational excellence, companies with well-documented processes are 30-50% more likely to outperform their peers on efficiency metrics. That's not a marginal advantage. That's the difference between a business that scales and one that stays stuck.

This guide walks you through exactly how to write SOPs that people actually follow -- not the kind that collect dust in a shared drive. We'll cover the format, the process, the templates, and the mistakes that derail most documentation efforts. Whether you're writing your first SOP or rebuilding a library of outdated ones, this is the framework that works.

What Is a Standard Operating Procedure (SOP)?

A standard operating procedure is a documented set of instructions that describes how to complete a recurring task or process. It answers three questions: what needs to happen, who does it, and what "done" looks like.

SOPs differ from policies, guidelines, and work instructions -- though these terms often get used interchangeably:

• Policy: The "why" -- the principle or rule. Example: "All customer refunds must be processed within 48 hours."
• SOP: The "how" -- the documented process. Example: "Steps for processing a customer refund in our billing system."
• Work instruction: The detailed "what" for a specific task within the SOP. Example: "How to issue a credit in QuickBooks."
• Guideline: A recommendation, not a requirement. Example: "When possible, offer store credit before a cash refund."

The SOP sits in the middle -- specific enough to be actionable, broad enough to cover the full process. When you systemize your business, SOPs are the building blocks.

Why Do SOPs Matter for Growing Businesses?

Small businesses can survive without SOPs for a while. The founder knows everything, the team is small, and communication is easy. But there's a threshold -- usually somewhere around 8-15 employees or $1M-$3M in revenue -- where the lack of documented processes starts creating real damage.

Here's what that damage looks like in practice:

• Quality inconsistency. The same task produces different results depending on who does it. One account manager sends flawless onboarding emails; another forgets half the attachments. That's not a talent problem. It's a systems problem.
• Slow onboarding. New hires take months to become productive because they're learning by osmosis instead of by system. Every question they ask is a question someone has to stop and answer.
• Owner dependency. The founder becomes the bottleneck because they're the only person who knows how things work. That's not leadership. That's captivity. (If this sounds familiar, read our guide on the founder's delegation framework.)
• Rework and errors. Without documented standards, mistakes get repeated. According to the U.S. Small Business Administration, documented procedures are a foundational element of operational resilience -- a principle that applies to every business function, not just security.
• Impossible delegation. You can't delegate what isn't defined. Delegation requires a clear process, clear expectations, and clear metrics. SOPs provide all three.

The businesses that get past these thresholds are the ones that build systems before they desperately need them. SOPs are how you get there.

How Do You Choose Which SOPs to Write First?

Don't try to document everything at once. That's the fastest way to burn out and abandon the effort entirely. Instead, use the Impact-Frequency Matrix to prioritize.

Score each process on two dimensions:

1. Frequency: How often does this process happen? (Daily = 3, Weekly = 2, Monthly or less = 1)
2. Impact: What's the cost when this process goes wrong? (High revenue/customer impact = 3, Moderate = 2, Low = 1)

Multiply the two scores. Your highest-scoring processes are your SOP priorities. For most businesses, the top candidates fall into these categories:

• Customer-facing processes: Onboarding, support ticket handling, order fulfillment, complaint resolution
• Revenue processes: Lead follow-up, proposal generation, invoicing, collections
• Recurring operational processes: Inventory management, quality checks, reporting, vendor management
• People processes: Hiring, onboarding new employees, performance reviews, offboarding

A practical starting point: identify the five processes where errors have cost you the most money or the most customer goodwill in the last six months. Start there.

What Is the Best Format for an SOP?

There's no single "right" format, but the best SOPs share common elements. After working with hundreds of growing businesses at gardenpatch, we've found that the Trigger-Action-Outcome (TAO) format produces SOPs that people actually use.

The TAO Format

Every step in the SOP follows this structure:

• Trigger: What initiates this step? ("When the customer submits a return request...")
• Action: What specifically needs to happen? ("Open the returns dashboard, verify the order date is within 30 days, check the item condition notes...")
• Outcome: What does success look like? ("The return authorization number is generated and the customer receives a confirmation email with shipping instructions.")

This format eliminates the ambiguity that plagues most SOPs. The person following it knows exactly when to act, what to do, and how to verify they did it correctly.

SOP Template: The Core Sections

Every SOP should include these sections:

1. Title and ID number. Something descriptive and searchable. "SOP-CS-004: Processing Customer Refunds" beats "Refund Procedure."
2. Purpose. One sentence explaining why this SOP exists. "This SOP ensures all customer refunds are processed accurately within 48 hours of approval."
3. Scope. Who does this apply to? What situations does it cover -- and what does it explicitly not cover? "Applies to all refund requests under $500. Refunds over $500 require manager approval per SOP-CS-005."
4. Roles and responsibilities. Who is involved and what is each person accountable for?
5. Prerequisites. What tools, access, or information does someone need before starting?
6. Step-by-step instructions. The TAO-formatted steps. Number them. Keep them concrete. Use screenshots where the interface matters.
7. Decision points. Where does the process branch? Map out the if/then logic clearly.
8. Exceptions and escalation. What do you do when the SOP doesn't cover the situation? Who do you escalate to?
9. Metrics. How do you know this process is working? What gets measured?
10. Version history. When was this created, last updated, and by whom?

This template works for everything from a 10-step customer onboarding process to a 3-step inventory reorder procedure. Scale the detail to match the complexity of the task.

How Do You Write an SOP Step by Step?

Here's the actual process for creating an effective SOP from scratch. This is the method we use and recommend to every operations team we work with.

Step 1: Observe and Record the Real Process

The single biggest mistake in SOP creation is writing from memory. When people describe how they do something, they skip steps, idealize the process, and forget the workarounds that make it actually work. Instead, observe the process as it happens in real time.

For digital processes, have the person who currently performs the task record their screen using Loom, OBS, or any screen recording tool. They should narrate as they go: "First I open the CRM, then I filter by lead status, then I check if the last contact was more than seven days ago..."

For physical or in-person processes, use a smartphone video. Follow the person through the actual workflow. Record everything, including the small decisions they make without thinking about it.

Watch the recording once through, then watch it again with the SOP template open, noting each step, decision point, and tool used.

Step 2: Draft the SOP in TAO Format

Convert your observations into numbered steps using the Trigger-Action-Outcome format. Be specific. Instead of "Update the customer record," write "In HubSpot, navigate to the customer's contact record, click 'Log Activity,' select 'Call' from the dropdown, and enter the call summary in the notes field."

Include screenshots for any step where the interface matters. A picture of the exact button to click eliminates 90% of confusion.

For decision points, use a simple if/then structure:

• If the customer's account is less than 30 days old, then escalate to the account manager.
• If the customer's account is 30+ days old and the refund is under $500, then process the refund directly.
• If the refund exceeds $500, then submit for manager approval via the approvals channel in Slack.

Step 3: Test with a Fresh Set of Eyes

Hand the drafted SOP to someone who has never done this task before and ask them to follow it. Watch them, but don't help. Every time they pause, get confused, or ask a question, that's a gap in the SOP.

This step is non-negotiable. An SOP that only works when the writer follows it is useless. The whole point is that anyone with reasonable competence can produce a consistent result by following the document.

Common gaps revealed during testing:

• Assumed knowledge ("Open the dashboard" -- which dashboard? Where?)
• Missing login credentials or access requirements
• Skipped steps that seemed too obvious to write down
• Decision points that weren't documented because the expert handles them on instinct

Step 4: Refine Based on Feedback

Update the SOP based on what the test revealed. Then test it again with a different person. After two rounds of testing, your SOP should be robust enough for production use.

This iterative approach is the same principle behind continuous improvement methodologies. The first draft is never the final draft, and that's by design.

Step 5: Store It Where the Work Happens

An SOP buried in a folder no one visits might as well not exist. Store your SOPs where people encounter them in the natural flow of work:

• Link SOPs directly in your project management tool (Asana, Monday.com, ClickUp) as task templates
• Embed them in your CRM workflow stages
• Pin them in the relevant Slack channels
• Add them to your company wiki or knowledge base (Notion, Confluence, or Google Sites) with a clear naming convention and search-friendly titles

The rule is simple: zero clicks from where the work happens to where the SOP lives. If someone has to go searching for it, adoption will be low.

What Does a Good SOP Look Like? A Real Example

Let's walk through a complete SOP example for a common small business process: onboarding a new client.

SOP-OPS-012: New Client Onboarding

Purpose: Ensure every new client receives a consistent, professional onboarding experience within 48 hours of contract signing.

Scope: Applies to all new retainer and project-based clients. One-time consultation clients follow SOP-OPS-013.

Roles:

• Account Manager: Primary owner of the onboarding process
• Project Manager: Sets up project workspace and timeline
• Finance: Sends first invoice and confirms payment terms

Prerequisites: Signed contract in DocuSign, CRM deal marked "Closed Won," client contact details verified.

Steps:

1. Trigger: Deal status changes to "Closed Won" in CRM. Action: Account Manager sends the welcome email template (Template: NCA-Welcome-01) within 4 hours. Outcome: Client receives email with welcome packet, team introductions, and scheduling link for kickoff call.
2. Trigger: Welcome email sent. Action: Project Manager creates project workspace from the "New Client" template in the PM tool. Assigns team members, sets milestone dates based on the project timeline in the signed proposal. Outcome: Project workspace is live with all tasks assigned and dated.
3. Trigger: Project workspace created. Action: Account Manager schedules kickoff call within 5 business days of contract signing. Sends agenda template (Template: NCA-Kickoff-Agenda-01) 24 hours before the call. Outcome: Kickoff call is on the calendar and client has received the agenda.
4. Trigger: Contract signed. Action: Finance sends first invoice per payment terms in the contract using the billing template in QuickBooks. Outcome: Invoice delivered, payment due date logged in the AR tracker.
5. Trigger: Kickoff call completed. Action: Account Manager sends kickoff summary email with action items, next steps, and shared access links within 24 hours. Updates CRM with kickoff notes. Outcome: Client and team are aligned on scope, timeline, and responsibilities.

Decision Point: If the client requests changes to scope during kickoff, Account Manager documents the request and escalates to the Director of Client Services before modifying the project plan.

Metrics: Time from contract signing to kickoff call (target: 5 business days or less). Client onboarding satisfaction score (target: 4.5/5 or higher).

This example covers a relatively simple process. More complex operations -- like supply chain workflows or multi-phase service delivery -- may require sub-SOPs for individual stages.

How Do You Handle Decision Points and Exceptions in SOPs?

Linear processes are easy to document. The real challenge is handling the branches -- the "what if" scenarios that require judgment. Here's how to document them without turning your SOP into a novel.

Use Decision Tables for Complex Logic

When a single decision point has multiple variables, a decision table is clearer than nested if/then statements. For example, a returns process might have a table like this:

Returns Decision Table:

• Item condition: Unopened + Within 30 days = Full refund, no approval needed
• Item condition: Opened, undamaged + Within 30 days = 75% refund or full store credit, team lead approval
• Item condition: Any condition + 31-60 days = Store credit only, team lead approval
• Item condition: Any condition + 60+ days = No refund, offer 15% discount on next order, no approval needed

Decision tables compress complex logic into a scannable format. The person following the SOP finds their scenario and knows exactly what to do.

Build an Escalation Framework

No SOP can cover every scenario. That's why every SOP needs an escalation path -- a clear answer to "what do I do when this process doesn't apply?"

A good escalation framework has three tiers:

1. Tier 1: Handle within the SOP. The documented decision trees cover the scenario. Follow them.
2. Tier 2: Consult a peer or team lead. The scenario is unusual but not unprecedented. Check with someone more experienced before proceeding.
3. Tier 3: Escalate to management. The scenario is novel, high-risk, or involves significant financial impact. Stop and escalate.

The key is making it safe to escalate. If people feel punished for flagging exceptions, they'll improvise instead -- and improvisation is where expensive mistakes happen.

How Do You Keep SOPs Up to Date?

The half-life of an SOP in a fast-growing business is about six months. Tools change, team structures shift, customer expectations evolve. An outdated SOP is worse than no SOP because it gives false confidence.

Build maintenance into the system:

• Assign an owner to every SOP. Not a team. A person. They're responsible for keeping it current.
• Schedule quarterly reviews. Every 90 days, each SOP owner reviews their documents. Has anything changed? Are the screenshots still accurate? Have new edge cases emerged?
• Create a change trigger list. Certain events should automatically trigger an SOP review: a tool migration, a team restructure, a new product launch, a process change requested by a client. Build these triggers into your project management workflow.
• Track version history. Every update gets logged with the date, the author, and a brief description of what changed. This creates accountability and makes it easy to understand the evolution of a process.
• Collect feedback continuously. The people who use the SOP daily are the best source of improvement ideas. Make it easy for them to suggest changes -- a simple form, a Slack shortcut, or a comment thread on the document itself.

At gardenpatch, we recommend treating SOPs the way software companies treat code: they're living documents that improve through continuous iteration, not static artifacts that get written once and forgotten. This mindset is central to how we approach operations management for growing businesses.

How Do You Get Your Team to Actually Follow SOPs?

Writing SOPs is half the battle. Getting people to use them is the other half. Here's what works:

Involve the Team in Creation

The people who do the work should build the first draft. Not just because they know the real process (though they do), but because people follow processes they helped create. Ownership drives adoption. When you build high-performing teams, shared ownership of systems is part of the culture.

Make SOPs Part of Onboarding

New hires should encounter SOPs on day one. "Here's how we do things" is one of the most powerful onboarding messages you can deliver. It communicates professionalism, reduces anxiety, and accelerates productivity.

Tie SOPs to Performance Standards

If following the SOP is optional, it won't happen. Make process adherence part of how you evaluate work quality. This doesn't mean punishing people for deviating -- it means rewarding consistency and using deviations as improvement signals.

Keep SOPs Short and Visual

No one reads a 15-page SOP. The best SOPs are concise, heavily visual (screenshots, flowcharts, short videos), and written at a reading level that matches your team. If a step can be shown in a screenshot instead of described in a paragraph, use the screenshot.

Celebrate Improvements

When someone suggests an improvement to an SOP and it gets implemented, recognize it publicly. This signals that SOPs are living tools, not commandments carved in stone. It encourages the continuous improvement mindset that separates good operations from great ones.

What Tools Should You Use to Create and Manage SOPs?

You don't need specialized software to manage SOPs. In fact, for most businesses under $10M in revenue, the best approach is using tools you already have:

• Google Docs / Notion / Confluence: For writing and storing SOPs. Notion is particularly strong here because it supports templates, databases, and embedded media in a single tool. Confluence works well for teams already in the Atlassian ecosystem.
• Loom / Scribe: For recording screen-based processes. Loom creates video walkthroughs. Scribe automatically generates step-by-step guides with screenshots as you perform a task -- remarkably efficient for documentation.
• Lucidchart / Miro: For creating flowcharts and process maps. These are especially useful for complex processes with multiple decision points and handoffs. (For more on this approach, see our complete guide to process mapping.)
• Your project management tool: For turning SOPs into executable workflows. Asana, Monday.com, and ClickUp all support task templates that mirror your SOPs.

The critical requirement is that your SOP tool integrates with where your team works. Documentation that exists in a separate universe from daily operations gets ignored. Keep everything connected.

How Many SOPs Does a Small Business Need?

There's no magic number, but here's a practical framework. A business with 10-50 employees typically needs SOPs for:

• 5-8 core operational processes (order fulfillment, service delivery, quality control)
• 3-5 customer-facing processes (onboarding, support, complaint resolution)
• 3-5 financial processes (invoicing, collections, expense reporting, month-end close)
• 3-5 people processes (hiring, onboarding new employees, performance reviews, offboarding)
• 2-3 technology/IT processes (access provisioning, business continuity, data backup)

That's roughly 16-26 SOPs to start. It sounds like a lot, but remember: you're not writing them all at once. Start with the top five based on the Impact-Frequency Matrix, then add 2-3 per month. Within six months you'll have a comprehensive library.

A Harvard Business Review study on making process improvements stick found that organizations with documented standard procedures were significantly more likely to sustain operational gains over time. The documentation isn't just useful -- it's the mechanism that prevents process regression.

Common SOP Mistakes to Avoid

After reviewing thousands of SOPs across hundreds of companies, these are the patterns that consistently undermine the effort:

1. Writing from memory instead of observation. We covered this above, but it bears repeating. The ideal SOP and the actual process are often very different. Document what really happens, then improve it.
2. Too much detail in the wrong places. A step like "Click the blue 'Submit' button in the lower right corner" is useful when the interface is confusing. A step like "Open your web browser" is insulting. Match the detail level to the difficulty of the step.
3. No decision trees. If your SOP is purely linear and the real process involves judgment calls, people will stop trusting the document when they hit a scenario it doesn't cover.
4. Written by managers, not practitioners. The person who manages the process and the person who does the process often have very different understandings of how it works. Always involve the doer.
5. No testing phase. If you didn't have someone unfamiliar with the process follow the SOP successfully, you don't know if it works.
6. Storing SOPs in the wrong place. A beautifully written SOP in a Google Drive folder that no one navigates to is wasted effort. Proximity to the work is everything.
7. No review schedule. SOPs without maintenance schedules become outdated and dangerous. Build the review cadence from day one.

Avoid these mistakes and your SOPs will be functional documents that drive consistency -- not shelfware that your team ignores.

How Do SOPs Fit Into the Bigger Picture of Business Operations?

SOPs are one layer of a broader operational system. They sit between strategy (where are we going?) and execution (what are we doing today?). Here's how the layers connect:

1. Strategic goals: Define what you're trying to achieve (grow revenue 40% this year, expand to two new markets)
2. Process architecture: Map the major workflows that drive those goals (operations management, sales processes, service delivery)
3. SOPs: Document how each workflow is executed
4. Automation: Identify which SOP steps can be automated through technology
5. KPIs: Measure whether the processes are producing the right outcomes (operational KPIs tie directly to this)

When all five layers are working together, you have a business that executes consistently, improves continuously, and scales predictably. SOPs are the connective tissue that makes this possible.

If you're ready to move beyond ad hoc processes and build an operation that runs without depending on any single person, SOPs are where you start. If you want to go deeper, our related guides on lean manufacturing principles and operational improvements cover complementary frameworks.

---

Go Deeper: The Operations Efficiency Playbook

If you want a hands-on guide to implementing everything in this article -- including ready-to-use SOP templates, the Impact-Frequency Matrix worksheet, decision tree frameworks, and a 90-day documentation sprint plan -- our Operations Efficiency Playbook walks you through it step by step. It's built for founders and operations leaders who are ready to stop relying on tribal knowledge and start building systems that scale.