Read summarized version with
The first SOP I ever tried to write was called “Accounts Payable.” That was the title. It was also the first sign the whole thing was about to fall apart.
By page 12 I had vendor onboarding, invoice entry, three-way match, exception handling, payment runs, month-end close, and a little section on 1099s. By page 20 I quit. Nobody on my team was going to read that. Nobody was going to follow it. And worst of all, nobody was ever going to own it, because “Accounts Payable” isn’t a process. It’s a department.
I’m Yuval, CEO of Glitter AI. I’ve watched hundreds of small and mid-sized businesses try to document their operations, and the single most common mistake has nothing to do with writing quality or screenshots. It’s bad scope. People try to stuff an entire function into one document and end up with something too long to read, too vague to follow, and impossible to keep current.
This post is about fixing that. Not by writing better. By drawing better boundaries.
Teach your co-workers or customers how to get stuff done – in seconds.
What “Scope” Actually Means in an SOP
Scope is the fence around your SOP. It tells the reader (and the author, and the auditor) what this document is and isn’t responsible for.
A good scope has four parts:
- Start condition - what trigger kicks off the process? (an invoice arrives, a ticket is created, a customer signs the contract)
- End condition - what state means we’re done? (the invoice is paid, the ticket is closed, the welcome email is sent)
- Who - which role or person performs this work?
- What’s in vs out - which adjacent activities are explicitly not covered here?
If you can’t answer all four in one or two sentences, your scope is fuzzy. Fuzzy scope is the root cause of most bad SOPs. For more on the structural side of writing the doc itself, see my guide on how to write an SOP.
A useful gut check: a well-scoped SOP should be 7±2 steps long. That’s the same magic number George Miller found for short-term memory back in 1956. If your SOP balloons past nine steps, your scope is almost certainly too broad. Split it.
The Three Most Common Scope Mistakes
I see the same three failure modes show up over and over.
Mistake 1: Too Broad (“All of Finance”)
This is the “Accounts Payable” mistake from my opening. The title is a department, a function, or a quarter’s worth of work. The author tries to capture everything one person on the team does.
The result is predictable: the doc is too long to read on one screen, the steps are too generic to actually follow, and updating it is painful enough that it goes stale within a quarter.
Tell-tale signs your scope is too broad:
- The title is a noun phrase like “Customer Support” or “HR Onboarding”
- The doc runs more than 9 steps
- It covers multiple roles or hand-offs across teams
- You catch yourself writing “depending on the situation, you might…”
Mistake 2: Too Narrow (One Click in QuickBooks)
The opposite failure. Someone reads advice like “be specific” and ends up writing an SOP called “How to Click the Save Button in QuickBooks.”
That isn’t an SOP. It’s a tooltip. Documents this small don’t justify their own ownership, review cadence, or place in your knowledge base. They just become noise.
A useful rule: if a teammate could figure it out from the UI in under 30 seconds, it doesn’t need its own SOP. Roll it into the parent process.
Mistake 3: Overlapping with Adjacent SOPs
This one’s the sneakiest. You have an SOP for “New Hire Onboarding” and another for “Granting System Access.” Both cover provisioning the new hire’s email account. Now when the email policy changes, you have to remember to update both. You won’t.
Overlapping scope is silent rot. The two docs drift apart, and eventually a new hire ends up with two conflicting sets of instructions.
The fix: every step lives in exactly one SOP. The other one references it with a link, not a copy.
Teach your co-workers or customers how to get stuff done – in seconds.
The Scope Statement Formula
Here’s the formula I use for every SOP. Steal it.
This SOP covers [X process] for [audience], starting when [trigger] and ending when [completion]. It does NOT cover [adjacent X].
That’s it. One sentence. Maybe two if the “does NOT cover” list is long.
The “does NOT cover” line is the part everyone skips, and it’s the most important one. It’s the explicit fence. It’s how the next person figures out whether this is the right doc to grab.
A Filled-In Example
This SOP covers vendor invoice entry into QuickBooks for the AP clerk, starting when a PDF invoice arrives in ap@company.com and ending when the invoice is saved in QuickBooks with status “Awaiting Approval.” It does NOT cover vendor onboarding, three-way matching, payment runs, or 1099 preparation.
Picture an auditor, a new hire, or a future-you reading that. Zero ambiguity about what this doc is.
A Decision Tree for Splitting One SOP into Two
When you suspect your scope is too broad, walk through this:
- Does the process have a natural hand-off? If person A finishes and hands the work to person B, that’s almost always two SOPs. Split at the hand-off.
- Are there branching paths longer than 2-3 steps? If your doc has a big “if this, then…” branch, the branch probably deserves its own SOP. Link to it from the parent.
- Does the doc cross more than one system of record? Logging into ERP, then CRM, then a spreadsheet usually means you’re covering more than one process. Split by system if the work is distinct.
- Is any single step itself a multi-step procedure? If step 4 secretly contains 6 sub-steps, extract it as its own SOP and link.
- Will different people own different parts? Ownership is the cleanest test. If finance owns the first half and IT owns the second half, you have two SOPs.
If the answer to any of these is yes, split. Two short, owned, accurate SOPs always beat one long, unowned, half-true one. Same principle behind why SOPs and work instructions live at different altitudes - different audiences, different scopes.
Good vs Bad Scope Statements: Real Examples
Here are three common SMB processes with the bad scope statement people actually write, and the good one they should write.
Accounts Payable
Bad: “This SOP covers accounts payable.”
Good: “This SOP covers entering vendor invoices into QuickBooks for the AP clerk, starting when an invoice PDF lands in ap@company.com and ending when the invoice is saved in QuickBooks with status ‘Awaiting Approval.’ It does NOT cover vendor onboarding, three-way matching, payment runs, or 1099 prep.”
The bad version is a department. The good version is a single, repeatable, observable task.
Customer Onboarding
Bad: “This SOP covers onboarding new customers.”
Good: “This SOP covers sending the welcome kit to new SMB customers for the customer success rep, starting when a deal is marked Closed-Won in HubSpot and ending when the welcome email is logged as sent in HubSpot. It does NOT cover contract signing, payment collection, technical implementation, or the 30-day check-in.”
Customer onboarding in the bad version could mean ten different things. The good version is one observable, finishable unit of work. If you’re documenting a full onboarding journey, you’ll probably end up with five or six SOPs that link together. That’s the right answer, not one mega-doc.
IT Password Reset
Bad: “This SOP covers IT support.”
Good: “This SOP covers resetting an employee’s Active Directory password for the IT helpdesk technician, starting when a password reset ticket is opened in Zendesk and ending when the user confirms successful login. It does NOT cover password resets for SaaS apps not federated to AD, account lockouts due to suspected compromise, or new employee account creation.”
The bad version is so broad it’s useless. The good version is laser-focused, and it explicitly carves out the security-incident edge case, which is a different process with different stakeholders.
Teach your co-workers or customers how to get stuff done – in seconds.
Scope Drives Ownership and Review Cadence
Here’s something most people miss. Scope is what makes ownership possible.
If your SOP is “Accounts Payable,” who owns it? The CFO? The AP manager? The clerk? In practice, nobody, and unowned docs rot.
If your SOP is “Vendor Invoice Entry into QuickBooks,” ownership is obvious. The AP manager owns it, the AP clerk uses it, and it gets reviewed when QuickBooks changes its UI or when the chart of accounts is updated.
Tight scope also dictates review cadence. A narrow, tactical SOP only needs review when the underlying tool or input changes. A broad, sprawling SOP technically needs review every time anything in its surface area changes, which is constantly, which means in practice it never gets reviewed at all.
Tight scope = clear owner = realistic review cadence = a doc that stays accurate. Broad scope = no owner = no review = a doc nobody trusts. For more on what belongs in a well-scoped doc, see my SOP checklist and SOP format best practices.
The Audit and Compliance Angle
If you’re in a regulated industry - healthcare, finance, manufacturing, anything ISO-adjacent - auditors love a clean scope. I mean it. Tight scope is the single thing that makes an auditor’s job easy and yours short.
When an auditor opens your SOP and sees:
“This SOP covers X for Y, starting when Z and ending when W. It does NOT cover A, B, or C.”
…they instantly know what evidence to ask for. They sample within the boundary. They don’t go on a fishing expedition.
When an auditor opens an SOP titled “Quality Management” with no scope statement, they have to figure out the boundary themselves. That goes badly. They’ll either ask for evidence about everything (painful) or assume the doc is meant to govern things it wasn’t (worse).
Clean scope is a compliance gift to your future self.
Why SMBs Over-Scope (and Why You Shouldn’t)
Almost every SMB I’ve worked with over-scopes their SOPs. The reason is psychological, not technical.
When you’re a 20-person company and you finally sit down to “document the business,” it feels wasteful to write five small docs when you could write one big one. Five docs feels fragmented. One doc feels thorough.
But thorough is a trap. The big doc is harder to write, harder to read, harder to maintain, harder to onboard new hires with, and harder to update when something changes. You optimized for the moment of authoring instead of the lifetime of the document.
Five short, narrow SOPs that link together will beat one mega-SOP every time. Each one is short enough to actually read before doing the work. Each has a clear owner. Each has a clean trigger and a clean completion. When something changes, you update only the one affected.
How a Screen Recording Naturally Enforces Narrow Scope
Here’s something I learned the hard way building Glitter’s SOP generator: if you record yourself doing a task, scope enforces itself.
You hit record. You do the task. You hit stop.
The “hit stop” moment is the natural end condition. You can’t accidentally pad the SOP with the next process, because you literally stopped recording. The “hit record” moment is the natural start condition. You’re not theorizing about where the process begins. You’re showing it.
This is one of the reasons recording-based SOPs tend to be tighter than written-from-memory ones. Memory invites scope creep (“oh, and also, sometimes you have to…”). A recording can’t creep. It’s bounded by the real-world start and stop of the task.
If you’ve been wrestling with scope, my honest suggestion is this: stop trying to write the SOP. Record yourself doing the task one time, end-to-end, in under five minutes. If it took longer than five minutes, your scope is too broad. Split the task and record again. The clock is your scope guardrail.
Teach your co-workers or customers how to get stuff done – in seconds.
A Practical Checklist for Defining SOP Scope
When you sit down to write your next SOP, run this checklist before writing a single step:
- Write the scope statement using the formula. One sentence. Two if needed.
- Verify the start condition is observable (an event, an arrival, a status change).
- Verify the end condition is observable (a saved record, a sent email, a closed ticket).
- Identify the single role that performs the work. If there’s a hand-off, you have two SOPs.
- Write the “does NOT cover” list. Be explicit about adjacent processes.
- Estimate the step count. If you’re already over nine, narrow the scope before writing.
- Confirm there’s exactly one owner for this scope.
- Confirm the scope doesn’t overlap with any existing SOP.
Clear all eight and you’re ready to write the body. If you can’t, fix the scope first. Writing on top of bad scope is wasted work.
Wrapping Up
The reason most SOPs fail isn’t poor writing. They were doomed before the first word was typed, because the scope was wrong.
Tight scope is what makes an SOP usable, ownable, auditable, and maintainable. Use the formula. Aim for 7±2 steps. Be explicit about what’s not in the doc. When in doubt, split.
Two short SOPs that work will always beat one long SOP that doesn’t. - Yuval, CEO of Glitter AI
Frequently Asked Questions
What is SOP scope?
SOP scope is the boundary of a standard operating procedure. It defines the start condition, end condition, who performs the work, and what adjacent activities are explicitly not covered. A clear scope keeps SOPs short, ownable, and accurate.
What is an SOP scope statement?
An SOP scope statement is a one-sentence definition of what the SOP covers. The standard formula is: 'This SOP covers [process] for [audience], starting when [trigger] and ending when [completion]. It does NOT cover [adjacent processes].'
How do you define the scope of an SOP?
Define SOP scope by identifying four things: the observable trigger that starts the process, the observable state that ends it, the single role performing the work, and the adjacent processes that are explicitly excluded. Write all four in one or two sentences before drafting steps.
How long should an SOP be?
A well-scoped SOP should be 7±2 steps. If your draft has more than nine steps, the scope is almost certainly too broad and the SOP should be split into two or more documents with a clean hand-off between them.
What are common SOP scope mistakes?
The three most common mistakes are scoping too broadly (titling an SOP after a department instead of a task), too narrowly (writing an SOP for a single button click), and overlapping scope with adjacent SOPs (causing two docs to drift apart over time).
When should an SOP be split into two?
Split an SOP when the process has a natural hand-off between roles, branches longer than three steps, crosses multiple systems of record, contains a step that's itself a multi-step procedure, or has different owners for different sections.
What is the difference between SOP scope and SOP purpose?
Scope defines the boundaries - start, end, who, in vs out. Purpose explains why the process exists and what outcome it produces. Scope is operational and concrete; purpose is strategic and contextual. Both belong at the top of an SOP, but they answer different questions.
How does SOP scope affect compliance and audits?
Auditors prefer SOPs with explicit scope statements because it tells them exactly what evidence to sample. Vague scope leads auditors to assume the doc governs more than it does, expanding their inquiry. Clean scope keeps audits short and predictable.
Should SOPs cover multiple roles or hand-offs?
Generally no. When a process hands off from one role to another, treat each side of the hand-off as its own SOP and link them together. Single-role scope makes ownership clear and review cadence realistic.
How does screen recording help define SOP scope?
Screen recording enforces narrow scope automatically. The moment you hit record is the natural start condition, and the moment you hit stop is the natural end condition. Recording-based SOPs tend to be tighter than memory-based ones because the real-world task length bounds the doc.
