A standard operating procedure, or SOP, is the agreed way to complete a repeated task. It should help a person do the work without guessing. It should not be a long policy file that only the owner understands.
Small teams often wait too long to document work, so a task lives in one person’s head until that person is sick, busy, or leaves. The team then discovers that the “simple process” includes ten small choices nobody wrote down.
The answer is not to document the whole company in one week; choose one task, write one useful page, and test it in real work. A short SOP that gets used is worth more than a perfect manual that gets ignored.
Choose the first process by pain, not prestige
Do not begin with a grand operations manual; begin with a task that happens often and creates visible friction. Good first choices include sending a new client invoice, approving a refund, publishing a blog post, handing a sales lead to delivery, or closing a customer complaint.
Score each possible task with three questions:
- How often does the task happen?
- How costly is a mistake or delay?
- How much does the work depend on one person?
Start with the task that scores high across all three, because this gives the team a quick result and shows whether your method works before you use it on harder processes.
A sales handoff can be a strong first choice. It affects the customer, the delivery team, and your forecast. It also connects with the need to build a sales forecast from real information, not hopeful notes.
Write six parts on one page
A simple SOP needs enough detail to guide the work, but not so much that the steps hide inside paragraphs. Use these six parts.
| Part | Question it answers | Example |
|---|---|---|
| Purpose | Why does this process exist? | Move a signed client from sales to delivery without missing scope or payment details. |
| Trigger | What starts the work? | The signed agreement and deposit appear in the shared system. |
| Owner | Who is responsible for the result? | The account manager owns the handoff. |
| Steps | What happens, and in what order? | Create the project, attach the agreement, confirm dates, and book the kickoff. |
| Proof | How do we know it is complete? | The delivery lead accepts the handoff checklist. |
| Exceptions | What happens when the normal path breaks? | Missing deposit: pause setup and notify the account manager. |
Add a version number, an owner, and a review date at the top; these small details stop old copies from becoming the default and give people a clear place to send a correction.
Use action verbs and one decision per step
Write each step as a direct instruction. Start with a verb: open, check, record, send, approve, or stop. “The invoice should be checked” is weaker than “Check the client name, amount, due date, and purchase order before sending.”
Penn State Extension recommends short sentences and direct commands because they are easier to understand. Its writing guide also suggests matching the format to the work: simple steps for short routines, a layered format for longer jobs, and a flowchart when the user must make many decisions.
That gives a small business a useful rule:
- Use a checklist when the path is short and stays the same.
- Use steps with substeps when beginners need more detail.
- Use a flowchart when each answer changes the next action.
Do not squeeze a risky or complex process onto one page just to meet a format. Health and safety work, regulated work, and tasks with serious financial impact may need training, controls, and expert review. The UK Health and Safety Executive says procedures should be clear, concise, accurate, and owned by the people who use them. It also warns that a procedure alone is not always enough to control risk.
Record the real process before you improve it
Owners often write the process they wish the team followed, which creates a clean document and a messy reality. Watch the task once and ask the person doing it to talk through each choice, then capture the files, tools, approvals, and checks they actually use.
Then remove waste. Combine duplicate checks. Delete steps that no longer change the result. Name the one system that holds the final record. If the team moves the same data through email, chat, and a spreadsheet, the SOP should not hide that problem.
This matters when you add automation or AI. A tool can speed up a clear step, but it can also repeat a bad step much faster. Fix the workflow and execution plan first, then decide which part a tool should handle.
Test the SOP with a cold reader
The writer should not be the only tester, so give the page to a team member who knows the business but not the task and ask them to follow it exactly. Do not rescue them as soon as they pause; record the point where they became unsure.
Look for four types of failure:
- Missing input: The reader cannot find a file, login, approval, or customer detail.
- Hidden decision: The step says “review” but does not say what passes or fails.
- Unclear owner: Two people assume the other person will act.
- No finish line: The work feels done, but no record proves it.
Penn State’s implementation guide recommends testing a procedure by doing each step exactly as written and involving the workers who perform the task. That simple test turns an SOP from a manager’s description into a working tool.
Give every process an owner and review signal
An SOP becomes stale when nobody owns it. The owner does not need to perform every step, but must keep the page accurate and respond when the process fails. That boundary matters because a manager who agrees to every request cannot protect the process or the team’s capacity.
Use both a fixed review date and event-based review. Check the page every six or twelve months, depending on risk. Review it sooner when a tool changes, a customer complaint exposes a gap, a rule changes, or the team creates a workaround.
Track one useful measure. For a client handoff, that might be the share of handoffs accepted without missing information. For refunds, it might be the average time from request to decision. A measure shows whether the process became easier, not just whether the document exists.
A one-page SOP template
Copy this structure into the tool your team already opens. A shared document is enough for the first version.
- Title: Use the name people use in conversation.
- Purpose: One sentence about the result.
- Trigger: The event or input that starts the work.
- Owner: One role responsible for completion.
- Inputs: Files, access, approvals, or data needed.
- Steps: Five to ten numbered actions, each starting with a verb.
- Proof: The saved record, approval, or output that confirms completion.
- Exceptions: The stop rule and person to contact.
- Version and review date: The current version, owner, and next check.
Keep the first version plain. Add screenshots only when they remove doubt. Add a short video only when movement or screen order matters. The page should remain the source of truth, so the team can scan it and find the current rule. For a publishing workflow, connect the SOP to one clearly chosen marketing channel instead of adding every platform at once.
Frequently asked questions
What does SOP mean in a small business?
An SOP is a standard operating procedure. It records the agreed way to complete a repeated task, including who owns it, which steps to follow, and what result proves the work is done.
How long should a small-business SOP be?
Start with one page for a simple task. Use a longer guide or flowchart when the work has many decisions, safety risks, or more than about ten steps.
How often should an SOP be reviewed?
Review it after a failed handoff, a tool or rule change, and on a fixed date. The owner should confirm that the written steps still match the real work.