Someone asks how to handle a client refund. You explain it. A month later, someone else asks the same question. You explain it again.
Your team member leaves. The new hire asks how everything works. You realize most of it lived only in one person’s head.
You need documentation. But you have seen what documentation becomes in big companies: 47-page procedure manuals that no one reads.
Here is how to get the benefits of SOPs without the bureaucratic overhead.
What “SOP” Really Means for Small Teams
SOP stands for Standard Operating Procedure. The name sounds corporate. The reality does not have to be.
An SOP is just the answer to: “When X happens, here is what we do.”
That is it. The format can be:
- A Google Doc with bullet points
- A Loom video walkthrough
- A checklist in Notion or Asana
- A Slack message pinned to a channel
- A diagram on a whiteboard (photographed)
The goal is capturing knowledge so it exists outside individual heads. The goal is NOT creating perfect documentation.
The Problem with Most SOP Efforts
Small teams try to document and fail because they:
-
Aim for completeness. They try to document everything at once. Overwhelm. Paralysis. Nothing gets finished.
-
Over-engineer the format. Custom templates. Approval workflows. Version control systems. They build infrastructure before building content.
-
Write for auditors, not users. Dense paragraphs. Legal-sounding language. No one reads it because it is miserable to read.
-
Never update. Processes change. Documentation does not. Soon the SOPs describe how things worked two years ago.
-
Centralize too much. Everything lives in a “knowledge base” that requires searching. People give up and just ask.
The result: Documentation that exists but is not used. The team reverts to asking each other—which is exactly where you started.
The Minimum Viable SOP
Before you create an SOP, ask:
- Does this task happen more than once per month?
- Has someone made a significant error doing this task?
- Would a new hire struggle without guidance?
- Does this task involve external-facing work (clients, vendors, partners)?
If yes to two or more, document it.
Format: The 3-Minute Rule
If someone cannot understand your SOP in 3 minutes, it is too long.
For most small team procedures, use this format:
**[Task Name]**
When: [Trigger - what causes this task to start]
Who: [Role responsible]
Time: [How long this typically takes]
Steps:
1. [First action]
2. [Second action]
3. [Third action]
...
If something goes wrong: [Escalation path]
Last updated: [Date]That is it. No 47 pages. No approval signatures. Just clear, scannable steps.
Example: Handling Client Refund Requests
**Processing Client Refunds**
When: Client requests a refund via email or phone
Who: Account Manager
Time: 10-15 minutes
Steps:
1. Acknowledge the request within 24 hours
2. Check client agreement for refund terms
3. If within terms, process in Stripe (Payments → Find charge → Issue refund)
4. Send confirmation email using the "Refund Confirmation" template
5. Log in CRM: Notes → Add "Refund processed: [amount] - [reason]"
If refund is outside terms: Escalate to [Director name] before responding
Last updated: January 2026Anyone can follow this. It took 5 minutes to write. It will save hours over the next year.
Which Processes to Document First
You cannot document everything. Start with:
High-Impact, High-Frequency
These happen often and affect clients or revenue:
- Client onboarding
- Invoice creation and sending
- Payment collection/follow-up
- Support ticket handling
- Quote/proposal creation
High-Risk
Errors here are expensive or damaging:
- Refunds and cancellations
- Access management (who gets system access, how is it revoked)
- Data handling
- Client offboarding
New Hire Critical
What does someone need to know in their first two weeks?
- How to use your core systems
- Communication norms
- Who to ask for what
- Basic troubleshooting
Single Point of Failure
If one person knows this and they leave, you are stuck:
- How specific integrations work
- Where historical files are stored
- Password/access recovery
- Vendor relationships and contacts
Where to Store Documentation
For small teams, simple beats sophisticated:
Option 1: Notion or Coda
- Pros: Flexible, searchable, collaborative
- Cons: Requires everyone to use it
- Best for: Teams that already live in these tools
Option 2: Google Docs/Drive
- Pros: Everyone knows how to use it, easy sharing
- Cons: Can become a mess without structure
- Best for: Teams with no budget for extra tools
Option 3: Your Project Management Tool
- Pros: In the flow of work
- Cons: Documentation gets buried in tasks
- Best for: Simple procedural checklists
Option 4: Loom or Video
- Pros: Fast to create, shows exactly what to do
- Cons: Harder to update, not searchable
- Best for: Screen-based workflows
The best tool is the one your team will actually use. Do not add a new system just for documentation.
The Living Document Problem
SOPs rot. Processes change, but documentation does not.
Rotation Ownership
Do not make documentation one person’s job. Instead:
- Each process has an owner
- The owner reviews their SOPs quarterly
- “Last updated” is visible on every document
Update Triggers
When any of these happen, update the SOP:
- Someone makes an error following current documentation
- A tool or system changes
- A team member asks for clarification
- New hire onboarding reveals gaps
Kill Stale Documentation
Old, wrong documentation is worse than no documentation. If an SOP has not been updated in 12 months and no one uses it, delete it. You can recreate it if needed.
Building the Habit
Documentation is a habit, not a project. Here is how to build it:
The “Document as You Go” Rule
When you answer a question more than once, document it right then. Takes 5-10 minutes. Do it before you forget.
The New Hire Forcing Function
When onboarding someone new:
- Have them attempt tasks using existing documentation
- Note where they get stuck
- Update documentation immediately based on their questions
New hires are your best documentation auditors.
The 30-Minute Friday
Once per month, spend 30 minutes on documentation:
- Write one new SOP for something that tripped someone up
- Review and update one existing SOP
- Delete one outdated document
Small, consistent effort beats annual documentation projects.
Common Mistakes
Too Much Detail
“Open Chrome. Navigate to stripe.com. Enter your email in the ‘email’ field. Enter your password in the ‘password’ field…”
If your audience is competent adults, skip the obvious. Document the decisions and business logic, not every keystroke.
No Context
“Submit the report by the 5th.”
What report? To whom? In what format? What happens if the 5th is a weekend?
Include enough context that someone unfamiliar could understand.
Passive Voice
“The invoice should be sent after the work is completed.”
By whom? When exactly? Passive voice creates ambiguity.
“Account Manager sends the invoice within 24 hours of project completion.”
Clear ownership, clear timing.
No Escalation Path
Every SOP should answer: “What if this does not work as expected?” If the normal process fails, who does the team member contact?
Where This Fits in the Constraint Pyramid
Documentation is Layer 1 (Operations) work. It is not glamorous. It does not show up on a dashboard. But it is foundational.
Without documented processes:
- Every new hire starts from scratch
- Departures cause knowledge loss
- Consistency depends on individuals
- Scaling requires constant hand-holding
With documentation:
- Training is faster and more consistent
- Operations continue when people are out
- Quality is more predictable
- You can see where improvements are needed
Documentation does not fix broken processes. But it makes processes visible—and visible processes can be improved.
Related reading:
- Why Your Business Needs Written Processes (Layer 1)
- Capacity Problem or Systems Problem? (Layer 1)
- Automate Client Onboarding (Layer 3)
