SOPs That Actually Get Followed (Not Filed and Forgotten)

Why Most SOPs Fail

Founders write SOPs after a mistake. The SOP prevents a repeat of that specific mistake but doesn’t help the team execute the task efficiently. Three failure patterns:

1. Written as prose, not checklists. Wall-of-text SOPs are unusable during actual work. Nobody reads 2,000 words to execute a 5-minute task.
2. Stored in isolation. SOPs in a “SOPs folder” die there. If you have to remember to look them up, you don’t.
3. No owner. Without a named owner, SOPs go stale within 6 months. Stale SOPs are worse than no SOPs, they train the team to distrust documentation.

The 5-trait format below fixes all three.

The 5 Traits of SOPs That Get Followed

Trait 1: Written for the Person Doing the Job

Test: Would a new hire on day 3 be able to execute the task using this SOP alone?

If yes, it’s written for the doer. If no, it’s written for the auditor or compliance reviewer.

How to write for the doer: - Use imperative voice (“Click Save,” not “The user should click Save”) - Include specific tool names and menu paths (“In HubSpot → Contacts → Filters”) - Include screenshots showing exactly what to click - Include example inputs and outputs - Include timing expectations (“This step takes 2-3 minutes”)

Trait 2: Formatted as Checklists

Structure: - Numbered steps (1, 2, 3…) - Each step is one action - Sub-steps are indented - Checkboxes so the executor can track progress - Bold on the exact button, field, or action

Example step:

1. In the deal record, click **Set Stage** → select **"Qualified"**. - If deal value is over $10K, also add tag "Enterprise" - Timing: ~30 seconds

Avoid: Multi-action steps (“Click Save and then update the field and notify the manager”). Break into separate steps.

Trait 3: Include Screenshots or Short Videos

Rule: Any step that involves clicking a specific button, menu, or field should include a screenshot.

Format: - Annotate the screenshot with arrows or circles - Keep image size reasonable (nobody wants to scroll past a full-screen screenshot) - For complex workflows: link a 30-90 second Loom video

Tools: - Screenshots: Cleanshot X, Snagit, ShareX - Annotations: Canva, or the same screenshot tool - Videos: Loom, Descript - Embedded into: Notion, Google Docs, ClickUp Docs, Confluence

Rule: If you can’t find the right button because the SOP has no screenshot, the SOP failed.

Trait 4: Has a Named Owner

Every SOP should have: - Owner: the person accountable for keeping it current - Last updated: the date it was last reviewed - Review cadence: quarterly, semi-annually, or annually - Version history: dates and summary of changes

Owner responsibilities: - Update when the underlying tool or process changes - Add clarifications when team members report confusion - Review on the scheduled cadence - Retire the SOP when the process is deprecated

Rule: No named owner = SOP will decay. Assign an owner to every SOP or don’t write it.

Trait 5: Lives Where the Work Happens

Bad location: A “SOPs” folder in Google Drive that nobody opens.

Good locations: - Linked directly inside the project template in Asana/ClickUp/Notion - Embedded in the tool where the work happens (e.g., inside HubSpot’s task templates) - Bookmarked in the team’s daily workflow - Referenced in onboarding automation

Rule: SOPs should be reachable in one click from wherever the team is doing the work.

The Plug-and-Play SOP Template

[SOP Title - Specific Task]Owner: [Name]Last updated: [Date]Review cadence: [Quarterly / Semi-annually / Annually]Time to execute: [X minutes]---WHEN TO USE THIS SOP[1-2 sentences describing the trigger - when should someone start following this?]WHO USES THIS SOP[Role or team member type]TOOLS NEEDED- [Tool 1]- [Tool 2]---STEPS1. [First action] - Detail or note - [Screenshot if useful]2. [Second action] - [Screenshot]3. [Third action] [continues...]---TROUBLESHOOTINGIf [common issue]: [what to do]If [common issue]: [what to do]---WHEN TO ESCALATEEscalate to [role] when:- [Situation 1]- [Situation 2]---RELATED SOPs- [Link]- [Link]---VERSION HISTORY- [Date]: [Change summary] - [Author]

Use this template for every SOP. Consistency matters more than perfection.

How to Prioritize Which SOPs to Write First

Don’t try to document everything. Prioritize using the “frequency × pain” matrix:

High frequency + high pain if done wrong → Write first. Examples: client onboarding, invoice processing, lead qualification.

High frequency + low pain → Write second. Examples: routine reporting, standard follow-ups.

Low frequency + high pain → Write third. Examples: contract execution, offboarding, security incidents.

Low frequency + low pain → Don’t document. Handle case-by-case.

Rule: A team of 10 needs 20-40 well-written SOPs, not 200 mediocre ones.

Building an SOP Library in 90 Days

Weeks 1-2 (Discovery): - Interview each team member: “What tasks do you do most often?” - List every recurring process - Score each on frequency × pain

Weeks 3-6 (Write): - Write 4-8 SOPs per week - Prioritize highest-frequency, highest-pain first - Test each with 1 team member before finalizing

Weeks 7-9 (Integrate): - Link SOPs into project templates - Embed in tool workflows - Train team on where to find them

Weeks 10-12 (Optimize): - Track which SOPs get accessed (many tools show this) - Interview team: which SOPs helped? Which didn’t? - Revise the underperforming ones

Outcome: 20-40 SOPs in production, actively used, with named owners.

SOP Maintenance and Owners

SOPs die without maintenance. Prevent decay:

Quarterly review: - Owner reviews their SOPs each quarter - Confirms the process still matches reality - Updates screenshots if the tool UI changed - Notes any team feedback

Trigger-based updates: - Tool change → update within 1 week - Process change → update immediately - Team feedback about confusion → update within 1 week

Retirement process: - Some SOPs eventually become obsolete - Retire them with a note explaining why - Keep in an archive for reference

Metrics: - Access count (are people opening it?) - Update frequency (has the owner touched it recently?) - Team NPS (“was this SOP helpful?”)

Common Mistakes

1. Writing SOPs before doing the task yourself. Founders sometimes write SOPs for processes they’ve never executed. Result: SOPs are wrong. Do the task, take notes, then write the SOP.
2. Documenting every step at the same level of detail. Some steps are obvious (“open email”). Some need detail. Match detail level to complexity.
3. Not testing with a real user. Every SOP should be tested by someone who didn’t write it. Their first-attempt experience reveals gaps.
4. Writing SOPs in prose. Prose loses the reader. Checklists survive.
5. No screenshots. For any tool-based process, the SOP without screenshots is 3x slower to execute than the SOP with them.
6. Never revising. SOPs are living documents. If you write them once and never touch them, they die.

FAQ

How long should an SOP be? Depends on the task. Simple 5-minute tasks: 1 page. Complex 30-minute workflows: 3-5 pages including screenshots. If you need more than 5 pages, break the task into multiple SOPs.

Should SOPs be in Notion, Google Docs, or somewhere else? Where your team already works. Notion is best if the team lives in Notion. Google Docs is fine if that’s the standard. ClickUp Docs and Asana docs are good if your PM tool is those. The rule: SOPs should be one click from the work.

Who should write SOPs, founders or team members? The person who does the task most often should write the first draft. Founders can review and edit but shouldn’t be the primary writer for team-level tasks. Founder-written SOPs often miss the small details doers know.

How do I know if my SOPs are working? Track: access count (are people opening them?), team feedback (“did this help?”), and error rate (do errors drop when SOPs are followed?). If access is low, the SOPs aren’t being found, fix location. If access is high but errors persist, the SOPs aren’t clear, fix content.

Do I need SOPs for a team of 3? For high-frequency high-pain tasks (client onboarding, sales handoffs, financial processes): yes. For everything else: no. A team of 3 usually needs 5-10 SOPs, not 40.

Key Takeaways

SOPs fail when written as prose, stored in isolation, and unowned.

5 traits of SOPs that get followed: written for doers, formatted as checklists, include visuals, have owners, live where work happens.

A team of 10 needs 20-40 well-written SOPs, not 200 mediocre ones.

The plug-and-play template covers when-to-use, tools, steps, troubleshooting, escalation, related SOPs, and version history.

SOPs die without owners and quarterly reviews. Don’t write them without an owner.

If you’d like Octo Partners to build your SOP library including prioritization, writing, and integration into your workflow tools, book a free Strategy Call. We build SOP systems that reduce onboarding time by 40-60% and lower error rates measurably.