How to Write SOPs: The Complete Guide for Small Business (2026)

Table of Contents

1. What an SOP Actually Is (vs. Policy, Checklist, Work Instruction)
2. When You Need an SOP — and When You Don’t
3. Picking Your First Process
4. Extracting the Process From a Subject-Matter Expert
5. Choosing Your Format: Prose, Checklist, Flowchart, or Video
6. The 7-Section SOP Template
7. Writing Each Step Well
8. The “Smart New Hire” Review Pass
9. Templates vs. Starting From Scratch
10. Getting Your Team to Actually Use SOPs
11. Maintaining SOPs Over Time
12. Tools and Software
13. Two SOP Examples, End to End

---

Most small businesses that try to document their processes fail at the same three points: they don’t know where to start, they write steps too vaguely to be useful, and the documents sit unused within six months.

This guide is not a list of “SOP best practices.” It is the full playbook — from the decision to start, through picking the right process, extracting the knowledge, writing it clearly, getting your team to use it, and keeping it current. Each section links to a deeper post in this series if you want more on a specific step.

If you run a business with five to 150 employees and you’re tired of being the person who has to answer every question and fix every mistake, this is the right starting point.

---

1. What an SOP Actually Is {#what-an-sop-actually-is}

A standard operating procedure is a step-by-step document that describes how a specific task is done, by whom, and to what standard. That definition is easy to recite and easy to get wrong in practice — so let’s separate it from three things it’s often confused with.

SOP vs. Policy

A policy says what must happen (“all customer refunds must be approved by a manager”). An SOP says how it happens (“open the refund queue, verify the order number against the receipt, click Approve, then send the customer the refund confirmation template”). Policies set rules. SOPs describe work. Most small businesses need more SOPs and fewer policies — but confuse the two constantly, which is why their documentation is full of rules that nobody knows how to execute.

SOP vs. Checklist

A checklist is a shorter, task-specific tool — usually a subset of an SOP, or the final verification pass at the end of one. An SOP for opening a retail location might include a checklist as its last step (“verify each item on the daily opening checklist before unlocking the door”). Checklists are useful. They are not the same as an SOP, and substituting one for the other produces documentation that is either too shallow or too crowded.

SOP vs. Work Instruction

A work instruction is the most granular level — it zooms in on one specific subtask and explains exactly how to do it, often with photos or diagrams. SOPs reference work instructions; they don’t replicate them. If your SOP has 40 steps because you’re documenting the keystroke-by-keystroke operation of a piece of equipment, you’ve written a work instruction nested inside an SOP. Split them out.

The practical test: if a smart person who has never done this job could follow your document and get the right outcome on their first try, you’ve written something useful — whatever you call it.

---

2. When You Need an SOP — and When You Don’t {#when-you-need-an-sop}

Not everything needs an SOP. Some processes are simple enough that a brief note or a short onboarding conversation is sufficient. Writing an SOP for tasks that never cause problems or variation is documentation theater — you’ve produced a document nobody reads because nobody needed one.

An SOP is worth the time when at least two of these are true:

• The task repeats. If you do it once a year with low stakes, an SOP is probably overkill. If you do it weekly with five different people, it’s essential.
• Mistakes in this process are costly. Costly means: expensive to fix, harmful to the customer relationship, a compliance risk, or dangerous. Higher cost of error = higher value of a documented standard.
• The process has multiple steps with specific sequence or decision points. If anyone could reasonably do the steps in the wrong order and get the wrong outcome, that’s a process that needs documentation.
• New people regularly need to learn it. If training always requires one-on-one time with your best employee, you have a scalability problem that only a documented process solves.
• The task is currently done inconsistently across your team. Variance in output usually traces back to variance in process. Documenting the correct process — and then enforcing it — closes the gap.

Common signals you need SOPs right now: the same question gets asked more than twice, a key employee leaving would be a crisis, or quality varies noticeably depending on who does the work.

---

3. Picking Your First Process {#picking-your-first-process}

The hardest part of starting an SOP library is not writing — it’s choosing where to begin. Most owners who stall do so because they’re trying to decide between 30 candidates simultaneously.

The right first process meets three criteria:

1. It causes real pain right now — the kind you feel weekly, not annually.
2. The documentation effort is bounded — you can finish a solid draft in two to four hours.
3. The payoff is immediately visible — your team will notice and use it.

The four-factor scoring method: rate each candidate 1–5 on (a) repetition frequency, (b) cost of errors, (c) training time currently required, and (d) cross-team dependency. Sum the scores. The highest number is your first SOP.

Common starting points for most small businesses: new employee onboarding, client intake or sales follow-up, order fulfillment or service delivery, end-of-day or end-of-week closing procedures, and quality checks on high-stakes deliverables.

For a full breakdown of how to score and rank your candidates, read Where to Start: How to Pick the First Process to Document in Your Business.

---

4. Extracting the Process From a Subject-Matter Expert {#extracting-the-process-from-a-subject-matter-expert}

Once you’ve picked the process, you need to get it out of the person who actually knows how to do it. This is harder than it sounds, for a structural reason: the person who performs the process best is usually the person who can explain it least clearly. Expertise creates compression — they skip steps because the steps are automatic.

If you hand your best employee a blank doc and ask them to “write up how you do it,” you’ll get one of three results: a vague paragraph, a perfect doc three weeks late, or nothing.

The fix is to separate the extraction from the writing. The expert does the work while someone else documents it. Four methods that work:

Method 1: Shadow and transcribe. Sit beside the expert while they do the task. Ask them to narrate what they’re doing. You write the steps. Debrief for exceptions and edge cases at the end. Takes 30–60 minutes for most processes.

Method 2: The 30-minute interview. Walk through the process verbally using a structured question set: “What’s the trigger for this process?”, “What do you need before you start?”, “Walk me through the steps in order,” “What’s the most common mistake you see?”, “What would you tell a new person to watch out for?” Record and transcribe. The owner writes the draft from the transcript.

Method 3: Screen recording + narration. For software workflows, have the expert screen-record themselves doing the task while narrating what they’re clicking and why. The resulting video is both an asset and a transcription source. Loom, Scribe, and Tango are all viable tools for this.

Method 4: Process shadowing log. For physical processes, have the expert keep a sticky note nearby for one week and jot down anything they did that they’d want a new hire to know. At the end of the week, you interview them from the notes.

For a full 30-minute interview script and decision matrix on which method to use, read How to Get Knowledge Out of Your Team’s Head.

---

5. Choosing Your Format: Prose, Checklist, Flowchart, or Video {#choosing-your-format}

The format is not a style preference. The wrong format for a process type makes the SOP harder to use, not easier. Here is how to match them:

Numbered step list — the default format for most SOPs. Use it when: the process is linear, the sequence matters, and each step is discrete. Works for 70% of small business processes. A numbered list forces you to be specific and gives readers a clear progress indicator (“I’m on step 4 of 9”).

Prose paragraphs — use only for context sections, not for step-by-step instructions. The overview, purpose, and scope sections of an SOP can be prose. The steps themselves should not be. Prose buries the executable information inside reading comprehension work.

Checklist — use when the process is already familiar to the operator and the goal is verification, not instruction. Pre-flight checklists, daily close checklists, quality-review checklists. If someone needs a checklist to be taught the process, they need an SOP first and a checklist as a companion tool.

Flowchart or decision tree — use when the process has significant branching based on conditions (“if the return is over $100, escalate to a manager; if under, process directly”). Decision-heavy processes are hard to read in linear step format and much easier to follow visually. Tools: Lucidchart, Miro, even a simple Markdown table.

Video — use for physical processes, spatial layouts, or high-motor-skill tasks where text and images genuinely can’t capture the work (food prep, equipment operation, surgical technique in a medical SOP). Video is high production cost and high maintenance cost. Don’t default to video because it feels easier to make than to write. The maintenance burden is real: when the process changes, you have to re-record the whole thing instead of editing one line.

Hybrid — the most effective format for most SMB SOPs is a numbered step list with embedded screenshots and a companion checklist at the end for experienced operators who just need the verification pass. Build the numbered list first. Add the checklist once the SOP has been tested.

---

6. The 7-Section SOP Template {#the-7-section-sop-template}

Every SOP, regardless of format, should answer seven questions. These are not bureaucratic checkboxes — each section exists because operators and managers ask these questions in practice, and a document that forces them to hunt for the answer will be abandoned.

1. Purpose

One to three sentences. Why does this process exist? What goes wrong when it’s not followed?

Example: “This process ensures every new client receives the same onboarding experience within 48 hours of signing. Without it, clients have been missed or received incomplete setup, leading to cancellations in the first 30 days.”

2. Scope

Who does this apply to? When does it apply? What does it explicitly exclude?

Example: “Applies to all customer-facing staff. Required for every new client sign-up. Does not apply to renewals or plan upgrades, which follow the Account Expansion SOP.”

3. Owner

One person by role (not name) is responsible for this process being followed and updated. If nobody owns it, nobody maintains it.

Example: “Process Owner: Customer Success Manager”

4. Inputs

What do you need before you can start? Materials, information, access, tools. Listing inputs prevents people from starting a process only to discover halfway through that they’re missing something.

Example: “Signed contract, client contact details, provisioning access to the client portal, welcome email template in Shared Templates folder.”

5. Steps

The numbered list of actions in the correct order. One action per step. Action verb first. See Section 7 for how to write each one.

6. Outputs

What does a successfully completed process produce? What does “done” look like?

Example: “Client fully configured in the portal, welcome call scheduled, and client record marked ‘Active’ in the CRM.”

7. Exceptions and Escalations

What should someone do when they hit an edge case the SOP doesn’t cover? Who do they escalate to? What common exceptions have you already identified?

Example: “If the client has not responded to the welcome email within 72 hours, escalate to the Account Manager. If provisioning fails, stop and contact IT before proceeding.”

---

7. Writing Each Step Well {#writing-each-step-well}

The difference between an SOP draft and a working SOP usually comes down to step quality. Most first drafts contain steps like these:

• Verify the order is correct.
• Make sure the customer gets what they need.
• Process the return as appropriate.

None of those are executable. Someone reading them will still have to make multiple judgment calls that the original expert would have made automatically. The knowledge is still in someone’s head — it’s just been summarized badly.

The three rules for executable steps:

Rule 1: Action verb first, every time. Each step begins with a specific verb: Click, Open, Enter, Select, Confirm, Call, Email, Print, Sign, Attach, Upload, Verify, Check. Not “Make sure,” not “Ensure that,” not “You will need to.” Those phrases bury the action in hedging language. “Click the green Approve button in the upper-right corner of the Returns screen” is a step. “Ensure the return has been approved” is a hope.

Rule 2: One action per step. If a step contains “and then,” it’s two steps. Split it. A long numbered list of single-action steps is much easier to follow than a short list of multi-action steps. Readers can lose their place in the latter; they can’t in the former.

Rule 3: Add a screenshot or photo for any visual step. If the step involves a button, a screen element, a physical object, or a spatial layout, add an image. A screenshot with an arrow pointing at the relevant element eliminates the support question before it’s asked. A phone photo of the correct workstation setup means the new hire doesn’t have to guess. You don’t need professional equipment. A screenshot with a red circle is sufficient.

Decision points need branches. When a step leads to one of two different next steps depending on a condition, write it explicitly: “If the return amount is under $50, proceed to Step 7. If it is $50 or more, complete the Manager Approval Form (in the Shared Forms folder) before proceeding.” Unwritten decision points are where new hires improvise incorrectly.

Name specific tools, systems, and locations. Not “the CRM” — “HubSpot.” Not “the shared folder” — “the Google Drive folder at Operations > Onboarding > Client Templates.” Specificity is what makes the difference between a step someone can follow the first time and a step that requires a follow-up question.

---

8. The “Smart New Hire” Review Pass {#the-smart-new-hire-review-pass}

Before you publish any SOP, run it through this test: Could a smart person who has never done this job follow this document and get the right outcome on their first attempt, without asking anyone a question?

That question reveals most of the gaps in a first draft. Here is the four-check refinement pass:

Check 1: Every step starts with an action verb. Scan the numbered list. Any step that starts with “You,” “Make sure,” “Verify that,” or “It’s important to” needs to be rewritten. Rewrite it as a command.

Check 2: No step requires prior knowledge you haven’t stated. Read each step as if you’ve never seen the software, the form, the room, or the tool. If a step assumes the reader knows what “the approval queue” is, define it or link to where it lives.

Check 3: Every decision point has a branch. Search for conditional language — “if,” “depending on,” “unless,” “when applicable.” Each conditional should have a named next step for each outcome.

Check 4: The exceptions section covers the top two or three real-world edge cases. Ask the subject-matter expert: “What’s the most common mistake you see when someone new does this?” Write down the answer and put it in the exceptions section, or add a “Common Mistakes” note at the relevant step.

The goal is not a perfect document — it’s a document that works for a new person on day one. If it passes the smart-new-hire test, publish it. You can improve it later.

For a full refinement checklist with a before/after example, read How to Turn a Rough Draft Into an SOP Your Team Will Actually Follow.

---

9. Templates vs. Starting From Scratch {#templates-vs-starting-from-scratch}

Using a template saves 60–80% of the time it takes to write an SOP — but only when the template closely matches your actual process.

The decision comes down to one question: how much of the template structure maps directly onto what you do? If you’re a restaurant and you’re documenting the opening procedure, a restaurant opening SOP template will have the right categories, the right sequence, and the right level of detail. You’ll fill in your specifics and be done in an hour.

If you’re a consulting firm documenting your custom project intake process, a generic project management SOP template will spend your time on deletion and rewriting rather than actual documentation. Start with a blank 7-section structure (see Section 6 above) and build the steps directly.

When to use a template:

• Your industry or role type is common enough that templates exist (restaurants, dental offices, cleaning companies, agencies, accounting firms)
• The template covers a category you haven’t thought through before and would benefit from a structured starting point
• You need something usable quickly and accuracy on edge cases is lower priority

When to write from scratch:

• Your process is genuinely distinctive — you’ve built something that doesn’t match the standard way this type of business operates
• The template requires more deletion and rewriting than filling in
• The process is internal and specific to your systems, tools, and team structure

For the full decision matrix, read Should You Use an SOP Template or Write From Scratch?

What’s the Process For maintains an industry template library that covers restaurants, dental offices, cleaning companies, agencies, churches, accounting firms, and more. If your industry is there, starting from a template is the faster path.

---

10. Getting Your Team to Actually Use SOPs {#getting-your-team-to-actually-use-sops}

This is the step most owners skip, and it’s why SOP libraries go unused. The assumption is: if you write clear SOPs and store them somewhere accessible, the team will use them. That assumption is usually wrong.

Adoption is not a technology problem. The team does not need a better Wiki, a different folder structure, or a new app. Adoption is a behavior problem — and the behavior you’re trying to create (consult the SOP before doing the task) requires near-zero friction and consistent reinforcement in the first two weeks.

The four root causes of adoption failure, and their fixes:

Cause 1: The document is not where the work happens. If accessing the SOP requires five steps and a folder search, people will not do it in the middle of a task. The fix is to put the SOP where the work is — a QR code on the equipment, a pinned link in the Slack channel where that work gets coordinated, a shortcut on the workstation desktop.

Cause 2: The manager doesn’t use it either. If you, as the owner, still answer the question verbally instead of saying “that’s covered in the onboarding SOP, let me show you where it is,” you’ve communicated that the SOPs are optional. The fix is to stop being the answer. Point to the document every single time, without exception, for the first two weeks.

Cause 3: The SOP is wrong and nobody wants to say so. If your team found one error and didn’t report it, they concluded the document was unreliable and stopped trusting it. The fix is to make the update process trivially easy — a comment box, a Slack message, a standing agenda item — and visibly fix reported errors fast.

Cause 4: There’s no consequence for not following the process. If following the SOP and ignoring the SOP produce the same outcome (no feedback, no accountability), most people will take the path of least resistance. The fix is not punishment — it’s making “check the SOP” part of your performance feedback, onboarding evaluation, and quality reviews.

For the complete adoption playbook, read Why Your Team Ignores Your SOPs (And How to Fix Adoption).

---

11. Maintaining SOPs Over Time {#maintaining-sops-over-time}

A stale SOP is worse than no SOP. When your team finds that the document is wrong — and they will, because processes change — they stop trusting the whole library. One bad document contaminates the credibility of everything else you’ve written.

The solution is not an annual documentation blitz. It’s a lightweight maintenance system with three components:

1. The update trigger. SOPs should be reviewed and updated whenever: a tool changes (you switched CRMs, the software updated), a process changes (you found a better sequence, a vendor changed their workflow), or a mistake pattern emerges (three people made the same error at the same step). Put the update process in writing: who reports the change, who makes the edit, how quickly.

2. The “Last Reviewed” stamp. Every SOP should display the last-reviewed date prominently. A document that was last reviewed 18 months ago signals to any reader that it might not be current. A document reviewed three weeks ago signals reliability. This stamp also gives you a simple audit list: sort your library by last-reviewed date and work your way through the oldest ones quarterly.

3. The quarterly light audit. Once a quarter, run through every SOP with a question: “Did anything change in this process in the last 90 days?” This takes about 30 minutes for a library of 15–25 SOPs. If the answer is no, update the reviewed date. If the answer is yes, schedule the update within two weeks.

For a full maintenance playbook including review cadences and deprecation criteria, read How to Keep Your SOPs Current.

---

12. Tools and Software {#tools-and-software}

Where you store and run your SOPs matters more than most business owners realize. Not because the tool creates the quality — it doesn’t — but because accessibility and maintenance are behavioral problems as much as organizational ones.

The main categories of SOP tools and what each one actually does well:

Google Docs / Word — free, familiar, and completely acceptable if your library is small (under 20 documents) and your team is disciplined. The failure modes are navigation (people can’t find things in a big folder structure) and freshness (no alerts when documents go stale).

Notion / Confluence — more structured than Docs. Good for teams that want wiki-style organization with cross-linking between documents. Still requires discipline to maintain. Neither tool has built-in SOP training tracking or assignment workflows.

Purpose-built SOP and training platforms — tools like What’s the Process For, Trainual, SweetProcess, and Process Street are designed specifically for SOPs plus training. They add role-based assignments, completion tracking, onboarding portals, and maintenance reminders. The tradeoff is cost and setup time. For a 10–50 person team that wants to actually enforce and track SOP use, a purpose-built tool pays for itself in the time saved managing the library manually.

Screen capture tools (Scribe, Tango, Loom) — these are SOP creation tools, not storage systems. Scribe auto-generates step-by-step guides from screen recordings. They’re excellent for software-process SOPs and can produce a first draft in minutes. They don’t replace a training layer — you still need to assign the SOP to the right people, track completion, and update when the software changes.

For a full comparison of eight tools with pricing and honest assessments of who each one is for, read The Best SOP Software in 2026.

---

13. Two SOP Examples, End to End {#two-sop-examples-end-to-end}

Reading principles is helpful. Seeing them applied is more useful. Here are two complete SOP examples — one for a service business, one for an office process — written in the 7-section format.

---

Example 1: New Client Intake — Bookkeeping Firm

Purpose Ensure every new client completes setup and receives their first deliverable within five business days of signing. Without this process, clients have been lost or stalled during setup, causing first-month cancellations.

Scope Applies to all bookkeeping staff. Required for every new engagement signed. Does not apply to existing clients who are upgrading their plan.

Owner Operations Manager

Inputs

• Signed engagement letter (PDF, stored in Client > [Name] > Agreements)
• Completed new client questionnaire (link: [Client Questionnaire form])
• Access to QuickBooks Online as an Accountant user
• Access to the practice management system (Karbon or equivalent)

Steps

1. Create the client folder in Google Drive under Clients > [Client Last Name, First Name].
2. Move the signed engagement letter to Clients > [Name] > Agreements.
3. Open the practice management system and create a new client record. Enter the client name, entity type, tax ID, fiscal year end, and primary contact.
4. Send the welcome email using the “New Client Welcome” template (Shared Templates > Client Onboarding). Personalize the first paragraph with the client’s name and the specific services they signed up for.
5. Accept the QuickBooks Online invite or set up a new QBO account under their email. Connect the client’s bank accounts within 24 hours of receiving login credentials.
6. Run the New Client Setup Checklist (see attached) to verify: chart of accounts configured, bank feeds active, historical period agreed.
7. Schedule the kickoff call within three business days of signing. Use the Kickoff Call Template in Shared Templates.
8. After the kickoff call, mark the client status as “Active” in the practice management system.
9. Set a reminder in the practice management system for the first monthly deliverable due date.

Outputs Client folder created, record active in the practice management system, bank feeds connected, kickoff call completed, first deliverable reminder set.

Exceptions

• If the client does not respond to the welcome email within 48 hours, follow up by phone. If no response within five business days, escalate to the Partner.
• If QBO access has not been granted within 72 hours of signing, contact the client directly for credentials before proceeding to Step 5.

---

Example 2: Customer Refund Process — E-Commerce Store

Purpose Process every customer refund correctly and completely the first time, within 24 hours of the request. Incorrect refunds have resulted in duplicate refunds and chargebacks.

Scope Applies to all customer service staff. Required for all refund requests regardless of order size. Returns over $200 require manager approval before processing.

Owner Customer Service Lead

Inputs

• Customer refund request (email or support ticket)
• Original order number (provided by customer or found in help desk system)
• Access to the e-commerce admin panel
• Access to the payment processor (Stripe or PayPal dashboard)

Steps

1. Open the refund request in the help desk system and locate the original order number in the customer’s message or in their account history.
2. Open the e-commerce admin panel and search for the order by order number.
3. Verify the order: confirm the customer name matches the account, the order status is “Fulfilled,” and the item(s) requested for refund were included in this order.
4. Check the refund eligibility: confirm the order date is within the 30-day return window. If outside the window, go to Step 10 (Exceptions).
5. If the return is under $200: click Refund in the order detail screen. Select the items to be refunded. Enter the refund amount. Click Confirm Refund.
6. If the return is $200 or more: do not process yet. Fill out the Refund Approval Form (Shared Forms > Refunds) and send it to your direct manager. Wait for written approval before proceeding.
7. After processing (or receiving approval), open the help desk ticket. Send the customer the Refund Confirmation email using the “Refund Processed” template. Include the expected processing time (3–5 business days for credit card refunds, 1–3 business days for PayPal).
8. Mark the help desk ticket as Resolved.
9. Log the refund in the Refund Tracker spreadsheet (Shared > Operations > Refund Tracker): date, order number, amount, reason, and who processed.

Outputs Refund processed in the payment system, customer notified by email, ticket resolved, refund logged in the tracker.

Exceptions

• Orders outside the 30-day window: do not process a refund. Send the “Outside Return Window” response template and close the ticket.
• Suspected fraud (mismatched name, multiple refund requests for the same order): do not process. Escalate to the Customer Service Lead immediately.
• Duplicate refund risk: before processing, search the Refund Tracker for the same order number. If a refund was already processed, contact the customer to clarify before taking any action.

---

Where to Go From Here

A single SOP does not fix a disorganized operation. But a single SOP done well — clear steps, an honest review pass, published where your team can find it, assigned to the right people — demonstrates that documentation works and makes the next one easier.

The pattern that works for most small businesses: write one SOP, get it into use, update it after the first month of real-world feedback, then use what you learned to write the next one faster.

If you’re ready to start building your SOP library in a tool that handles the assignment, tracking, and maintenance overhead, What’s the Process For was built specifically for SMBs that want a complete system without enterprise pricing. See how it’s priced or start a free trial — no credit card required.

The processes are already running in your business. Writing them down is just the work of making what already exists repeatable by someone other than you.