A startup showed me their operations manual. It was 47 pages. I asked the team when they last opened it. Silence. One person admitted she had read it during her first week and never looked at it again.
Forty-seven pages of work that influenced zero behavior. That is not documentation. That is a monument to the fear of missing something.
I have made the same mistake myself. I once created a 12-page SOP for client onboarding. It covered every scenario, every edge case, every possible variation. My assistant read it once, told me it was “very detailed,” and then onboarded the next client by asking me what to do — the document was too dense to use as a working reference. Since that failure I have documented over forty processes in my own businesses. Every one fits on one page. Every one is actually used by the people who need it.
The One-Page SOP Format exists because of a brutal truth: a process document that nobody reads is worse than no document at all. It creates the illusion of systematization without the reality of it. You think you have a system because the document exists. Your team ignores it because they cannot find what they need in 47 pages.
One page. Every process. No exceptions. If it does not fit on one page, the process is too complicated — simplify the process, not the document.
Why One Page Works
There are three reasons one page is the correct length:
1. It gets read. A single page can be scanned in under 60 seconds. A 47-page manual requires a time commitment nobody will make during a busy workday.
2. It forces clarity. When you only have one page, you cannot hide behind vagueness. Every word must earn its place. The constraint eliminates filler and forces you to define what actually matters.
3. It gets updated. Short documents are easy to maintain. Long documents rot. The 47-page manual was outdated within months because updating it required re-reading 47 pages to find the relevant section. A one-page SOP can be updated in five minutes.
The Template: Six Sections
Every SOP follows the same six-section structure. Print it on one page, laminate it, and hand it to whoever runs the process.
Section 1: Process Name and Owner
Process: [Clear, specific name] Owner: [Name of person responsible] Last Updated: [Date]
The owner is the person who runs this process and is accountable for the output. Not “the team.” A name. One person.
Section 2: Trigger
What starts this process?
A trigger is the event that initiates the process. Be specific:
- “New customer signs up” (not “when we get a customer”)
- “First Monday of every month at 9:00” (not “monthly”)
- “Client submits feedback form” (not “when feedback comes in”)
If the trigger is vague, the process will not fire consistently. Vague triggers create the “I thought you were doing that” problem.
Section 3: Steps
The numbered sequence of actions, from trigger to completion. Rules:
- Maximum 10 steps. If you need more than 10, break the process into sub-processes, each with its own SOP.
- Each step starts with a verb. “Send confirmation email.” “Update CRM record.” “Create invoice in accounting software.”
- Include the tool or system. Not “send an email” but “send email using the New Client Welcome template in Mailchimp.”
- Include decision points. “If the order exceeds EUR 500, escalate to [name]. If under EUR 500, proceed to step 5.”
Example for a client onboarding SOP:
- Receive signed contract notification from DocuSign.
- Create client record in HubSpot using New Client template.
- Send Welcome Email using Mailchimp template “Client Welcome V3.”
- Schedule kickoff call within 5 business days using Calendly link.
- Create project folder in Google Drive using folder template.
- Assign project manager in Monday.com.
- Send kickoff agenda to client 24 hours before the call.
Seven steps. Clear. Specific. Anyone with basic competence can follow this.
The verb rule is not cosmetic formatting. Compare “The welcome email should be sent to the client” with “Send the welcome email using the Client Welcome template within 24 hours.” The second tells you exactly what to do, how to do it, and when. Every step should answer three questions: What action? Using what tool or template? By when? If a step does not answer all three, it is not specific enough.
Section 4: Quality Standard
What does “done well” look like?
Define the output quality in one to three bullet points:
- “Welcome email sent within 2 hours of contract signing.”
- “Kickoff call scheduled within 5 business days.”
- “Client confirms receipt of agenda before the call.”
Quality standards prevent the process from being completed technically but poorly. Without them, someone can tick every box while delivering a mediocre result.
Section 5: Time Estimate
How long should this process take?
Not “as long as it takes.” A specific time box:
- “30 minutes per new client”
- “15 minutes per weekly review”
- “2 hours for monthly report preparation”
Time estimates serve two purposes. They set expectations for the person running the process, and they flag problems — if a 30-minute process consistently takes 90 minutes, the process needs redesign.
Section 6: Escalation
When should the owner ask for help?
Define the situations where this process should be escalated to someone else. Usually two to three scenarios:
- “Client requests not covered by the standard template — escalate to [name].”
- “Process cannot be completed within 24 hours — notify [name].”
- “Any client complaint — escalate immediately to [name].”
Escalation rules prevent people from either suffering in silence when they are stuck or making decisions above their authority.
The strongest SOPs pair the escalation rules with the two or three most common problems and their fixes, in a Problem → Solution format: “Client does not respond to welcome email within 48 hours → send a brief follow-up.” Real work goes off the happy path roughly 20% of the time; without guidance for it, people either improvise inconsistently or come back to you — defeating the purpose of the SOP. Do not try to cover every scenario (that is how 47-page manuals happen). Cover the common cases and let the escalation rules catch the rest. When a new problem shows up twice, add it. When one stops occurring because the process improved, remove it.
Writing Your First SOP: A Step-by-Step Approach
Step 1: Pick Your Most Repeated Process
Choose the process that happens most frequently and involves the most people. Client onboarding, order fulfillment, content publishing, support ticket handling — whatever fires most often.
Start here because the impact of documenting it is immediate, and the frequency gives you rapid feedback on whether the SOP works.
Step 2: Do the Process While You Document It
Do not write the SOP from memory. Actually run the process one more time and document each step as you do it. You will discover steps you forgot, tools you did not mention, and decisions you make unconsciously that need to be explicit.
Step 3: Test It with Someone Else
Hand the SOP to someone who has never run the process. Have them follow it literally, step by step. Watch where they get confused, where they ask questions, and where they deviate.
Every question they ask is a gap in the document. Fill it. Every deviation is an ambiguity. Clarify it.
If they can complete the process with zero verbal guidance from you, the SOP works. If not, revise it and test again.
Step 4: Distribute and Update
Put the SOP where the team can find it — a shared drive, a Notion page, a physical binder. Make it accessible at the moment when someone needs it, not buried in a folder structure.
Set a calendar reminder to review it monthly. Open the SOP, confirm it is still accurate, update any steps that have changed. This takes five minutes if you do it monthly. It takes hours if you let it go stale.
The Zero-to-Five Sprint
If you have zero SOPs and feel overwhelmed by the idea of documenting everything, run a four-week sprint:
Week 1: Identify your five most critical recurring processes — 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. Do not 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 where the work happens, set review reminders, and start the ongoing “capture as you go” practice for new processes.
After the sprint, add SOPs incrementally — one per week as you encounter recurring processes that need documentation. Within three months you will have fifteen to twenty SOPs covering the vast majority of your operations. All on one page each. All actually used.
SOPs and the EAOS Framework
The One-Page SOP is the tool you use in the Systematize step of the EAOS framework. After eliminating, automating, and outsourcing, the remaining core processes get documented as SOPs.
It is also the tool you use when outsourcing. A freelancer or virtual assistant who receives a one-page SOP can start producing results immediately. A freelancer who receives a vague brief or a 47-page manual cannot.
At Startup Burgenland, the startups that successfully outsourced operations were invariably the ones that had documented their processes first. The ones that tried to outsource without documentation ended up spending more time managing the outsourced work than they would have spent doing it themselves.
Scaling with SOPs
As your business grows, SOPs multiply. The system for managing them:
One SOP per process. Never combine multiple processes into one document. Each process gets its own page.
A master index. A single page that lists all SOPs, their owners, and when they were last updated. This is the table of contents for your operations.
Linked SOPs. If step 4 of one process triggers another process, link to that SOP. My client onboarding SOP links to the invoicing setup SOP, the kickoff meeting SOP, and the CRM data entry SOP. This creates a connected documentation system rather than isolated documents.
Quarterly review. In your Sunday CEO Review, add a quarterly check: open the master index, confirm each SOP is current, flag any that need revision.
New hire onboarding. When someone new joins, hand them the relevant SOPs. Their first week is reading and running the processes under supervision. By week two, they are independent. This is dramatically faster than the alternative — months of shadowing and informal knowledge transfer.
The Connection to Owner Dependency
Every undocumented process is a process that only you can run. The more undocumented processes in your business, the higher your owner dependency score. SOPs are the mechanism that reduces owner dependency — they transfer your knowledge from your head into a document that anyone can follow.
The goal is a business where every critical process has an SOP, every SOP has an owner who is not you, and you can step away for a week without anything breaking. That is the foundation of the clockwork business.
Takeaways
One page per process. Six sections: name and owner, trigger, steps, quality standard, time estimate, escalation. If it does not fit on one page, simplify the process.
Write SOPs by doing the process, not from memory. Test them with someone who has never run the process. Update monthly. Store where people can find them.
The document nobody reads is worse than no document. The one-page SOP gets read, gets followed, and gets updated. That is what makes it a system instead of a shelf decoration.
Start with your most-repeated process. Document it this week. Test it next week. You will immediately see the difference between a process that lives in your head and a process that lives in a system.
