Every failed delegation story has the same root cause: the task lived in someone’s head instead of in a document. Standard operating procedures (SOPs) are the unglamorous fix — and the single highest-leverage administrative project a small business can run. This guide shows you how to write SOPs people actually follow, with a template you can copy today.
If you’re deciding what to document first, start with our list of 10 administrative tasks you should be delegating — every task on that list needs an SOP before you hand it off.
Why SOPs beat training sessions
Training transfers knowledge once, to one person, with decay. An SOP transfers it forever, to everyone, with version control. The practical benefits compound:
- Delegation becomes safe. You can hand invoicing to a new assistant in a day instead of shadowing them for a month — which changes the math we walked through in the real cost of outsourcing admin work.
- Errors become system problems, not people problems. If the mistake followed the SOP, you fix the document, not the person.
- Turnover stops being a crisis. When a team member leaves, their successor inherits a manual, not a mystery.
- You discover your own inefficiencies. Half the value of writing an SOP is noticing steps that exist only because “we’ve always done it that way.”
The 7-part SOP template
Copy this structure for every administrative procedure:
1. TITLE — Verb + object: "Process Vendor Invoices"
2. PURPOSE — One sentence: why this exists and what 'done' means
3. OWNER & FREQUENCY — Who runs it, how often, time budget
4. TOOLS & ACCESS — Systems needed + where credentials live
5. STEPS — Numbered, one action per step, with screenshots
6. EDGE CASES — "If X happens, do Y" for the 3-5 known exceptions
7. ESCALATION — When to stop and ask, and whom
The two sections amateurs skip — edge cases and escalation — are the ones that prevent 2 a.m. messages. A procedure that only covers the happy path is a tutorial, not an SOP.
A real example: “Process incoming vendor invoices”
Purpose: Every approved vendor invoice is paid on time and recorded correctly. Done = invoice archived, payment scheduled, ledger updated.
Owner & frequency: Admin assistant, every Tuesday and Thursday, ~45 min.
Steps (abridged):
- Open the
invoices@inbox; filter unread with attachments. - For each invoice: verify vendor exists in the vendor master list. If not → Edge case A.
- Check invoice total against the purchase order. Mismatch → Edge case B.
- Enter into accounting software: date, vendor, category, due date.
- Schedule payment for due date minus 2 business days.
- Move email to
/Processed; save PDF toFinance/Invoices/[Year]/[Month].
Edge cases: (A) New vendor → request W-9, add to master list, then process. (B) Mismatch >$50 → flag to purchasing, do not pay. (C) Duplicate invoice number → check payment history before entering.
Escalation: Any invoice over $5,000, any vendor requesting changed bank details (fraud risk — always verify by phone using the number on file, never the one in the email).
That last line is a real control: payment-redirect fraud is one of the most common attacks on small-business admin teams, and the U.S. Small Business Administration’s guidance for small businesses consistently ranks process controls above software as the first defense.
Writing rules that make SOPs usable
- One action per step. “Log in and download the report and rename it” is three steps pretending to be one.
- Write at “new hire on day one” level. Name the exact button, the exact menu, the exact file path.
- Screenshots beat paragraphs — annotate them with arrows. A screen recording (Loom or similar) per SOP is even better as a companion, but never a substitute: video can’t be skimmed or version-controlled.
- State the trigger. Every SOP starts when something happens: a date, an email, a request. If the trigger is fuzzy, the task silently dies.
- Use checklists for the recurring core. The SOP explains how; a checklist tracks each run. Pilots don’t re-read the manual before takeoff — they run the checklist.
Tooling: keep it boring
- Notion, Google Docs, or Confluence — whichever your team already opens daily. The best SOP tool is the one that requires zero new habits.
- One folder, one naming convention:
SOP — [Department] — [Task name] — v[X]. - A master index page listing every SOP, its owner, and last-review date.
- Version history matters more than aesthetics: when a process changes, update the doc the same day and note what changed.
The maintenance loop (where most SOP projects die)
An SOP that’s wrong is worse than no SOP — people follow it off a cliff or learn to ignore documentation entirely. Build the loop:
- Quarterly 30-minute review per department: scan the index, flag stale docs.
- “Fix it when you hit it” rule: whoever finds an outdated step updates it immediately or comments on the doc.
- New-hire test: every new team member executes their core SOPs literally and logs every point of confusion. A fresh pair of eyes is the cheapest audit you’ll ever get — and it’s how you decide whether a virtual assistant or in-house hire can take the process over next.
Your first week of SOPs: a realistic plan
| Day | Action | Output |
|---|---|---|
| 1 | List your 10 most repeated admin tasks | Prioritized list |
| 2–3 | Write SOPs for the top 3 (use the template) | 3 draft SOPs |
| 4 | Have someone else execute them literally | Confusion log |
| 5 | Fix the gaps, create the index page | v1 library |
Don’t aim for completeness — aim for the three processes that would hurt most if their owner won the lottery tomorrow.
Bottom line: SOPs convert your operations from oral tradition into an asset — one that makes delegation safe, training fast, and growth possible. Write the first three this week using the 7-part template, test them on a real person, and you’ll have built more operational resilience in five days than most small businesses build in five years.