SOPs that actually get used

SOPs. Standard Operating Procedures, are the documented "how we do this." They exist on paper at most businesses and in reality at few. The gap between the two is where quality, training time, and institutional knowledge all leak out.

Why SOPs matter

• Onboarding, new hires get up to speed on specific processes without hours of 1:1 time
• Consistency, the 100th customer gets the same quality as the 1st
• Delegation, you can hand work off without reinventing the explanation
• Quality control, deviations from SOP get noticed and investigated
• Company value, documented operations are worth more when you sell

Why most SOPs fail

• Written by a consultant who doesn't do the job
• So generic they don't help
• Outdated within 3 months
• Stored somewhere nobody looks
• No one's accountable for keeping them current
• Too long to read before just asking someone

The rules of useful SOPs

1. Written by the person who does the job

The person with the fingers on the keyboard is the only one who actually knows the steps. The manager writes a framework; the operator fills in the details.

2. Short > complete

A 2-page SOP someone reads beats a 50-page SOP nobody opens. When in doubt, cut.

3. Actionable, not theoretical

"Monitor customer satisfaction" is not a step. "At the end of every onboarding call, send this survey link" is.

4. Include screenshots, videos, real examples

Text alone doesn't cut it for software-mediated work. Loom videos where you perform the task beat 40 bullet points every time.

5. Versioned + dated

Every SOP has: last-updated date, owner, review date. Older than a year without review? Probably stale.

6. One place to live

Notion page. Wiki. SharePoint. Pick one. Everyone finds SOPs the same way. "Which Google Drive folder was the onboarding SOP in again?" = SOPs aren't being used.

The SOP template

TITLE: [What this SOP covers]
OWNER: [Who maintains this]
LAST UPDATED: [Date]
NEXT REVIEW: [Date]

WHEN TO USE THIS SOP
[One-paragraph description of the situation this covers]

OUTCOME
[What "done" looks like]

STEPS
1. [Specific action]
2. [Specific action]
   - Sub-step or nuance
3. [Specific action]
...

COMMON ISSUES + FIXES
- Problem X → do Y
- Problem Z → escalate to [person]

RELATED SOPs
- Link
- Link

The adoption loop

1. Write it, the operator drafts, the manager reviews, one round of edits.
2. Test it, someone else follows the SOP to complete the task. Notes every place they had to ask a question.
3. Update based on test, fill in the gaps found.
4. Publish, land in the wiki, link from relevant onboarding docs.
5. Review quarterly, the owner confirms it's still accurate. If they can't, someone else inherits.

When to create an SOP

• The second time you're about to explain the same thing
• Before onboarding a new person to a role
• When a process spans 3+ people or 3+ steps
• When there's a compliance or safety element
• When the person who does the work might leave

When NOT to create one

• Truly one-off tasks
• Creative work that varies per instance
• Work that's changing rapidly (write a rough doc, wait until it stabilizes)

Signs your SOP library is working

• New hires reach productivity faster
• Manager time spent on "how do I…" questions drops
• Handoffs don't lose quality
• Audit trails exist when something goes wrong

Signs it's not

• SOP library exists but nobody references it
• Same questions get asked repeatedly
• SOPs are drastically different from actual practice
• Nobody knows who owns updating them