Most SOPs get ignored. Here's the one-page format, ownership model, and review cycle that makes documentation stick. Includes 3 real examples.
How to Write SOPs Your Team Will Actually Follow (Not Just File Away)
You spent a weekend writing SOPs. Beautiful Google Docs. Detailed steps. Screenshots with red circles and arrows. You even added a table of contents.
You shared them with the team on Monday morning. "Here are our new SOPs - please review by end of week."
Nobody reviewed them by end of week. Nobody reviewed them by end of month. Three months later, people are still doing things their own way. The documents sit untouched in a shared drive folder that half the team doesn't know exists.
Sound familiar?
You're not alone. Most companies have an SOP graveyard somewhere - a folder full of painstakingly written procedures that nobody reads, nobody follows, and nobody updates. We've seen it at agencies, SaaS companies, service businesses, and every other type of operation we've worked with.
The problem isn't your team. It's the SOPs.
Why Your SOPs Get Ignored
There are exactly five reasons SOPs get filed away and forgotten. Every company we've audited hits at least three.
1. They're Too Long
A 15-page document for a 10-minute task is not an SOP. It's a novel. Nobody reads a novel to figure out how to process a refund.
We worked with a 20-person agency last year that had an 11-page SOP for client onboarding. Eleven pages. The actual process had 7 steps and took 30 minutes. The other 10.5 pages were background context, edge cases that happened once in 2019, and screenshots of a tool they stopped using.
When we asked the team how they onboarded clients, they said: "I ask Jordan."
Jordan was the SOP.
2. No Visual Aids
Walls of text don't work. They didn't work when you were in school and they don't work now. Your team looks at a dense paragraph describing a multi-step process and their brain checks out.
This is especially true for software-related SOPs. Describing where to click in a paragraph is absurd when a 2-minute screen recording shows the exact thing.
3. No Clear Owner
"The team" doesn't own SOPs. "Operations" doesn't own SOPs. If everyone owns it, nobody owns it. Nobody feels responsible for keeping it accurate. Nobody notices when it drifts from reality.
Unowned SOPs decay. Fast. Within 90 days, an unowned SOP is probably wrong about at least one step.
4. Never Updated
An outdated SOP is worse than no SOP. Way worse.
No SOP means people ask questions and figure out the current process. An outdated SOP means people confidently follow the wrong process. They reference a tool you canceled. They send things to an approval chain that doesn't exist anymore. They skip a step that was added six months ago.
If your SOP references Basecamp and you switched to ClickUp a year ago, that SOP is actively harmful.
5. Never Trained On
You shared a Google Doc link in Slack and assumed people would read it. They didn't. Sharing a document is not training. It's filing.
Training means walking someone through the SOP. Watching them do it. Answering questions. Correcting mistakes in real time. If that sounds like a lot of work, that's because training is work - and skipping it is why your SOPs collect dust.
Cedar's One-Page SOP Format
After building operational systems for dozens of companies, we've landed on a format that actually sticks. The constraint is deliberate: if your SOP doesn't fit on one page, you either don't understand the process well enough or you're documenting two processes in one document.
Here's the template:
SOP: [Name of the process - plain language, not a code]
Trigger: [What event kicks this off? Be specific.]
Owner: [Full name of the person who maintains this SOP]
Last Updated: [Date - if this is more than 90 days old, review it]
Video Walkthrough: [Loom/video link - optional but highly recommended]
STEPS:
1. [Verb] [specific action]
2. [Verb] [specific action]
3. [Verb] [specific action]
4. [Verb] [specific action]
5. [Verb] [specific action]
(Maximum 10 steps. If you need more, split into two SOPs.)
TOOLS NEEDED:
- [Tool 1] - [link]
- [Tool 2] - [link]
IF SOMETHING GOES WRONG:
- [First thing to try]
- [Who to escalate to, with contact method]
The rules:
- Under 10 steps. If your process has 14 steps, you have two processes pretending to be one. Split them. We covered this principle in depth in our guide to standard operating procedures - the short version is that complexity kills compliance.
- Every step starts with a verb. "Open," "Send," "Check," "Upload," "Notify." Not "The invoice should be reviewed." That's passive. That's vague. "Review the invoice for line-item accuracy" tells someone exactly what to do.
- Trigger is mandatory. People need to know when to use the SOP, not just how. "When a new client signs the contract" is a trigger. "Client onboarding" is a category.
- Owner is a name, not a title. "Marketing Manager" isn't an owner. "Sarah Chen" is an owner. Titles change. Names are accountable.
- Last updated date is visible. If someone sees "Last Updated: March 2024," they know to verify before following it.
- One page. Period. If you can't explain it in one page, you don't understand it well enough. This is the same principle behind effective work instructions - clarity requires compression.
Three Real SOP Examples
Theory is easy. Here are three filled-out SOPs from actual business contexts. These aren't hypothetical - they're based on real processes we've built for clients, with details changed.
Example 1: Agency Client Delivery QA
SOP: Client Deliverable QA Check
Trigger: Any deliverable is ready to send to a client
Owner: Maria Torres
Last Updated: 2026-02-15
Video Walkthrough: [Loom link - 4 min]
STEPS:
1. Open the deliverable in its final format (not the working file)
2. Check all client branding: logo placement, colors, fonts
3. Run spell check and read every headline out loud
4. Verify all links work by clicking each one
5. Confirm deliverable matches the scope in the project brief
6. Compare against the client's last round of feedback
7. Export/screenshot and post in #qa-review Slack channel
8. Get written approval from project lead before sending
9. Send to client via the agreed channel (email/portal, not Slack DM)
TOOLS NEEDED:
- Project brief - [ClickUp link]
- Brand guidelines - [Google Drive link]
- #qa-review channel - [Slack link]
IF SOMETHING GOES WRONG:
- Found an error after sending → notify project lead within 15 min
- Client flags an issue → acknowledge within 2 hours, fix within 24
- Unsure if something meets brand standards → ask, don't guess
Why this works: the trigger is clear (any deliverable, before it goes out), the steps are sequential, and the escalation path is specific. A junior designer can follow this on day one.
This is the kind of QA process that separates agencies doing $500K from agencies doing $2M. We break down the full progression in agency SOPs by revenue stage.
Example 2: SaaS Customer Onboarding Follow-Up
SOP: New Customer Onboarding Follow-Up Sequence
Trigger: Customer completes initial setup (status changes to "Active" in CRM)
Owner: Jake Winters
Last Updated: 2026-02-10
Video Walkthrough: [Loom link - 3 min]
STEPS:
1. Verify account setup is complete in the admin dashboard
2. Send Day 1 welcome email (template: "Onboarding - Welcome")
3. Schedule the 15-minute kickoff call within 48 hours
4. Send kickoff agenda 24 hours before the call
5. Complete the kickoff call - walk through 3 quick wins
6. Send Day 3 check-in email (template: "Onboarding - Quick Wins")
7. Send Day 7 follow-up with first usage report
8. Log all touchpoints in CRM with dates and notes
TOOLS NEEDED:
- CRM - [HubSpot link]
- Email templates - [HubSpot sequences link]
- Usage dashboard - [internal tool link]
- Call scheduling - [Calendly link]
IF SOMETHING GOES WRONG:
- Customer doesn't respond to Day 1 email → follow up by phone on Day 2
- Customer misses kickoff call → reschedule within 24 hours, send quick-start video
- CRM status didn't update → check with engineering, log manually
Why this works: the trigger is a system event, not a vague "when someone signs up." The timeline is specific (Day 1, Day 3, Day 7). And the failure modes are real - people miss emails and skip calls. The SOP accounts for that.
Example 3: Service Business Quality Control
SOP: Post-Service Quality Control Check
Trigger: Technician marks job as "Complete" in dispatch system
Owner: Dana Kim
Last Updated: 2026-01-28
Video Walkthrough: [Loom link - 5 min]
STEPS:
1. Pull the original work order and review scope
2. Compare completed work against every line item in the scope
3. Take 4 photos: before (from file), after (front), after (detail), any concerns
4. Upload photos to the job record in dispatch system
5. Run the 6-point checklist (posted in every truck and in the app)
6. Call the customer within 2 hours and ask 3 questions:
- "Was the work completed to your satisfaction?"
- "Was there anything we missed?"
- "Can I schedule your next service?"
7. Log the call outcome and any follow-up needed
8. If score is below 4/5, flag for manager review within 24 hours
TOOLS NEEDED:
- Dispatch system - [ServiceTitan link]
- Photo upload app - [link]
- 6-point checklist - [Google Doc link]
- Customer call script - [Google Doc link]
IF SOMETHING GOES WRONG:
- Customer unreachable → try again next business day, then email
- Quality issue found → schedule return visit within 48 hours, waive fee
- Photos missing → technician must return to site same day
Why this works: it combines documentation (photos), verification (checklist), and customer feedback (the call) into one short flow. The technician doesn't need to read a manual. They follow 8 steps. Done.
The Video Layer
Here's a pattern we see constantly: a team ignores a written SOP for months. The same SOP gets recorded as a 4-minute Loom video. Suddenly everyone follows it.
People watch videos. They don't read documents. Not because they're lazy - because video is a better medium for showing how to do things.
For every SOP you write, record a 3-5 minute Loom walking through it.
Here's the format that works:
0:00 – 0:15 What this process is and when you use it
0:15 – 0:30 Open the tools you'll need
0:30 – 3:30 Walk through each step, actually doing it on screen
3:30 – 4:00 Common mistakes and how to avoid them
4:00 – 4:15 Who to ask if you're stuck
Record it in one take. Don't script it. Don't edit it. Perfection is the enemy of adoption - a rough video people watch beats a polished video you never record.
The numbers speak for themselves. At one client (28-person service company), we tracked SOP engagement for 60 days:
- Written SOPs: opened an average of 3 times per month
- Video SOPs: viewed an average of 22 times per month
Same content. Same processes. 7x more engagement because of the format.
Add the Loom link to your one-page SOP template in the "Video Walkthrough" field. Now people have a choice: read the steps or watch the video. Most will watch. That's fine. The written version exists for quick reference after they've learned the process.
The Ownership Model
Every SOP needs one owner. One person. Not a team. Not a department. A name.
The owner's job:
- Keep it accurate. When the process changes, the owner updates the SOP within one week. Not "eventually." Not "when they have time." Within one week.
- Train new hires. When someone new joins and needs to use this SOP, the owner walks them through it. Not their manager. Not HR. The owner - because they know the process cold.
- Review quarterly. Every 90 days, the owner re-reads the SOP and asks: "Is this still how we actually do it?" If yes, update the date. If no, rewrite it.
- Delete if unused. If nobody referenced the SOP in 90 days, the owner either promotes it (maybe nobody knows it exists) or kills it (maybe the process doesn't need documentation).
No owner = no SOP. If you can't name the person responsible, don't write it. It'll be outdated in 90 days and wrong in 180.
Who should own what? Start with whoever does the process most often. Not their manager. Not the person who designed the process. The person who actually does it every day. They know the real steps, the real gotchas, and the real shortcuts.
At smaller companies (under 15 people), the founder often owns all the SOPs. That's fine - just put your name on them and block 2 hours quarterly to review them. As you grow, hand ownership to the people closest to the work. We outline exactly how this handoff works at different revenue stages in the agency operations playbook.
The Quarterly Review Cycle
SOPs without a review cycle decay into fiction. Within 6 months, at least half your SOPs will describe a process that no longer exists.
Here's the rotation we use with clients:
Month 1: Review all delivery/fulfillment SOPs
Month 2: Review all admin/finance SOPs
Month 3: Review all sales/marketing SOPs
Repeat.
Each review takes 30-60 minutes. You're not rewriting from scratch - you're reading each SOP and asking three questions:
- Is this still how we do it? If a step changed, update it. If a tool changed, update the link. If the owner left, assign a new one.
- Did anyone use it? If the answer is "I don't think so," find out why. Maybe nobody knows it exists. Maybe the process is intuitive enough that it doesn't need documentation. Either promote the SOP or delete it.
- Is the video still accurate? If the written SOP changed, the video needs to be re-recorded. A video showing the old process is worse than no video at all.
Put the review on your calendar. Not a to-do list - a calendar event with a reminder. Quarterly reviews that aren't scheduled don't happen. If you're running a full operations audit, fold the SOP review into that process.
Track what you find. Keep a simple log:
Date | SOP Reviewed | Action Taken
-----------|---------------------------|---------------------------
2026-01-15 | Client Delivery QA | Updated step 4 (new portal)
2026-01-15 | Invoice Processing | Deleted - fully automated now
2026-01-15 | Client Offboarding | Re-recorded Loom, new owner
2026-02-12 | Expense Approval | No changes, date updated
2026-02-12 | Payroll Processing | Added step for new state tax
2026-03-15 | Lead Qualification | Updated scoring criteria
2026-03-15 | Proposal Creation | New owner: Alex (Jamie left)
This log takes 2 minutes to maintain and gives you a clear record of what's current and what's been touched.
How to Roll This Out Without Overwhelming Your Team
Don't write 30 SOPs in a weekend. That's the Big Bang approach, and it fails every time.
Here's the rollout that works:
Week 1: Pick your 5 most painful processes. The ones that cause mistakes, require you to answer the same question repeatedly, or fall apart when someone's out sick. Write one-page SOPs for all five. Record Loom videos for all five.
Week 2: Train the team on those 5 SOPs. Not "share the docs and hope." Actually walk through each one. Have people do the process while you watch. Answer questions. Fix unclear steps on the spot.
Week 3: Assign owners. Put quarterly review dates on the calendar. Add the SOPs to wherever your team already looks - Slack pinned messages, Notion homepage, browser bookmarks. Not buried in a folder.
Week 4: Check adoption. Are people using them? Ask. If not, find out why. Too long? Unclear trigger? Can't find them? Fix the problem. Don't just re-share the link.
Then stop. Five SOPs, properly written and actually trained on, will do more for your operations than 50 SOPs nobody reads. Add more only when a real problem demands it.
Start Here
The best SOPs are the ones people use. Not the most comprehensive ones. Not the most detailed ones. The ones that are short enough to read, clear enough to follow, and current enough to trust.
Start with 5. One page each. A Loom video for each one. Train your team on them - don't just share a link. Assign an owner. Review quarterly.
Everything else is overthinking it.
If your operations need more than documentation - if the processes themselves are broken - we can help with that. But the SOPs come first. You can't fix what you haven't written down.
Frequently Asked Questions
How do I create SOPs for a small business?
Start with 5 processes that cause the most mistakes or confusion. Use the one-page format: trigger, numbered steps (under 10), tools needed, owner, and last updated date. Record a Loom video for each one. Train your team on them - sharing a document link is not training. Review every 90 days. Don't write more than 5 until those 5 are actually being followed.
What are good SOP examples for small businesses?
The five SOPs that matter most for any small business: how you bring on a new customer, how you deliver your service, how you handle complaints or quality issues, how you onboard a new hire, and how you process payments. These cover the processes that break first when the founder isn't directly involved. Keep each one to one page with specific, numbered steps.
How do I get my team to actually follow SOPs?
Three things: make them short (one page, under 10 steps), make them findable (pinned in Slack, not buried in a drive folder), and train on them (walk through each one with every person who uses it). The number one reason teams ignore SOPs is that the SOPs are too long. The number two reason is that nobody trained them. Fix both and compliance goes up immediately.
How often should SOPs be updated?
Every 90 days at minimum. Use a rotating quarterly cycle: delivery SOPs in month 1, admin/finance in month 2, sales/marketing in month 3. Each review takes 30-60 minutes. If an SOP hasn't been used in 90 days, either promote it or delete it. If the owner has left the company, assign a new one immediately - an unowned SOP is an outdated SOP within weeks.
What's the difference between an SOP and a work instruction?
An SOP describes what to do and when - the overall process in under 10 steps. A work instruction describes how to do a specific step in detail - every click, every field, every decision point. SOPs are for process overview. Work instructions are for task-level detail. Most small businesses need SOPs first. Add work instructions later for complex or high-risk steps.
Cedar Operations builds the SOPs, automations, and dashboards that make your business actually run. See if we're a fit.
Related reading: