Business Standard Operating Procedures: How to Build Them
The minimum viable approach to writing business SOPs that actually get used. No corporate template. No weekend retreat. Just the three sittings that finally get your business out of your head.
It is 3:47 on a Tuesday afternoon. You had blocked the next hour to take a walk before school pickup. The Slack notification lights up. One of your team members needs to know how you handle the deliverable when a client misses the third check-in. She has asked this before. You have answered it before. But the answer lives in your head, and your head is not a place she can go.
You type out three paragraphs from your phone. You miss the walk. You pick up your son. He asks if you're listening. You say yes.
This is what we mean when we say a business is living inside the founder. The business is not living in software. It is not living in a folder. It is living in you. Every time someone needs an answer that only you have, the business takes a little more of your day and gives you a little less of your life back.
Business standard operating procedures are the documented version of how decisions get made in your company. They are not corporate documents. They are not a weekend project. They are the work of moving what lives in your head onto a page so your team can do the work without finding you for the answer.
Most founders I work with have known they need SOPs for two years. They have not written them. Not because they are lazy. Because the standard approach is too big to start.
This is the smaller approach.
Related Blog Post: What a Business Operations Consultant Actually Does
Key Takeaways
📌 Business SOPs are the documented version of how decisions get made in your company. The format is less important than the fact that they exist.
📌 The reason yours have not been written is not discipline. The standard approach is too big to start, so nothing starts.
📌 You can build three working SOPs in three sittings of forty-five minutes each. That is the minimum viable version.
📌 The trap is writing SOPs in a Google Doc no one opens. Store them where the team already works.
📌 An SOP without an owner and a review date will be wrong inside six months. Build the maintenance in, or do not write the SOP.
What Business Standard Operating Procedures Actually Are (And Aren't)
A business standard operating procedure is a written record of how a specific task gets done in your business. That's the whole definition. It includes who does it, when it is done, what the inputs are, what the outputs are, and what decisions get made along the way.
What an SOP is not: a flowchart someone drew in a workshop three years ago. A Notion page that hasn't been opened since onboarding. A Loom video buried in a folder with no title.
The Institute of Management Accountants frames the value of SOPs plainly. For small businesses, SOPs are how you preserve consistency, reduce error, and grow without losing the founder's standard. They are how the standard moves from the founder's brain to the team's hands.
McKinsey puts a finer point on the cost of not having them. Their research found that cross-cutting management processes can consume 40 to 65 percent of management and overhead time when they are not standardized. For a service founder, that 40 to 65 percent is your week. It is your Tuesday afternoon walk. It is your morning quiet.
The number is not the point. The point is what the number is taking from you.
Why Your Business SOPs Keep Sitting in a Drawer
You have started SOPs before. You bought the template kit. You filled out two pages in January. You have not opened the folder since.
The reason is not that you stopped caring. The reason is that the template was built for somebody else's business. The categories did not match how your work actually flows. The fields asked for information that does not exist in your operation. The format made you feel further behind, not further along.
The other reason is the size of the lift. When someone tells a founder to "document her processes," she hears: build forty SOPs covering every department, in matching format, with version control. That is not a project. That is a relocation.
So the documents sit. The business stays in your phone. The team keeps finding you for the answer.
The shift that gets SOPs out of the drawer is this: stop trying to write every SOP. Start with the three that are bleeding the most time, build them in the smallest viable form, store them where the team already works, and assign each one an owner and a review date.
That is the architecture. The rest is sittings.
How to Build Business SOPs Without Spending a Weekend
This is the five-step approach I walk founders through inside Scale With Sanity. It is the approach I use for myself. It does not require a retreat. It does not require new software. It requires three sittings of about forty-five minutes each.
Step 1: Pick the three processes that bleed the most time
Sit with a notebook for ten minutes. Answer one question: what are the three things my team asks me about most often?
These are usually:
Client onboarding (the contract, the welcome packet, the first meeting setup)
Decision-making at a known choke point (refunds, scope changes, client escalations)
A recurring delivery (the weekly report, the monthly close, the quarterly review)
Pick the three that you answered out of your phone or out loud at least four times in the last month. Those are your first three SOPs. Everything else can wait.
Step 2: Record yourself doing the work once
Open Loom or Granola or any tool that records you talking through a process while you do it. Run through the work once, out loud, in real time, while it is being done.
Do not script it. Do not edit it. Talk through every decision. When you make a judgment call ("this is the one I'd flag for a discount" or "this is when I escalate"), say the call out loud and say why.
The recording becomes the source. You will never have to remember the SOP again. It is on tape.
Step 3: Strip it to the essential decisions, not every keystroke
This is the part most founders skip and most templates get wrong. You do not need to document every keystroke. Your team is not learning to use the software. They are learning to make the call.
Watch your recording back. Pull out:
The trigger (when does this start)
The decisions (what are the two or three calls being made)
The exceptions (when does it stop being the standard process)
The output (what does done look like)
The handoff (who picks it up next)
That is your SOP. Five sections. Half a page. It can be longer when it needs to be, but it almost never needs to be.
⚡ Pro Tip: Run the Loom recording through an AI transcription tool, then ask it to summarize the five sections above. It will give you a rough first draft of the SOP in under two minutes. You edit. You sign off. The whole sitting takes forty-five minutes per process. You do three sittings. You have three SOPs. The lift is real, but it is not a weekend.
Step 4: Store the SOP where the team already works
This is the step where most SOPs go to die. Founders create a beautiful folder structure, label everything, and the team never opens it again.
Store the SOP in the place the work actually happens. If the team uses ClickUp, put the SOP in the task template. If the team uses Notion for client work, embed the SOP at the top of the client database. If the team uses Slack channels, pin the SOP to the channel.
The rule: the SOP lives one click away from the work it describes, or it does not live at all.
Step 5: Assign an owner and a review date
An SOP without an owner is a draft. An SOP without a review date will be wrong in six months.
For each SOP, name:
The owner (one person, not a team)
The review cadence (quarterly is the default)
The first review date (put it on the calendar before you close the file)
The owner does not have to be the one who wrote it. The owner is the one who keeps it true. When the process changes, the owner updates the document. When the document is up for review, the owner reads it, edits it, and re-pins it.
This is the part that makes SOPs durable instead of decorative.
Business SOP Examples That Travel Well
Here are five SOP examples drawn from service businesses we have built operations for. Each one is the half-page version, not the manual.
New client onboarding SOP. Trigger: signed contract received. Decisions: which onboarding track, which team member leads, which welcome packet variant. Exception: returning client (skip welcome packet, go straight to kickoff). Output: kickoff call booked, client folder created. Handoff: account lead.
Refund request SOP. Trigger: client requests a refund. Decisions: was service delivered fully, was the service within the refund window, is there a partial credit option. Exception: client is in active conflict, escalate to founder. Output: written response, refund issued or denied. Handoff: bookkeeping.
Weekly client report SOP. Trigger: every Friday by 10am client time. Decisions: which metrics are included this week, which wins to highlight, which risks to flag. Exception: client is in their last 30 days (use the wrap-up report variant). Output: report sent, calendar invite for review call confirmed. Handoff: account lead.
Hiring a contractor SOP. Trigger: workload exceeds capacity for two consecutive weeks. Decisions: contractor role, rate band, trial scope. Exception: hire is for a specialized one-off (skip trial, use referral pipeline). Output: contractor agreement signed, first task assigned. Handoff: project manager.
Client offboarding SOP. Trigger: final invoice paid. Decisions: testimonial ask, referral conversation, archive level. Exception: client is moving to a higher tier (skip offboarding, run onboarding instead). Output: thank-you note sent, archive complete, asset transfer confirmed. Handoff: bookkeeping.
These look small. They are small. That is the point. A small SOP that is actually used is worth ten beautiful ones that are not.
Frequently Asked Questions
What is the difference between a business SOP and a business operating procedure?
In most service businesses, they are the same thing. "Standard operating procedure" is the more formal term, often used in regulated industries like manufacturing or healthcare. "Business operating procedure" is sometimes used as the everyday version. The format matters less than whether the document is current, findable, and owned.
What are good examples of standard operating procedures for a small business?
The strongest SOPs for a small service business cover the processes that touch the client (onboarding, delivery, offboarding), the processes that touch the team (hiring, performance check-ins), and the processes that touch the money (invoicing, refunds, contractor payments). Start with the five examples in the section above. Add as you grow.
How do you write SOPs for a company without making them feel corporate?
Two things. First, use your own language. If your business talks to clients in plain warm language, your SOPs should be written the same way. Second, keep them short. A half-page SOP is more likely to be used than a five-page one. The SOP is not a legal document. It is a working tool.
Where should business SOPs be stored so the team actually uses them?
Store the SOP one click away from the work it describes. If the team manages projects in ClickUp, the SOP belongs in the task template. If the team works in Notion, embed it in the relevant database. If the team works mostly in Slack, pin the SOP to the channel where the work happens. A central SOP library is fine as a backup, but the working copy lives next to the work.
Wrap Up
The reason your business standard operating procedures have not been written is not that you are not disciplined enough. It is that the standard approach is too big to start, the templates were built for somebody else, and nobody told you that three SOPs of half a page each is a real starting point.
Three sittings. Three SOPs. One owner each. One review date each. Stored where the team already works.
That is the architecture. From there, you add one SOP a month until the most common questions stop coming to your phone on a Tuesday afternoon.
You built something extraordinary. You can build it so it runs without you holding it together. The first three SOPs are the doorway.
Thanks so much for reading.
If this is the version of the problem you've been carrying, the next step is a quiet conversation. Book a sanity call. We'll look at what your business is actually asking of you right now, and whether the operational architecture you need is something we should build together.
If you want a head start before the call, the SOP starter kit walks you through the first three SOPs with the format I use with retainer clients.
If you are not ready for a call and you are not ready for the starter kit, that is okay. Subscribe to the newsletter and let me write to you on the Tuesdays your shoulders are tight. Sometimes that is the work.
