The SOP Problem
Most founders know they need standard operating procedures.
They have read enough business books to know that documented processes are what separate a business from a job. They have felt the pain of the same question being asked for the seventh time. They have watched a task get done differently by three different people and produced three different results.
They know they need SOPs. They just never write them.
The reason is almost always the same. They imagine SOPs as lengthy, formal documents - the kind that take days to write, sit in a folder nobody opens, and become outdated within weeks of being created. The cure sounds worse than the disease.
So nothing gets documented. The knowledge stays in people's heads. The founder keeps answering the same questions. The team keeps improvising. And when someone leaves, they take a critical piece of how the business runs with them. This is the exact pattern we wrote about in how to fix a business that runs on the founder's memory.
The good news is that effective SOPs do not have to be lengthy, formal, or time-consuming. The SOP that gets used is not the most detailed one. It is the simplest one that gives someone enough information to do the task correctly without asking a question.
What an SOP Actually Needs to Contain
Strip out everything you have been told an SOP should look like and start with this: an SOP exists to answer one question.
How does this get done?
Not why it gets done. Not the history of why the process exists. Not a list of every possible exception. Just: how does this get done, step by step, by someone who has never done it before?
Every SOP needs five things:
A clear title. Not "Customer Onboarding Process" - something like "How to Onboard a New Client After Contract Signing." The title should describe the task so specifically that anyone reading it knows immediately whether this is the document they need.
Who this is for. Which role is responsible for this process? Not which person - which role. Processes survive people. When the person in that role changes, the SOP stays.
When to use it. What triggers this process? A new client signs. A complaint comes in. A monthly report is due. The trigger makes it clear when to reach for the document.
The steps. Numbered, sequential, specific. Each step should describe one action. Not "handle the onboarding" - "send the welcome email using the template in the shared drive, then create the client folder in the project management tool, then schedule the kickoff call within 48 hours." Specific enough that someone can follow it without guessing.
Where to find the tools and templates. Links, folder paths, logins (in the password manager, not in the document). If the step requires a tool, the SOP points to exactly where to find it.
That is the whole document. One page, usually less. Written in plain language. No jargon, no corporate formatting, no executive summary.
The 30-Minute SOP Format
Here is the format we use with every client. It is designed to be written quickly and read quickly.
PROCESS NAME: [Specific, action-oriented title]
OWNER: [Role, not person]
TRIGGER: [What starts this process]
LAST UPDATED: [Date]
STEPS:
1. [Action] - [Where/how to do it]
2. [Action] - [Where/how to do it]
3. [Action] - [Where/how to do it]
...
TOOLS AND RESOURCES:
- [Tool name] - [Link or location]
- [Template name] - [Link or location]
NOTES:
[Any exceptions or things to watch for - keep this short]
Writing one SOP in this format takes between 20 and 45 minutes depending on the complexity of the process. That includes the first draft, a quick review, and adding the links to tools and templates.
It is not a perfect document. It does not need to be. It needs to be good enough that someone can follow it and get a consistent result. You can improve it later when you discover what is missing.
A Real Example: Client Onboarding SOP
To make this concrete, here is a real example of an SOP written in the format above.
PROCESS NAME: How to Onboard a New Client After Contract Signing
OWNER: Account Manager
TRIGGER: Signed contract received in the CRM
LAST UPDATED: 2026-04-15
STEPS:
1. Confirm contract details - check signed contract for scope, deliverables, and payment terms match what was quoted.
2. Send welcome email - use the "Client Welcome" template in the shared drive. Personalise the first two sentences.
3. Create client folder in project management tool - use the "New Client" template. Tag the assigned project lead.
4. Schedule kickoff call - find 60 mins in next 5 business days. Send calendar invite with agenda template.
5. Add to billing system - create new client record with payment terms from contract. Schedule first invoice.
6. Notify delivery team in #client-launches Slack channel - use the client launch template message.
TOOLS AND RESOURCES:
- Welcome email template - shared drive / Templates / Client Welcome.docx
- Project management template - ClickUp / Templates / New Client Project
- Kickoff agenda - shared drive / Templates / Kickoff Agenda.pdf
- Billing system - link to internal billing tool
NOTES:
- For clients over $10K monthly: assign senior account manager and notify operations lead.
- For international clients: add timezone to all calendar invites.
That is one page. It took about 25 minutes to write. Any new hire can follow it.
Where to Start
The mistake most founders make when they finally decide to write SOPs is trying to document everything at once. They make a list of every process in the business, feel overwhelmed, and do nothing.
Start with the processes that cause the most pain right now.
Ask yourself three questions:
What do people ask me the same question about repeatedly? These are the processes where knowledge lives only in your head. Document them first - they are costing you time every single week.
What tasks get done inconsistently? When two people do the same task and produce different results, there is no documented standard for how it should be done. Pick the task where inconsistency causes the most problems.
What would break if a key person left tomorrow? Every business has one or two critical processes that only one person knows how to run. These are the highest-risk SOPs to not have.
Start with one process from each of these three categories. That is three SOPs. Write them this week. Get them in front of the people who do those tasks and ask for feedback. Improve them. Then move to the next three.
Where to Store Them: Tool-Specific Setup
An SOP that nobody can find is the same as an SOP that does not exist.
The location matters less than the consistency. Pick one place and put everything there. The most common options for growing businesses are Notion, ClickUp, and Google Drive. Here is how to set up each one properly.
Setting Up SOPs in Notion
Notion works well for SOPs because of its database structure and easy linking.
Create a top-level page called "SOPs." Inside it, create a database (called "Process Library" or similar) with these properties:
- ·Name (title)
- ·Department (select: Operations, Sales, Finance, HR, Client Delivery, etc.)
- ·Owner Role (text)
- ·Last Updated (date)
- ·Status (select: Draft, Active, Needs Review)
Each row in this database is one SOP. Open the row to write the actual SOP content using the format above. Pin the database view to your main team workspace.
The benefit of this setup: the database becomes your master index automatically. You can filter by department, find SOPs that need review (over 6 months old), and see who owns what.
We covered the broader case for using Notion as a business operating system - SOPs are one of the strongest use cases.
Setting Up SOPs in ClickUp
ClickUp's Docs feature works well for SOPs and integrates with tasks.
Create a Space called "Operations" or "Internal." Inside it, create a Folder called "SOPs." Inside that, create one Doc per department (Operations, Sales, etc.). Inside each Doc, sub-pages for each individual SOP.
The advantage of ClickUp: you can link SOPs directly to the tasks and workflows they govern. When someone is doing a task that should follow an SOP, the link is right there in the task.
If your team is already in ClickUp for project management, putting SOPs in the same tool removes a context switch.
Setting Up SOPs in Google Drive
If your team is already heavy on Google Workspace, a Drive structure works fine.
Create a shared drive called "SOPs" (not in personal Drive - shared Drive ensures continuity when people leave). Inside it, one folder per department. Inside each folder, one Google Doc per SOP. Maintain a master index document called "SOP Index" with links to every SOP.
The downside of Google Drive: no built-in metadata or search by owner/department. You rely on folder structure and the index document. Works for smaller teams (under 20). Becomes harder to manage past that.
The Index Matters More Than the Tool
Whichever tool you pick, the single most important artifact is the master index.
The structure that works for most growing businesses is simple:
A top-level folder, database, or page for each department or function - Operations, Sales, Finance, HR, Client Delivery. Inside each, one document per process. A master index that lists every SOP with a one-line description and a link.
When someone joins the team, the first thing they get is a link to the master index. When someone needs to do a task they have not done before, they check the index before they ask. When a process changes, the person who owns it updates the document.
That is the system. It is not complicated. The hard part is starting.
The SOP That Gets Used
The best SOP is the one your team actually refers to.
That means it has to be findable, readable, and accurate. Findable means it lives in the agreed location and the index is up to date. Readable means it is written in plain language with numbered steps, not paragraphs of explanation. Accurate means it reflects how the process actually works today, not how someone hoped it would work six months ago.
The only way to keep SOPs accurate is to make updating them part of the process itself. When someone follows an SOP and discovers a step is wrong or missing, they update the document before moving on. Not later. Not in a batch review once a quarter. Right then.
Build that habit and your documentation stays current without a dedicated maintenance effort.
How Often to Review SOPs
Even with embedded updates, SOPs need scheduled reviews. The rhythm we recommend:
Quarterly - the owner of each SOP reviews it. Five minutes per SOP. Are the steps still accurate? Are the tool links still working? Is anything missing?
Annually - the operations function reviews the entire SOP library. Are there processes that have changed materially? Are there SOPs that are no longer needed? Are there gaps where new processes should be documented?
This is light maintenance. Maybe two hours a quarter for a typical operations function. Compared to the cost of out-of-date SOPs - confused new hires, inconsistent execution, missed steps - it is the highest-ROI two hours you can spend.
SOPs as Part of a Broader Operations System
SOPs are one component of a working operational system. They sit alongside org structure (who owns what), tools (where work happens), and process design (how work flows). Get one of these right and the others start to matter more.
If your business is past the SOP problem - or you have tried writing them and they did not stick - it usually means the underlying operations need broader work first. For more on that, see what does a business operations consultant actually do.
For the org structure side specifically, how to structure a growing team covers the patterns we see most often.
And if your tool stack is part of the SOP problem - if you cannot document a process because the tool itself is the bottleneck - start with a tool stack audit.
The Return on the Investment
A business where the key processes are documented is a fundamentally different business from one where everything lives in people's heads.
Onboarding is faster because new hires have documentation to follow instead of waiting to be taught. Consistency is higher because everyone follows the same steps. The founder gets time back because the same questions stop getting asked. The business is less fragile because no single person holds all the knowledge.
None of that requires a month of writing. It requires an hour a week, a simple format, and the discipline to start with the three most painful processes instead of trying to document everything at once.
Start there. The rest follows.
Frequently Asked Questions
How long should an SOP be? One page, usually less. The SOP that gets used is the simplest one that gives someone enough information to do the task correctly. Anything longer than a page usually means you are mixing the SOP with training material or background context - separate those out.
What is the difference between an SOP and a process document? An SOP is one type of process document focused on step-by-step instructions for completing a specific task. Broader process documents might also include policies, decision frameworks, or escalation paths. SOPs are the most actionable type and usually the most useful for growing teams.
Should I write SOPs myself or get the team to write them? The person who does the task should write the SOP. The founder or operations lead should review and approve. SOPs written purely top-down often miss real-world steps. SOPs written purely bottom-up sometimes include shortcuts that should not be standardised. Combine both.
How often should SOPs be updated? Update immediately whenever someone discovers a step is wrong or missing. Review formally each quarter for accuracy. Audit the full library annually for gaps and obsolete documents.
What tools are best for storing SOPs in 2026? For under 20 people, Google Drive with a master index works. For 20-100 people, Notion or ClickUp with proper database structure. Past 100 people, dedicated tools like Process Street or Trainual become worth the cost.
Do small businesses really need SOPs? Yes, but selectively. A 3-person business does not need 50 SOPs. It needs 5 SOPs for the processes most likely to be done by someone new or done inconsistently. Scale the number of SOPs with the size of the team.
How do I get my team to actually use the SOPs? Three things: make them findable (clear index), make them readable (one page, plain language), and embed the habit (when someone discovers an issue, they update the document on the spot). The team will use what is easier than asking - so make using the SOP easier than asking.