Building SOPs That People Actually Follow

The SOP Problem

Most SOPs are written by managers, for auditors, and ignored by the people who actually do the work. They're too long, too abstract, and too far removed from the actual task. The result: tribal knowledge persists, onboarding is slow, and quality is inconsistent.

What Makes a Good SOP

A good SOP answers one question: "If I've never done this before, what exactly do I do?"

It should be:

• Action-oriented — Steps, not concepts
• Visual — Screenshots, diagrams, or short videos where possible
• Tested — Written by someone who does the task, then verified by someone who doesn't
• Living — Updated when the process changes, not when someone remembers

The SOP Writing Framework

1. Observe First

Before writing anything, watch someone do the task. Note every step, decision point, and edge case. Ask "why" at each step — if the answer is "that's how we've always done it," that's a process smell worth investigating.

2. Write in Second Person

Use "you" not "the operator" or "the team member":

Do: "Click the Sync button in the top-right corner." Don't: "The user should initiate synchronization via the interface."

3. Number Every Step

No paragraphs of instructions. Numbered steps, one action per step:

1. Open the dashboard at app.example.com
2. Navigate to Settings → Integrations
3. Click Add Integration
4. Select Slack from the list
5. Paste the webhook URL
6. Click Test Connection
7. If the test succeeds, click Save

4. Include Decision Trees

Real processes have branches. Use simple if/then formatting:

• If the test connection fails → Check the webhook URL for trailing spaces
• If it still fails → Generate a new webhook in Slack and retry
• If it fails a third time → Escalate to the engineering team in #ops-support

5. Add Error Handling

Every SOP should include a "When things go wrong" section:

• Common errors and their fixes
• Who to contact
• Expected resolution time
• What to tell the customer (if applicable)

SOP Structure Template

# [Process Name] **Owner:** [Role/team responsible] **Last Updated:** [Date] **Review Cycle:** [Quarterly / Monthly] ## Purpose [1-2 sentences: why this process exists] ## Prerequisites - [Access/permissions needed] - [Tools required] ## Steps 1. ... 2. ... ## Common Issues - [Error] → [Fix] ## Escalation - Contact: [Role/Slack channel] - SLA: [Response time]

Tools for SOP Management

Don't use Word documents in a shared drive. Use a system that supports:

• Version history
• Search
• Inline comments
• Embeddable media

Good options: Notion, GitBook, or even a well-organized GitHub repo with Markdown files.

Adoption Tips

The best SOP is useless if nobody reads it. To drive adoption:

1. Include SOPs in onboarding — New hires should complete tasks using only the SOP
2. Make them searchable — A single source of truth that's easy to find
3. Review in retrospectives — When something goes wrong, ask "did the SOP cover this?"
4. Reward feedback — If someone spots an outdated step, celebrate it
5. Keep them short — If an SOP exceeds 2 pages, break it into sub-processes

Measuring SOP Effectiveness

Track these metrics quarterly:

• Onboarding time for new team members on SOP-covered tasks
• Error rate for processes with SOPs vs. without
• Update frequency — SOPs updated in the last 90 days
• Search/usage analytics — Which SOPs are actually being read

SOPs are infrastructure for your operations team. Invest in them the way you'd invest in code quality — iteratively, with tests, and with a bias toward clarity over completeness.