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.
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.
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
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. Notion, ClickUp, Google Drive, a dedicated wiki — any of these works. What does not work is half in Google Docs, half in Slack messages, and half in someone's email inbox.
The structure that works for most growing businesses is simple:
A top-level folder for each department or function — Operations, Sales, Finance, HR, Client Delivery. Inside each folder, 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.
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.