I once created a 12-page SOP for client onboarding. It covered every scenario, every edge case, every possible variation. It was thorough, comprehensive, and completely useless. My assistant read it once, told me it was “very detailed,” and then proceeded to onboard the next client by asking me what to do — because the 12-page document was too dense to use as a working reference.
That experience taught me something I now consider a fundamental business principle: a process document that nobody follows is worse than no document at all. Worse, because it creates the illusion of a system while providing none of the benefits.
The One-Page SOP format came from that failure. It’s a standardized template for documenting any business process on a single page — not because processes are simple, but because the document people reference needs to be simple enough to scan in thirty seconds during real work.
I’ve used this format to document over forty processes in my own businesses. Every one of them fits on one page. Every one of them is actually used by the people who need them.
Why One Page (Not Three, Not Ten)
The constraint is the feature. When you limit yourself to one page, you’re forced to make decisions about what matters. You can’t include every edge case, every exception, every scenario. You have to identify the 20% of the process that handles 80% of situations and document that.
This constraint produces three benefits:
Benefit 1: People actually read it. A one-page document takes 60-90 seconds to read. A ten-page document takes 15-20 minutes. The first will be read and referenced. The second will be filed and forgotten.
Benefit 2: It’s scannable during real work. When your assistant is in the middle of onboarding a client and needs to check the next step, they need to find the answer in five seconds. A one-page document with clear headings allows this. A multi-page document doesn’t.
Benefit 3: It stays updated. A short document is easy to update when the process changes. A long document is such a pain to update that people stop maintaining it, and outdated documentation is worse than no documentation because it actively misleads.
The Owner Dependency Audit identifies which processes need documentation. This SOP format is how you document them without creating a library nobody uses.
The Template
Every One-Page SOP follows this structure. Copy it directly.
[PROCESS NAME] Last updated: [DATE] | Owner: [WHO MAINTAINS THIS]
PURPOSE: [One sentence: why this process exists and what outcome it produces]
TRIGGER: [What event starts this process — “When a new client signs the contract” / “Every Monday at 9 AM” / “When inventory drops below 20 units”]
STEPS:
- [Action verb] [Specific action] [Tool/location if relevant]
- [Action verb] [Specific action] [Tool/location if relevant]
- [Action verb] [Specific action] [Tool/location if relevant] …continue for 5-10 steps maximum
IF SOMETHING GOES WRONG:
- [Common problem 1] → [What to do]
- [Common problem 2] → [What to do]
- [Anything else] → Contact [name] at [contact method]
DONE WHEN: [Specific completion criteria — how do you know this process is finished?]
TOOLS NEEDED: [List of tools, accounts, templates, with links]
That’s it. Six sections. One page. Let me walk through each section.
Section Walkthrough With a Real Example
I’ll use my actual client onboarding SOP as the example.
CLIENT ONBOARDING Last updated: 2026-03-15 | Owner: Felix Lenhard
PURPOSE: Welcome new consulting clients and set up everything needed for a smooth engagement start.
TRIGGER: When a new client signs the project agreement.
STEPS:
- Send the welcome email using Template C-1 in the email templates folder within 24 hours of signed agreement
- Create a new client folder in the shared drive using the Client Folder Template
- Add client contact details to the CRM (company, primary contact, email, phone, project value, start date)
- Schedule the kickoff meeting within 5 business days — send the pre-meeting questionnaire (Template C-2) when scheduling
- Set up invoicing: create the client in the invoicing tool, set payment terms (Net 30 unless otherwise agreed), schedule first invoice for project start date
- Send the project timeline document (Template C-3) at least 48 hours before the kickoff meeting
- Prepare the kickoff meeting agenda using Template C-4, customized with answers from the pre-meeting questionnaire
IF SOMETHING GOES WRONG:
- Client doesn’t respond to welcome email within 48 hours → Send a brief follow-up: “Just confirming you received my welcome email — let me know if you have any questions”
- Scheduling conflict for kickoff meeting → Offer three alternative time slots, always within the first 5 business days
- Pre-meeting questionnaire not returned before kickoff → Proceed with kickoff, cover the questions verbally in the meeting, document answers afterward
DONE WHEN: Kickoff meeting is complete, CRM is updated, invoicing is set up, and client folder contains all project documents.
TOOLS NEEDED: Email templates (Folder: Templates > Client), CRM (link), Invoicing tool (link), Shared drive client folder template (link), Scheduling tool (link)
This fits on one page with room to spare. It takes about 60 seconds to read and provides everything someone needs to onboard a client without my involvement.
The “Action Verb” Rule
Notice that every step starts with an action verb: Send, Create, Add, Schedule, Set up, Prepare. This is not optional formatting — it’s a design decision that makes SOPs dramatically more useful.
Compare:
- “The welcome email should be sent to the client” (passive, vague)
- “Send the welcome email using Template C-1 within 24 hours” (active, specific, time-bound)
The second version tells you exactly what to do, how to do it, and when. The first version tells you something should happen without specifying who does it or when. Action verbs create clarity. Passive language creates confusion.
Every step should answer three questions: What action? Using what tool/template? By when? If your step doesn’t answer all three, it’s not specific enough.
The “If Something Goes Wrong” Section
This section is what separates useful SOPs from useless ones. Most process documents describe the happy path — what happens when everything goes according to plan. But in real work, things don’t go according to plan roughly 20% of the time. Without guidance for the unhappy path, people either improvise (inconsistently) or come to you for instructions (defeating the purpose of the SOP).
The key to this section: cover the two or three most common problems. Not every possible problem. If you try to cover every scenario, you’ll end up with that 12-page document nobody reads.
The format — Problem → Solution — makes it scannable. The final bullet (“Anything else → Contact [name]”) is your safety net for edge cases. It acknowledges that unusual situations exist and provides a clear escalation path.
I review this section quarterly and update it based on real problems that have occurred. If a new problem type shows up twice, it gets added to the SOP. If an existing problem stops occurring (because the process was improved), it gets removed. The section evolves with the process.
Writing SOPs That Actually Get Used
The format is important. The implementation is more important. Here’s how to ensure your SOPs are actually used:
Write them immediately after doing the task. Not before (you’ll miss steps). Not a week later (you’ll forget details). Immediately after, while the process is fresh. Spend the extra five minutes.
Have the person who’ll use it read it and tell you what’s unclear. You wrote it with full context. They’re reading it without context. What seems obvious to you may be confusing to them. This quick review catches 90% of clarity problems.
Store them where work happens. If your team works in Google Drive, the SOPs go in Google Drive. If they work in Notion, SOPs go in Notion. If they work in email, SOPs get pinned in relevant email folders. Don’t create a separate “SOP repository” that requires an extra step to access. Proximity to the work is everything.
Review every SOP at least once per quarter. Processes evolve. Tools change. Team members change. A quarterly scan of all SOPs (which takes maybe thirty minutes if you have twenty SOPs) catches outdated information before it causes problems.
Link SOPs to each other. If Step 4 of one SOP triggers another process, link to that SOP. This creates a connected documentation system rather than isolated documents. My client onboarding SOP links to the invoicing setup SOP, the kickoff meeting SOP, and the CRM data entry SOP.
This documentation discipline connects to building a clockwork business — you can’t run a business without the owner if the owner’s knowledge isn’t documented somewhere outside the owner’s head.
The SOP Creation Sprint
If you have zero SOPs and feel overwhelmed by the idea of documenting everything, here’s a focused approach:
Week 1: Identify your five most critical recurring processes. These are the ones that happen regularly and would cause problems if done wrong or not done.
Week 2: Document one SOP per day using the one-page format. Five days, five SOPs. Don’t agonize over perfection — the first version will be good enough to be useful and can be refined later.
Week 3: Have someone else (a VA, a colleague, a partner) try to follow each SOP without your input. Note where they get stuck. Those are your clarity gaps. Fix them.
Week 4: File the SOPs in accessible locations, set quarterly review reminders, and start the ongoing “capture as you go” practice for new processes.
After this sprint, you’ll have five usable SOPs covering your most critical processes. That’s more documented process than most solo founders ever create, and it’s enough to start delegating, taking vacations, and reducing your owner dependency score meaningfully.
Add SOPs incrementally after that — one per week as you encounter recurring processes that need documentation. Within three months, you’ll have a library of fifteen to twenty SOPs that covers the vast majority of your business operations. All on one page each. All actually used.
Key takeaways:
- Use the six-section template: Purpose, Trigger, Steps, If Something Goes Wrong, Done When, and Tools Needed — this structure fits on one page and covers everything needed for execution.
- Start every step with an action verb and answer three questions: what action, using what tool, by when — passive language creates confusion.
- Cover the two or three most common failure modes in the “If Something Goes Wrong” section — always include a catch-all escalation contact for unusual situations.
- Store SOPs where work happens (same tool, same folder) — separate repositories add friction that prevents actual usage.
- Run the four-week SOP Creation Sprint to go from zero to five critical SOPs — then add one per week through ongoing “capture as you go” documentation.
