Every small business has at least one SOP that took a whole weekend to write and has not been opened since. It lives in a folder called “Processes (Final) (v3),” it is eleven pages long, and the new hire it was written for is now training the next new hire by Slack message instead, because reading it takes longer than asking.
That is not a discipline problem. It is a format problem. Most SOPs fail before anyone reads a word of them, because they were built to look thorough instead of to get used.
Free SOP template. Two pages: a blank one-page standard operating procedure template with the five fields explained below, and the same form filled in for client onboarding. The spreadsheet version adds an SOP index, so you can see which procedures are overdue for a review.
What an SOP template actually needs to contain
The U.S. Environmental Protection Agency has run one of the few genuinely rigorous documents on how to write these: EPA QA/G-6, Guidance for Preparing Standard Operating Procedures, first published in 2001 and still the reference for regulated labs and government contractors. Its administrative SOP format has seven parts: title page, table of contents, purpose, scope and applicability, the procedure itself, quality-control checkpoints, and references. It is built for organizations where an auditor may ask to see who approved a document and when.
A ten-person business does not need an auditor. It needs the person covering for someone on vacation to not guess. Strip the EPA format down to what actually earns its place in a small operation, and five parts survive.
| Field | What it captures | You skip it if… |
|---|---|---|
| Trigger | The single sentence that starts the process | Two people would disagree on when this SOP applies |
| Steps | Numbered, in the order they actually happen | You’re past twenty steps (that’s two processes, not one) |
| Owner | One name, not a team | You wrote “team” or “whoever’s available” |
| Tools | Where the work happens, with direct links | You wrote “the CRM” instead of the specific saved view |
| Check | How and how often someone confirms it ran | Nobody would notice for a month if it stopped happening |
Everything else in the official EPA version exists to satisfy a compliance requirement most small businesses do not have.
A sixth field is worth adding once a process has run a few times: exceptions, meaning the two or three ways reality branches from the happy path (the client who pays by wire instead of card, the ticket that needs escalation), each with a one-line instruction. Skip it for a brand-new process. You don’t know the exceptions yet.
A worked example: onboarding a new client, start to finish
Here is what the fields look like filled in, for a process almost every service business runs.
Trigger: contract is signed and the deposit invoice is paid.
- Create the client folder in the shared drive using the naming convention
ClientName_YYYY. - Send the welcome email (template: Onboarding > Welcome) within one business day of payment.
- Add the client to the project management tool with the standard onboarding board template.
- Schedule the kickoff call within five business days; send the calendar invite with the intake form attached.
- Run the kickoff call using the intake form as the agenda; record answers directly into the client’s project brief.
- Set up billing in the invoicing tool with the agreed schedule and payment method.
- Assign the account to its day-to-day owner and tag them in the project board.
- Send the “what to expect in week one” follow-up email 48 hours after kickoff.
- Log the onboarding as complete in the CRM and set a 30-day check-in reminder.
Owner: operations lead (backup: founder, when the ops lead is out).
Tools: shared drive (Clients folder), email template library, project management board, invoicing tool, CRM.
Check: every new client shows “Onboarding: Complete” in the CRM within 10 business days of signing, reviewed weekly during the Monday ops check-in.
Notice what is missing: no screenshots, no explanation of why each step matters, no branding. A new one-page SOP does not need to sell the process to anyone. It needs to answer “what do I do next” faster than a Slack message would.
When you actually need one, and when you’re wasting a weekend
Not every repeated task deserves a document. Three questions decide it, and you need all three to answer yes before you write anything.
Does it happen often enough to be worth writing down? A process you run twice a year is cheaper to re-figure-out each time than to keep updated. Once a month is usually the threshold.
Will more than one person ever touch it? If it will always be you, keeping it in your head is a valid choice for now. Our business systems for entrepreneurs guide covers where that stops being a shortcut and starts being a liability.
Is the cost of it going wrong higher than the cost of writing it down? Payroll, client onboarding, and anything touching money or a legal deadline clear this bar immediately. A process for how you personally format a weekly report to yourself does not.
Answer no to any of the three and skip it. The businesses that drown in documentation usually wrote SOPs for processes that failed all three tests, while the process that actually broke, the one nobody could run without the one person who understood it, never got written down at all.
How to write one without stopping the business for a week
Founders postpone SOPs because they picture a manual. Budget ninety minutes, and follow the process while it happens, not from memory afterward.
Open a blank document the next time the process runs, and write each step as you take it, including the ugly ones: the manual copy-paste into a spreadsheet, the workaround for the tool’s bug. A process description written from memory is the version you wish you ran. One recorded live is the version someone else can actually follow.
Write it as the person doing the work, not the person managing them. A manager describing a process they haven’t done in a year documents it as they remember designing it, which usually differs from how it actually runs today. If you are not the one doing the work, sit with the person who is and write while they narrate.
Stop at “good enough to hand off,” not “perfect.” The first version of a new SOP is a draft that gets corrected the first time someone follows it and hits a step that doesn’t match reality. That correction is not a failure of the first draft. It is the process working.
Keeping SOPs from rotting
An SOP that is accurate the day you write it and wrong six months later is worse than no SOP, because it fails silently: someone follows outdated step 4 and produces the wrong result with total confidence.
Three habits prevent that. Keep every SOP in one place, a single folder or wiki space, never scattered across whichever tool the process happened to touch that week; if people have to remember where to look, they stop looking. Put a date stamp on every document, so a reader can tell a process last reviewed two years ago from one reviewed last month at a glance. And fold the review into a cadence you already run instead of inventing a new ritual you’ll skip. Our weekly review template has room for exactly this, and it maps directly onto system 8, review and improvement, in the business systems framework.
The moment a tool changes, you switch invoicing platforms, the CRM adds a step, the SOP referencing the old tool is not slightly wrong. It is actively misleading. Retire or rewrite it the same week, not “when there’s time.”
Get the free SOP template (PDF + Excel)
We built this as a two-page download. Page one is the blank one-page SOP form with all five fields, plus the optional exceptions field, ready to fill in. Page two is the client-onboarding example above, filled in completely, so you have a finished one to copy the shape of. A matching spreadsheet version adds a running SOP index: name, owner, last reviewed date, and a review-due flag, so you can see at a glance which of your processes have gone stale.
Download the free Standard Operating Procedure Template (PDF) · get the spreadsheet version (Excel / Google Sheets)
Write your first one this week, on the process that would hurt the most if the person who currently holds it in their head took a month off.
Frequently asked questions
What is a standard operating procedure for a small business?
A standard operating procedure is a written, step-by-step description of how to complete a specific repeated task, so the outcome does not depend on who does it or whether the usual person is available. For a small business, the practical version fits on one page and covers five things: what starts the process, the numbered steps, who owns it, what tools it touches, and how you check it ran.
How long should a small business SOP be?
One page for most processes. Seven to twelve numbered steps covers the majority of small-business tasks; past twenty steps, the document is usually two processes that should be split. Length is not a sign of thoroughness. A long SOP is read less often than a short one, which makes it less accurate over time as nobody notices when it drifts from reality.
What is the difference between an SOP and a business system?
A business system is the whole repeatable process: who owns it, what tools it touches, and how it gets checked. A standard operating procedure is the written document describing the steps inside that system, the “how” on paper. A process can have a well-written SOP and still be a weak system if nobody owns it or checks it; the document alone does not make the system work.
How often should SOPs be reviewed and updated?
Review each SOP at least quarterly, and immediately whenever the tool or team member behind it changes. A date stamp on the document makes staleness visible at a glance. Without one, an SOP that is a year out of date looks identical to one updated last week, and someone will follow the wrong step with full confidence.
Do solopreneurs need SOPs?
Only for processes you plan to hand off eventually, or ones where a mistake would be costly even done alone, like tax deadlines, client contracts, or backup routines. A process that will always be just you and changes often is fine to keep in your head; writing it down costs more than it saves until a second person needs to run it.
The bottom line
An SOP earns its place by getting used, not by looking complete. Five fields on one page, trigger, steps, owner, tools, check, beat an eleven-page manual every time, because the one-pager gets opened and the manual gets forgotten. Write the one that would hurt the most if the person holding it in their head disappeared for a month, and write it while you run the process, not from memory afterward.
