How long should an SOP be?

As short as it can be while a new person can still finish the task without asking for help. Most business SOPs fit on one or two screens; if yours runs longer, it is usually two processes and should be split.

Who should write an SOP?

The person who does the task well should supply the knowledge, but they do not have to do the typing. Someone else can interview them and draft it, as long as the expert reviews and approves the final version.

What is the difference between an SOP and a checklist?

A checklist is one format an SOP can take. An SOP also carries the purpose, scope, owner and any context the steps need; a checklist is the list of steps on its own.

How often should SOPs be reviewed?

Set a review interval based on how fast the process changes: quarterly for anything tied to software or pricing, once or twice a year for stable processes. Also review immediately whenever the tool or the rule behind a step changes.

How to Write an SOP for Your Business (With Template)

Most SOPs fail in one of two ways. Either they never get written because nobody knows where to start, or they get written once, in a burst of good intentions, and nobody reads them again. This guide is about avoiding both. It walks through a method you can use for any repeatable task in your business, from sending an invoice to onboarding a client, and it ends with a template you can copy.

A note on the phrase: “how to write an SOP” also gets used for the statement of purpose in university applications. This guide is about the business kind.

What an SOP is (and what it is not)

An SOP (standard operating procedure) is a written, step-by-step set of instructions for completing a recurring task the same way every time, so that anyone with the right access and training can do it correctly without asking the person who usually does it. A good SOP names the task, says when it applies, lists the steps in order and states what “done” looks like.

An SOP is not a policy (a rule about what is allowed), and it is not a process map (the big-picture flow across several people). It sits between them: specific enough to follow, broad enough to cover the whole task. If you want the full breakdown of those terms, see SOP vs process vs work instruction vs policy.

Before you write: pick the right process

The first SOP you write should be one that pays you back quickly. Good candidates share a few traits:

It happens often. Weekly or monthly tasks give the SOP a chance to earn its keep.
Mistakes are expensive or embarrassing. Payroll, invoicing, client handoffs and anything customer-facing.
Only one person knows it. If that person is out sick, the task stops.
You are about to hand it off. A new hire or a promotion is the natural moment to write it down.

Avoid starting with a process that is still changing every week. Let it settle, then document it.

How to write an SOP in eight steps

1. Name the task and the outcome

Write a title that starts with a verb and names the thing: “Send a monthly client invoice,” not “Invoicing.” Then write one sentence describing the finished state: “The client has received a correct invoice and it is logged in the accounting system.” That sentence becomes your test later. If someone follows the steps and does not reach that state, the SOP is wrong.

2. Define the scope and the trigger

Answer three questions in a line or two each:

When does this start? The trigger, such as “the first business day of each month” or “a signed proposal comes back.”
What is included? Where the SOP begins and ends.
What is excluded? Anything that belongs in a different SOP, like handling a disputed invoice.

Scope keeps an SOP from swelling into a manual.

3. Get the knowledge out of the expert

The best source is the person who does the task well today. There are three reliable ways to capture what they know:

Interview them. Ask them to walk you through the last time they did it. Keep asking “then what?” and “how do you know when that is done?”
Watch them do it. Sit beside them, or have them record their screen while narrating. You will catch steps they skip without noticing.
Start from what exists. Old emails, a notes doc, a half-finished checklist. Treat it as raw material, not the answer.

Experts leave out the steps that feel obvious to them. Those are the steps a new person gets stuck on, so your job is to ask the naive questions. If typing is the bottleneck, SOPCompass’s AI assistant can run this interview for you by text or voice, ask the follow-up questions and draft the SOP; you approve every change before it is saved.

4. Write the steps

Now turn the notes into steps. A few rules keep them readable:

One action per step. If a step has “and then” in the middle, split it.
Start each step with a verb. “Open,” “Check,” “Send,” “Record.”
Say where. Name the tool, the screen, the folder or the field.
Put decisions in plain if/then form. “If the client is on annual billing, skip to step 6.”
Include the check, not just the action. “Confirm the total matches the signed proposal.”
Keep the why short. A single clause of reasoning helps people handle edge cases. A paragraph of history does not.

Aim for the smallest number of steps that a competent new person could follow. Most business SOPs land somewhere between five and fifteen.

5. Add what the steps need

Around the steps, add only what helps someone do the task:

Owner: the person responsible for keeping this SOP accurate.
Who performs it: a role, not a name, so it survives turnover.
Tools and access: logins and permissions needed before starting.
Screenshots or a short video for anything that happens in software.
Related SOPs: what comes before and after.

For the full list of standard sections and when to use a checklist versus a flowchart, see our guide to SOP format.

6. Test it with someone who has never done it

This is the step most people skip, and it is the one that matters most. Hand the SOP to a person who has never done the task and watch them follow it without help. Every time they hesitate, ask a question or open a different tab to look something up, you have found a gap. Fix it on the spot.

If there is no one new available, have the expert follow their own SOP literally, word by word. It is surprising how quickly they spot missing steps when they cannot rely on memory.

7. Publish it where the work happens

An SOP in a folder nobody opens does not exist. Put it where people look when they are doing the task: in a shared library organized by business area, linked from the tool itself, or assigned directly to the person who needs it. Tell the people who perform the task that it exists, and ask them to use it the next time.

8. Assign an owner and a review date

Every SOP goes stale eventually. A tool changes, a price changes, a step gets added in practice but never on paper. Give each SOP a named owner and a review interval, and put the next review on a calendar. When anyone spots something wrong, they should know exactly who to tell. Our page on keeping SOPs current covers this in more depth.

A worked example: sending a monthly client invoice

Here is what the method produces for a common small-business task. The business is an invented example: a small design agency that bills its clients monthly.

Title: Send a monthly client invoice

Purpose: Every active client receives a correct invoice on time, and it is recorded so payment can be tracked.

Trigger: First business day of each month.

Scope: Retainer clients on monthly billing. Disputed invoices and one-off project invoices are covered in separate SOPs.

Performed by: Operations coordinator. Owner: Finance lead. Review: Every quarter.

Tools: Accounting system, the client contracts folder, the time-tracking tool.

Steps:

Open the active clients list in the accounting system and filter to “monthly retainer.”
For each client, open their signed contract and note the monthly amount and any agreed extras.
Export last month’s billable hours for that client from the time-tracking tool.
If billable hours exceed the retainer allowance, add the overage as a separate line at the contract rate.
Create the invoice from the client’s saved template. Check the billing contact email against the contract.
Confirm the total equals the retainer plus any overage. If it does not, stop and ask the finance lead.
Send the invoice from the accounting system, not from personal email, so it is logged.
Record the invoice number and send date in the monthly billing sheet.
Set a reminder for the payment due date.

Done when: Every monthly client has a sent invoice logged in the billing sheet.

Notice what makes this usable. Every step starts with a verb, names the tool and ends in something checkable. The one decision point (overage hours) is written as a clear condition. The stop rule in step 6 tells a new person exactly when to ask for help, which is often the most valuable line in the whole SOP.

For nine more condensed examples from HR, sales, marketing and support, see 10 SOP examples from real business functions, and for a ready-made version of this one, the invoicing and collections SOP template.

An SOP template you can copy

Copy this structure into whatever tool you use. You can also start from our full standard operating procedure template, which includes guidance for each section.

Title: [Verb + object, e.g. "Process a customer refund"]
Purpose: [One sentence: what is true when this is done correctly]
Trigger: [What starts this task, and how often]
Scope: [What is included / what is covered elsewhere]
Performed by: [Role]
Owner: [Role or person responsible for accuracy]
Review interval: [e.g. quarterly]
Tools and access: [Systems, logins, permissions]

Steps:
1. [Verb + action + where]
2. [...]
   If [condition], then [action].
3. [...]

Done when: [The checkable end state]
Related SOPs: [Before / after]

Common mistakes when writing SOPs

Writing it from memory alone. The expert’s memory skips steps. Always watch, record or walk through the task while writing.

Documenting the ideal instead of the real. If the SOP describes how the task should work but the team does it differently, people will ignore the document. Write what works today, then improve it in a later version.

Too much text. Long paragraphs hide the steps. If a section is not something the reader does or checks, cut it or move it to a linked page.

Names instead of roles. “Ask Dana” breaks the day Dana leaves. Write “ask the finance lead.”

Vague verbs. “Handle,” “process” and “deal with” tell the reader nothing. Replace them with the actual action.

No stop rule. Say when to pause and ask for help. Without it, new people either guess or give up.

No owner. An SOP without an owner is out of date the moment something changes, and nobody notices.

Writing everything at once. A big documentation push usually produces a pile of drafts and burnout. Write one SOP per week for your most important processes and you will have a real library within a few months. Our guide on how to document business processes covers how to plan that rollout.

Quick checklist before you publish

The title starts with a verb and names the task.
The purpose sentence describes a checkable end state.
The trigger and scope are stated.
Every step is one action that starts with a verb.
Decision points are written as if/then.
There is a clear rule for when to stop and ask.
A person new to the task has followed it successfully.
It has an owner, a review interval and a home where the team will find it.

If you have a backlog of processes and not much time, the fastest route is usually to talk rather than type. With SOPCompass you can describe a process out loud, review the draft, and assign it to the people who need it with a due date so you can see who has read it. Whether you use a tool or a shared document, the method above is what makes an SOP worth having.