Somewhere in your company's shared drive, there's a folder called "Processes" or "SOPs" or maybe just "Docs." Inside it are documents that took someone hours to write. Nobody reads them. New hires get pointed toward them during onboarding week, skim the first paragraph, and never open them again. When something goes wrong, the conversation is always the same: "Did you follow the SOP?" followed by "What SOP?"
A standard operating procedure (SOP) is a step-by-step document that describes how to complete a specific task or process within an organization. Think of it as a recipe for how work gets done. SOPs exist so that the right thing happens the same way every time, regardless of who's doing it.
The problem isn't that teams don't want processes. The problem is that most SOPs are written in a way that makes them painful to use. Dense paragraphs, vague instructions, jargon that only makes sense to the person who wrote it. Fixing that is more straightforward than you'd think.
Why most SOPs fail before anyone reads them
The typical SOP gets written by someone who knows the process cold. They sit down, open a document, and write everything they know. The result reads like a textbook chapter, not a set of instructions.
According to a 2020 study published in the Journal of Chemical Health and Safety, poorly written SOPs are a leading cause of procedural errors in lab environments. The researchers found that ambiguous language and inconsistent formatting were the top two contributors. This isn't just a lab problem. The same patterns show up in IT runbooks, customer support scripts, HR onboarding docs, and warehouse workflows.
Three patterns kill SOPs more than anything else:
Wall-of-text formatting. When an SOP looks like a legal document, people skip to the part they think is relevant and hope for the best. If they can't find what they need in 10 seconds, they'll ask a coworker instead.
Assumed knowledge. The person who wrote the SOP already understands the process. They skip context that feels obvious to them but isn't obvious to a new team member. "Configure the environment" means nothing without specifics.
Write-once, forget-forever maintenance. An SOP that was accurate in 2023 might be dangerously wrong in 2026 if the tools, team, or policies have changed. Stale documentation is worse than no documentation because it creates false confidence.
Write for the person who's doing this for the first time
The best SOPs are written for the newest person on the team. Not the expert who helped design the process. Not the manager who approved it. The person who just joined last week and needs to complete a task without asking three people for help.
This changes how you write. Instead of "Process the return using the standard procedure," you'd write: "Open the Returns Dashboard at app.example.com/returns. Click 'New Return.' Enter the order number from the customer's email."
Specific beats general. Every time.
Use numbered steps, not paragraphs
An SOP is a set of instructions. Instructions work best as numbered lists. This is the single most impactful formatting change you can make.
Compare these two versions:
Before (paragraph style):
To set up a new client account, first log in to the admin portal and go to the accounts section. From there you'll want to create a new account entry and fill in the client's details including company name, billing email, and plan type. Make sure to check the box for email verification, then save the account and send the welcome email template.
After (numbered steps):
- Log in to the admin portal at admin.example.com
- Click Accounts in the left sidebar
- Click + New Account
- Fill in: Company name, Billing email, Plan type
- Check the Send email verification box
- Click Save
- Open the email templates folder and send the "New Client Welcome" template to the billing email
The second version takes less time to read, less time to follow, and less time to verify that you did it right. It's also easier to update when step 4 changes.
Front-load the "why" and "when"
Before the steps, answer two questions in 2-3 sentences: Why does this process exist? and When should someone use it?
This context prevents two problems. First, it helps people decide whether this is the right SOP for their situation. Second, it gives them the reasoning behind the steps, which matters when they encounter an edge case the SOP doesn't cover.
Example:
Purpose: This SOP covers how to escalate a customer complaint to the engineering team. Use it when a customer reports a bug that you can't resolve with standard troubleshooting (see SOP-014 for troubleshooting steps first).
Two sentences. The reader now knows exactly what this document is for and what to do before they start.
Make it scannable or watch it collect dust
People don't read SOPs like articles. They scan. They jump to the section they need, follow the steps, and close the document. Your formatting needs to support that behavior, not fight it.
Bold the critical actions
In each step, bold the clickable element or the key action. "Click Save" is easier to spot than "Click Save" when someone is scanning while toggling between the SOP and the actual tool.
Use callout boxes for warnings and tips
If a step has a common mistake or an important caveat, pull it out of the regular flow. A quick visual break like "⚠️ Don't skip this step, or the account will be created without billing info" catches attention in a way that burying the warning mid-paragraph doesn't.
Add screenshots (but keep them tight)
Screenshots are helpful when the interface is complex or when a button is hard to find. But full-screen captures with no annotations are almost as useless as no image at all. Crop to the relevant area. Add an arrow or highlight box pointing to the specific element.
Usability research consistently shows that users complete tasks faster and with fewer errors when instructions include annotated screenshots versus text-only instructions. The key word is annotated. A raw screenshot makes the reader search for what matters. A cropped, highlighted screenshot tells them exactly where to look.
Keep the language plain
SOPs often inherit the jargon of whoever wrote them. A technical lead writes SOPs full of acronyms and system-specific terms. A compliance officer writes them in regulatory language. The result is a document that makes sense to the author and confuses everyone else.
The fix: write at a reading level that matches your broadest audience. If the SOP will be used by people across departments or experience levels, strip out the jargon. If a technical term is necessary, define it the first time it appears.
Before: "Initiate the ETL pipeline via the orchestration layer, ensuring the DAG configuration reflects the current schema mappings."
After: "Start the data transfer process: Open Airflow (our scheduling tool) at airflow.example.com. Find the pipeline named 'daily_sync.' Click Trigger DAG. The pipeline will pull data from the source database and load it into the reporting database using the latest column mappings."
The second version is longer, yes. But it's longer because it's actually useful to someone who isn't already an expert.
What "plain language" actually means
Plain language doesn't mean dumbing things down. It means choosing clarity over impressiveness. The U.S. federal government's plainlanguage.gov guidelines define it as communication your audience can understand the first time they read it. That's a good bar for SOPs too.
A few practical rules:
- Use short sentences (under 20 words when possible)
- Choose common words over technical ones ("use" instead of "utilize," "start" instead of "initiate")
- Define acronyms on first use
- One instruction per step
Build in a maintenance schedule or accept decay
An SOP without a review cycle is a ticking clock. Processes change. Tools get updated. Team members leave and take tribal knowledge with them.
The fix is boring but effective: assign an owner and a review date to every SOP.
| Field | Example |
|---|---|
| Owner | Jamie Chen (Operations) |
| Last reviewed | March 15, 2026 |
| Next review | September 15, 2026 |
| Version | 3.1 |
When the review date arrives, the owner reads through the SOP, confirms each step is still accurate, updates anything that's changed, and bumps the date. If the owner has left the team, that's your signal that the SOP needs a new owner before it goes stale.
Some teams add a feedback mechanism directly in the document: a link or email address where anyone can flag a step that seems wrong. This turns every person who uses the SOP into a reviewer, which scales better than relying on a single owner.
A simple SOP template to start with
If you're staring at a blank page, here's a starting structure:
Title: [Process Name] – SOP-[Number]
Owner: [Name, Role]
Last Reviewed: [Date]
Next Review: [Date]
## Purpose
Why this process exists and when to use it. (2-3 sentences)
## Before You Start
Prerequisites, tools needed, or permissions required.
## Steps
1. [First action with specific details]
2. [Second action]
3. [Continue as needed]
## Common Mistakes
- [Mistake]: [How to avoid or fix it]
## Related Documents
- [Link to related SOP or resource]
This covers the essentials without over-engineering it. You can add sections (a glossary, a revision history, a diagram) as the process demands. But start simple. A short SOP that people actually use beats a thorough one that collects dust.
Simplify the draft before you publish
Here's where many SOP projects stall. You've written the steps. The structure is solid. But the language is still full of internal jargon, passive voice, and sentences that run too long. Editing technical writing for clarity is tedious work, and it's exactly the kind of work that gets skipped when deadlines are tight.
One approach that's been useful: run jargon-heavy drafts through a tool that rewrites for plain language before you do your final editing pass. WindowSill has built-in prompts for this, including "Simplify Language" and "Humanize," which are designed to take dense, technical text and make it clearer without losing the meaning. You select the text, pick the prompt, and get a rewritten version in seconds. No copying into a separate app, no context switching.
For teams writing SOPs regularly, WindowSill's custom prompts feature lets you create a reusable "SOP clarity check" prompt that enforces your team's plain language standards every time. Admins can even share prompts across the organization so everyone writes to the same bar. And because WindowSill supports local AI models, teams working with sensitive internal procedures can keep everything on their own machines or company network.
It's not a replacement for a human review. But it's a strong first pass that catches the jargon and complexity a fresh reader would stumble over.
Frequently Asked Questions
What's the difference between an SOP and a work instruction?
An SOP describes a complete process from start to finish, often spanning multiple roles or systems. A work instruction is narrower: it covers a single task within a process, usually for one person. Think of SOPs as the overview and work instructions as the detailed close-ups. Many organizations use both, with the SOP linking to relevant work instructions.
How long should an SOP be?
As short as possible while covering every step someone needs to follow. Most effective SOPs are 1-3 pages. If yours is running past 5 pages, consider splitting it into smaller, linked documents. A user looking for step 14 of a 40-step process is going to lose their place.
How often should SOPs be reviewed?
Every 6-12 months as a baseline, or whenever the tools, team, or policies involved change. The review doesn't have to be a rewrite. Often it's a 15-minute check confirming that each step is still accurate and the screenshots still match the current interface.
Who should write the SOP: the person doing the work or a manager?
The person doing the work, with a manager or peer reviewing it. The person who performs the task daily knows the real steps, the shortcuts, and the common mistakes. A manager can add context about why the process exists and ensure it aligns with team standards. The best SOPs come from this collaboration.
Can AI tools write SOPs for me?
AI can help with drafting, editing, and simplifying language, but it shouldn't be the sole author. AI doesn't know your specific tools, team structure, or edge cases. Use it to clean up jargon, suggest clearer phrasing, or reformat a brain dump into numbered steps. Then have someone who actually does the work verify every step.
That SOP folder in your shared drive doesn't have to be a graveyard. The difference between documentation that gets used and documentation that gets ignored comes down to formatting, plain language, and a commitment to keeping it current. Start with one process. Write it for the newest person on the team. Keep it short. Review it regularly. That's the whole formula.