Read summarized version with
A couple years back, a customer sent us a 47-page Word doc.
It was their “master SOP” for onboarding new sales reps. Beautifully written, too. Color-coded headings, a table of contents, footnotes. The whole production. The person who built it had burned three weekends on the thing.
Nobody read it.
Not the new hire it was written for. Not the manager supposed to enforce it. Not the rep who’d been there six months and still pinged the same questions in Slack every Tuesday. The doc sat in a Google Drive folder called “Onboarding (FINAL)” alongside four other versions with names like final_v3_FINAL.docx and Onboarding REAL final.docx.
That’s when it clicked. Most SOPs don’t fail because the content is wrong. They fail because they were written for the writer, not the reader. Long where they should be tight, vague where they should be specific, and parked somewhere nobody thinks to look.
I’m Yuval, founder of Glitter AI. We’ve watched a lot of teams write a lot of SOPs, and the ones that actually get used tend to follow the same handful of rules. This post covers 12 SOP best practices that drive real adoption - not the compliance-theater kind.
If you care more about keeping SOPs alive after they’re written, that’s a separate problem. Go read my post on SOP management best practices. This one is about getting the writing right the first time around.
Teach your co-workers or customers how to get stuff done – in seconds.
1. Pick One Process at a Time, Not All at Once
The most common way SOP projects die? Trying to document everything in one quarter.
Someone in leadership announces “we’re going to document our whole company” and a committee gets formed. Six weeks later, that committee has produced a spreadsheet of 240 processes and exactly zero finished SOPs. By month three, the meeting invite is the only thing left, and people have stopped showing up.
Why it matters: Documentation is a long game. The compounding only kicks in if you actually ship.
Common failure mode: Trying to boil the ocean. Picking processes by committee instead of by pain. Tweaking the doc template before any docs exist.
What good looks like: Pick one process this week. The one your team asks about constantly, or the one that breaks the moment a specific person goes on vacation. Write that one. Ship it. Get it used. Then pick the next. Momentum beats master plans, every time.
2. Write to Your Weakest Reader
Most SOPs are written by experts, for experts. That’s the bug.
The person reading your SOP is almost never the person who wrote it. It’s the new hire on day 2. The contractor covering parental leave. The support agent yanked into a process they’ve never run.
Why it matters: If your SOP requires context the reader doesn’t have, it’s not an SOP. It’s a memory aid for the author.
Common failure mode: Skipping the steps that “everyone knows.” Using internal jargon without defining it. Assuming the reader knows where to find the tool, what tab to click, or what “the usual” means.
What good looks like: Write as if the reader has never done this before. If you’d hesitate to hand the SOP to a new hire on day 2 and walk away, it’s not done. This, by the way, is why I think every SOP team should read how to create SOPs employees follow - the audience problem is basically the whole game.
3. Use Action Verbs in Present Tense
“The user should consider clicking the submit button when all fields have been validated” is not an SOP. That’s a legal document.
Why it matters: Your reader is doing this right now. On their screen. Hands on the keyboard. They need verbs, not philosophy.
Common failure mode: Passive voice (“the form is filled out”). Conditional language (“you might want to”). Describing the process from the third person, like a narrator.
What good looks like: “Click Submit.” “Type the customer’s email.” “Open the dashboard.” Direct. Imperative. Present tense. If you can’t read the SOP out loud like a recipe card, rewrite it.
4. Cap Each Step at One Verifiable Action
The fastest way to lose a reader? A step that secretly contains five steps.
I see this constantly. “Step 3: Open the CRM, find the customer, update their billing address, send a confirmation email, and log the change in the audit table.” That’s not step 3. That’s steps 3 through 7.
Why it matters: Readers track progress by checking off finished steps. If a step contains multiple actions, they can’t tell whether they finished it. They get anxious. Re-read. Make mistakes. Eventually they give up and Slack you.
Common failure mode: Cramming related actions together to keep the doc “short.” Using “and” or “then” inside one step.
What good looks like: One step, one action, one observable outcome. If you can’t say “I just did step 4” without ambiguity, the step is too big. Break it.
Teach your co-workers or customers how to get stuff done – in seconds.
5. Add Visuals Every 3-4 Steps Minimum
Text-only SOPs are a holdover from a world without screenshots.
Reading a paragraph that says “go to Settings, then Billing, then click the small gear icon in the upper right” is exhausting. Seeing a screenshot with an arrow pointing at the gear takes a second.
Why it matters: Visuals carry information words can’t. UI changes, button placement, color cues, screen layout. Without them, the reader has to translate your prose back into a mental picture of their screen, then go hunt for the thing.
Common failure mode: Writing a 12-step SOP with zero screenshots because adding them is annoying. Or worse, adding screenshots that are 2 years old and no longer match the UI.
What good looks like: A screenshot or short clip every 3-4 steps, minimum. For UI-heavy workflows, every step. This is exactly the problem we built Glitter to solve. You record yourself doing the process once, and Glitter spits out a step-by-step guide with annotated screenshots automatically. It’s the biggest force multiplier we’ve seen for visual SOPs, because the alternative (manual screenshot, paste, annotate, repeat) is what kills the writing process.
6. Include Decision Points Explicitly
Real processes have branches. Most SOPs pretend they don’t.
“If the customer is a new account, do X. If they’re an existing account, do Y. If they’re a partner, do Z.” That’s a decision point. Skip it and you produce an SOP that works 60% of the time and confuses everyone the other 40%.
Why it matters: When the SOP doesn’t address an edge case, the reader has to guess - or ping you. Both bad. Guessing creates inconsistency. Pinging you creates dependency on you, which is the whole reason you wrote the SOP in the first place.
Common failure mode: Writing the “happy path” only. Burying decision logic inside a paragraph instead of calling it out.
What good looks like: Use clear conditional formatting. “If X, go to step 7. If Y, go to step 9.” Or branch the SOP visually with sub-flows. Whatever the format, make the decision impossible to miss.
7. Owner-Name + Role on Every SOP
If nobody owns the SOP, nobody updates the SOP.
Learned this one the hard way. We had an SOP for onboarding new customers that worked great when our head of CX wrote it. Six months later, she’d left, the product had moved on, and the SOP was still telling new hires to click a button that didn’t exist. Nobody felt responsible for fixing it.
Why it matters: Documents without owners decay. Documents with owners get reviewed.
Common failure mode: “Owned by the team.” That’s nobody. Or owned by a person who left 18 months ago.
What good looks like: Every SOP has a named human plus a role. Both. The name handles ownership today. The role handles ownership when the human moves on. Bonus points for a “last reviewed” date next to the owner.
8. Version-Stamp Everything (No “final_v3_FINAL.docx”)
If your SOP filename ends in “v3_FINAL_REAL.docx”, you don’t have version control. You have version chaos.
Why it matters: Version chaos is how three teams end up running three different versions of “the” SOP. It’s also how you end up unable to answer “when did this process change?” - which matters more than you’d think the moment something breaks.
Common failure mode: Versioning by filename. Storing SOPs in Word/Google Docs without real history. “Saving as new” instead of editing in place.
What good looks like: Store SOPs in a system that tracks revision history automatically. Stamp every doc with a version number and a “last updated” date. When you make a real change, bump the version and note what changed. This is the kind of structure I get into in how to write an SOP - versioning is one of the things separating a real SOP from a sticky note.
9. Test the SOP With Someone Who Didn’t Write It
This is the most underrated SOP best practice on the list.
Before you call an SOP “done,” hand it to someone who’s never run the process and watch them try. Don’t help. Don’t explain. Don’t fill in gaps. Just watch.
Why it matters: You’ll discover, in about 90 seconds, every assumption you made that the reader doesn’t share. Every step you skipped because “everyone knows.” Every screenshot that’s slightly out of date. Every decision point you forgot to include.
Common failure mode: Marking an SOP “complete” the second the writer stops typing. No usability test. No feedback loop.
What good looks like: A new hire (or anyone unfamiliar) runs the process using only the SOP. The writer watches silently and takes notes wherever the reader stalls. Then the writer revises. This one practice will improve your SOPs more than any template ever will.
Teach your co-workers or customers how to get stuff done – in seconds.
10. Build Review Into the Calendar, Not “When We Remember”
“We’ll review these quarterly” is one of the most reliable lies in business.
Without a calendar trigger, reviews don’t happen. Then six months later you find out half your SOPs reference a tool you stopped using, and the new hire who onboarded off stale instructions has been running a broken process for two months.
Why it matters: SOPs decay. Tools change. People change. Processes change. If review isn’t scheduled, it doesn’t happen.
Common failure mode: Trusting individual willpower to remember to review docs. Setting up a “review when something changes” rule, which assumes the reviewer always knows when something changes (they don’t).
What good looks like: Each SOP has a scheduled review date - quarterly, twice a year, or annually depending on volatility. The owner gets a calendar reminder. The review itself is a 15-minute checklist, not an existential exercise. For a deeper look at the whole maintenance problem, SOP management best practices is the post I’d send next.
11. Make SOPs Searchable, Not Stuck in a Drive Folder
Drive folders are where SOPs go to die.
Specifically: nested drive folders three levels deep, with names like “Operations > Internal > Process Docs > 2024 Q3.” Nobody finds those. Even the people who made them can’t find them six months later.
Why it matters: An SOP nobody can find is the same as no SOP. If a new hire can’t search “refund policy” and pull up the right doc in 5 seconds, they’ll ask in Slack instead, and your “single source of truth” quietly becomes whatever the last person to answer in Slack said.
Common failure mode: Storing SOPs in a folder hierarchy. Assuming everyone bookmarks them. Relying on people to remember the exact title.
What good looks like: SOPs live in a system with full-text search. Tags or categories supplement search but don’t replace it. The system is linked from your team’s homepage, your Slack, your wiki - wherever people actually go. If you’re early-stage and need a starting point, our SOP template guide has a structure that’s easy to make searchable from day one.
12. Train on the SOP, Don’t Just Publish It
Publishing an SOP is not the same as adopting one.
I’ve watched companies write a beautiful 30-page SOP, drop it in a Notion folder, send a Slack message saying “FYI, here’s the new process,” and then act surprised when nobody follows it three weeks later.
Why it matters: People don’t read documents on the off-chance they might be relevant. They learn processes by doing them, ideally with someone watching. Publishing is the start of adoption, not the end.
Common failure mode: Treating SOP launch as a notification event. No walkthrough. No check that anyone read it. No follow-up.
What good looks like: When you publish a new SOP, you also schedule a 15-minute walkthrough - live or recorded. People run through the process with the SOP open. You verify they can complete it. You answer questions. This is the second place Glitter is a force multiplier: a recorded walkthrough that doubles as the SOP itself means publishing and training happen in the same step. No separate “now let’s train on the SOP we just wrote” meeting needed.
The Pattern Behind All 12 Tips
Re-read these 12 practices and they all share one underlying assumption: the SOP is a tool for the reader, not a trophy for the writer.
Every failure mode I described comes from optimizing for the writer instead of the reader. Long docs feel thorough to write but exhausting to read. Skipping screenshots saves time on creation but costs time on every single use. Storing in a folder is easier than setting up search, but it punishes everyone who has to find the doc later.
The SOPs that get adopted are the ones written for the moment of use. Day 2 of a new hire. The Tuesday morning when the regular person is out. The 11pm support escalation. If your SOP works in those moments, it’ll work anywhere.
If you’ve read this far and you’re thinking “okay, but actually writing SOPs that hit all 12 of these is a ton of work” - yeah, it is. That’s why we built Glitter’s SOP generator. Record yourself doing the process once, and it produces a step-by-step guide with screenshots, captions, and a structure that already follows most of these practices by default. It’s not magic, but it strips out roughly 80% of the manual labor that makes SOP writing painful.
Teach your co-workers or customers how to get stuff done – in seconds.
Frequently Asked Questions
What are the most important SOP best practices?
The most important SOP best practices are writing to your weakest reader, capping each step at one verifiable action, adding visuals every 3-4 steps, naming an owner on every SOP, and testing the SOP with someone who did not write it. These five drive the majority of adoption gains.
How do you write SOPs that people actually follow?
To write SOPs people follow, focus on adoption signals: short steps, screenshots, clear ownership, decision points, and live training on launch. Publishing the doc is not the goal - getting it used in the moment of work is.
How long should an SOP be?
An SOP should be as short as possible while still letting an unfamiliar reader complete the process. Most well-written SOPs are 5-15 steps. If you are writing a 47-page SOP, you are probably documenting multiple processes that should be split apart.
How often should SOPs be reviewed?
Most SOPs should be reviewed every 6-12 months, with high-change processes (tools, regulations, products) reviewed quarterly. The key is putting reviews on a calendar with a named owner, not relying on people to remember to update docs when something changes.
Why do most SOPs fail to get adopted?
Most SOPs fail to get adopted because they are written for the author, not the reader. They assume too much context, lack visuals, contain steps that cram multiple actions together, and live in folders nobody searches. Adoption requires writing for the moment of use.
Should SOPs include screenshots and videos?
Yes. Visuals dramatically increase comprehension and reduce errors, especially for UI-heavy workflows. Aim for a screenshot or short clip every 3-4 steps. Tools like Glitter generate annotated visuals automatically by recording the process once.
Who should own an SOP?
Every SOP should have a named human owner plus a role. The named owner handles current accountability, and the role handles continuity when people change positions or leave the company. Documents without owners decay quickly.
How do I structure steps in an SOP?
Each step should contain exactly one verifiable action written with an action verb in present tense. If a step contains the word "and" between two actions, split it. Readers track progress by completing single, observable steps.
What is the best way to version an SOP?
Use a system with built-in revision history rather than versioning by filename. Stamp each SOP with a version number and last-updated date, and note what changed when you publish a new version. Avoid filenames like "final_v3_FINAL.docx" - they are version chaos, not version control.
How do I make sure new hires actually find our SOPs?
Make SOPs searchable rather than nested in folders, link them from your team homepage, Slack, and wiki, and walk new hires through the search experience on day 1. If a new hire cannot find the right SOP in 5 seconds via search, they will ask in Slack instead and undermine your single source of truth.
