Every small business runs on knowledge that lives in someone's head — the owner knows how to close the month, the lead tech knows the install sequence, the office manager knows which invoices can wait. It works until that person is sick, quits, or takes a vacation, and the work either stops or gets done wrong. A standard operating procedure (SOP) gets that knowledge out of one head and onto one page, so the work happens the same good way every time, no matter who does it.
The takeaway up front: a useful SOP is short, written by the person who actually does the work, and stored where the work happens. It is not a binder nobody opens. Write one when a task is repeated, matters when it goes wrong, or needs to be handed off — and skip the ceremony for everything else. Below is a seven-step method, a one-page template with a worked example, and the reasons SOPs fail.
What a standard operating procedure actually is
An SOP is a documented, repeatable set of steps for completing a specific recurring task the same way every time. It answers one question: "How exactly do we do this?" It helps to separate three things people tend to blur together:
- A policy says what is allowed ("we approve refunds under $50").
- A process is the high-level flow across a whole function ("order to cash").
- An SOP is the ground-level instructions for one task inside that flow ("how to issue a refund").
You need all three eventually, but the SOP is where the work actually gets done — and it is the one most small businesses skip. Start there.
When an SOP is worth writing — and when it is overkill
Do not document everything. Documentation costs time to write and to keep current, and an out-of-date SOP is worse than none — once people catch one wrong step, they stop trusting all of them. Write an SOP when at least one of these is true:
- It repeats. Daily, weekly, or monthly — frequency is what makes the write-up pay for itself.
- It is costly when done wrong. A missed step loses a customer, breaks a compliance rule, or costs real money.
- It lives in one person's head. If only one person can do it, you have a single point of failure wearing a name badge.
- You want to hand it off. Delegating, training a new hire, or eventually selling the business all require the work to exist outside your memory.
Skip the SOP for genuinely one-off work or for creative judgment that changes every time — you cannot procedure your way through pricing a bespoke project. And on a small team, resist the enterprise urge to write everything down: a dozen SOPs for your highest-frequency, highest-stakes tasks beat a 200-page manual no one maintains.
How to write an SOP in seven steps
- Pick one task and pin down its edges. Name the exact trigger that starts it and the definition of "done." "Onboard a new client" is a project; "set up a new client in the system once the contract is signed" is an SOP.
- Watch it get done — by whoever really does it. SOPs are usually wrong because a manager wrote them from memory. Sit with the doer or have them narrate as they go; the real process always has steps the memory version forgets.
- Write each step as one action, in order. Start with a verb — open, enter, send, check — and keep one action per line. If a step holds two actions, split it.
- Add the decisions and the gotchas. Where does the person have to choose, and where do people get it wrong? "If the deposit has not cleared, do not schedule — hold and flag." This is what separates a real SOP from a list a beginner cannot follow.
- Name the owner, the tools, and the inputs. Who is responsible, which systems and logins are needed, and what must exist before you start — the answers that otherwise become interruptions at your desk.
- Test it on someone who has never done the task. Hand them the draft, do not help, and watch where they stall. Every stall is a missing or unclear step, and this one test catches most defects.
- Store it where the work happens and set a review date. An SOP in a folder nobody opens is dead. Link it from the tool or ticket where the task lives, and add a "review by" date — quarterly, or whenever the process changes.
Pick the simplest format that works
Match the format to the reader and the stakes, and default to the simplest one that still prevents mistakes:
- Checklist — for experienced people who just need to not miss a step (an end-of-day close, a pre-delivery check). Fastest to write and use; start here.
- Step-by-step with screenshots — for training and handoffs, where the reader has never done the task. More work to maintain, so reserve it for things you teach repeatedly.
- Flowchart — for tasks that genuinely branch on decisions. Use it only when the branching is real; on a linear task it just adds friction.
Default to the checklist because it is the cheapest to keep current, and a current simple SOP beats an elaborate stale one every time.
A one-page template you can copy
Keep it to one page. A workable SOP needs only a short header and a numbered body:
- Title: the task, named as an action
- Purpose: one sentence on why it matters
- Owner: the role responsible, not a person's name — roles outlast people
- Trigger and done when: what starts the task, and the finish line that ends it
- Tools and access needed: systems, logins, files
- Steps: numbered actions, with decisions and warnings written inline
- Last reviewed / review by: two dates
Here it is filled in for client onboarding. Set up a new client. Trigger: signed contract received. Done when: client active and welcome email sent.
- Confirm the signed contract and the deposit are both received. If the deposit has not cleared, hold and flag the account manager — do not proceed.
- Create the client record in the CRM using the naming format "Company – State."
- Copy the intake folder template to the client drive and rename it to match.
- Enter billing details and set the invoice schedule to match the contract terms.
- Assign the account manager and the delivery lead in the CRM.
- Send the welcome email from the saved template and attach the kickoff scheduling link.
- Post "New client live" in the team channel so delivery can begin.
Seven steps, one decision point, one naming standard — a new hire could run it on day one, which is exactly the test a good SOP has to pass. If the steps will not fit on a page, the task is probably several SOPs or a whole process — break it down.
Why SOPs fail — and how to make yours stick
Even well-written SOPs die for predictable reasons:
- Too long. If it reads like a manual, people skim and skip — cut it to the steps that matter.
- Stored where no one looks. Keep it at the point of work, not in a drive nobody opens.
- Never updated. One wrong step and the team stops trusting all of them, so assign an owner and a review date.
- Used as a weapon. If procedures only surface when someone is in trouble, people resent them. Frame them as how you protect time off and make training humane, not as a paper trail for blame.
SOPs are one piece of a well-run operation, not the whole thing. If the underlying workflow is tangled, writing it down just enshrines the mess — untangle the flow first. The operations guide covers finding and fixing the bottleneck before you document anything.
Frequently asked questions
What is a standard operating procedure (SOP)?
A documented, repeatable set of step-by-step instructions for completing a specific recurring task the same way every time. Its job is to move know-how out of one person's head and onto one page, so the work stays consistent no matter who does it and is easy to hand off.
How do I write an SOP?
Pick one task and define its trigger and its "done." Watch the person who actually does the work and capture the real steps as single actions in order. Add the decisions and common mistakes, name the owner and tools, then test the draft on someone who has never done it and fix where they stall.
How long should an SOP be?
Usually about one page. If the steps will not fit on a page, you are probably looking at several SOPs or a whole process — break it down. Shorter, current SOPs get used; long ones get skimmed.
How often should SOPs be reviewed?
On a set cadence — quarterly is a reasonable default for most small businesses — and immediately whenever the underlying task, tool, or policy changes. An out-of-date SOP is worse than none, because one wrong step erodes trust in all the others.
Next step
The businesses that scale, survive a key person leaving, and eventually sell for a fair price share one unglamorous trait: the work does not live only in someone's head. You get there one SOP at a time, starting with your highest-frequency, highest-stakes task. Write that one this week, test it on someone who has never done it, and store it where the work happens. If you want help deciding which procedures to document first, talk to a consultant.
