A standard operating procedure, or SOP, is a written set of steps for doing one task the same way every time. Refunding a customer. Closing the shop. Publishing an invoice. Onboarding a new hire.
Small businesses usually have plenty of procedures and almost none of them written down. The steps live in the head of whoever does the task most often, which works until that person is away, leaves, or simply gets asked the same question for the tenth time.
The catch is that writing an SOP is easy, but writing one that people actually follow is not. Most SOPs die one of two deaths: they are so long that nobody reads them, or so vague that nobody can act on them. This guide covers a structure that avoids both, with a worked example you can copy.
When a task deserves an SOP
Not everything needs a procedure. A task earns an SOP when at least two of these are true:
- More than one person does it, or will need to.
- It has to be done the same way every time, because mistakes cost money, trust, or compliance headaches.
- It happens on a schedule or a trigger, like end of month, a new client signing, or a complaint arriving.
- Someone asks how to do it more than once.
If a task is done by one person, rarely, and the stakes are low, skip it. Documentation has a cost, and spending it where it pays is the difference between a useful library and a graveyard.
The 6-part structure
Every good SOP answers six questions, in this order. Keep each part as short as it can honestly be.
1. Purpose (one sentence). What this procedure achieves and why it matters. "Refund customers within 48 hours so complaints never escalate."
2. Trigger. When exactly to run it. "A customer requests a refund by email, phone, or in person."
3. Owner. Who is responsible for the task, and who keeps this document current. One name each, not a department.
4. Steps. Numbered actions, each starting with a verb, each doable without asking anyone anything. This is the heart of the SOP and the part most worth your editing time.
5. Edge cases. The two or three situations where the steps do not apply, and what to do instead. Resist documenting every possibility; name the common exceptions and say who decides the rest.
6. Links. The actual tools, forms, and templates the steps mention. A step that says "fill in the refund form" must link the refund form.
A worked example
Here is the structure applied to something real. Notice how little ceremony it needs.
SOP: Processing a customer refund
Purpose: Refund customers within 48 hours so complaints never escalate.
Trigger: A customer requests a refund through any channel.
Owner: Task: whoever receives the request. Document: Maria.
Steps:
- Confirm the purchase in the billing system using the customer's email.
- Check the purchase date. Within 30 days: proceed. Older: see edge cases.
- Issue the refund in the billing system to the original payment method.
- Reply to the customer using the "refund confirmed" email template.
- Log the refund and reason in the refunds sheet.
Edge cases:
- Purchase older than 30 days: ask Maria before refunding.
- Amount over $500: Maria approves first, same day.
Links: billing system, refund email template, refunds sheet.
That is the whole document. A new hire could run it on their first day, which is the test that matters.
Writing rules that keep SOPs followable
- Write it while doing the task. Do the task once with a document open and write each step as you perform it. SOPs written from memory skip the steps the writer no longer notices.
- One verb per step. "Check the date and issue the refund and email the customer" is three steps wearing one number. Splitting them makes progress visible and mistakes traceable.
- Name the click, not the concept. "Mark the invoice as paid in the billing system" beats "update the financial records".
- State the finish line. The last step should make it obvious the task is done, like a log entry or a confirmation sent. Ambiguous endings are where procedures quietly fall apart.
- Read it aloud once. Anywhere you stumble, a reader will too.
Keeping SOPs alive
An SOP is wrong the day the process changes, and processes change constantly. Two habits keep your library trustworthy:
- Update as part of the change. When you change how a task works, updating the SOP is the final step of the change itself, not a cleanup job for later.
- Stamp a review date. A "last checked" line at the top tells readers how much to trust the document and tells the owner when it is due a skim. Quarterly is plenty for most small teams.
Where the SOPs live matters as much as how they are written. Procedures scattered across drives and inboxes get rewritten from scratch because nobody could find the original. They belong in your team's shared knowledge base, in one searchable place alongside your policies and templates. If you have not set one up yet, our guide on building a knowledge base for a small business covers it step by step.
Frequently asked questions
How long should an SOP be? As short as it can be while letting a new hire complete the task alone. Most small business SOPs fit on one page. If it runs past two, it is probably several procedures stapled together; split them.
What is the difference between an SOP and a process document? In practice, nothing worth debating. Some teams use "process" for the high-level flow and "SOP" for the step-by-step instructions. Use whichever word your team already says, and spend the energy on the steps instead.
What format should SOPs be in? A living document your team can search, link, and update beats a PDF or a printed binder. Version-controlled documents in a shared workspace mean the current version is always the one people find.
Who should write SOPs? The person who does the task, with a second person test-driving the draft. The doer knows the real steps; the tester catches the assumed knowledge the doer forgot to write down.
Ready to write yours? Start from an SOP template so the structure is done before you type a word.