How to Write SOPs That Actually Work When You're Not in the Room
You've got a team now. (or you're thinking of building one)
Maybe it's 2 people and maybe it's 5. Maybe you're in that in-between stage where you're hiring faster than you're training, and every new person you bring on feels like a small gamble. Not because they're not good. But because the way things get done in your business still lives mostly in your head, and you haven't fully accepted that yet.
And just to be 100% sure I'm talking to you, let me step into your business for a minute.
You just signed a client, and now you have to onboard that client, but the welcome email goes out a day late because your new hire wasn't sure which template to use. Or, if you don't have a team yet, the welcome email didn't go out because the trigger is YOU and you just... forgot (no judgement -- we've all been there)
A project gets assigned to someone on the team, but 3 things fall through the cracks because nobody was clear on who owned what task. Everyone thought that someone else was handling it, and you only get notified when the client emails you asking "can I have an update please?"
You're constantly getting Slack messages asking how to do something you've explained 5 timesalready, and you type out the answer again because it's faster than finding where you wrote it down last time.
Am I hitting a nerve here?
None of these are business-breaking failures. But they AREadding up. And if you're honest with yourself, you already know that the way your business runs right now is not the way it's going to be able to run at the next level.
That's what SOPs help to fix.
Here's what an SOP actually is, and what it most definitely isn't.
An SOP — Standard Operating Procedure — is a written record of exactly how something gets done in your business. Step by step, in the right order, with enough detail that someone brand new could follow it without having to come back and ask you a single question.
It's not a vague bullet list, or a 3-step overview that skips the parts you do automatically because they feel obvious to you, and it's definitely not the document you've been meaning to write properly since last quarter.
Because the SOP that helps your team is the one that actually exists.
And here's the part I know you know but I'm just going to say it anyway: If your team is making mistakes, missing steps, or coming to you for answers they should already have — that's not on them. That's on the documentation, or the lack of it. It's on YOU. Your team cannot read your mind, and they shouldn't have to. An SOP is how you take what's in your head and make it transferable and actionable.
Once it's written, it becomes the standard.
Where to start, and why you shouldn't try to do everything at once.
The biggest mistake people make with SOPs is trying to document the entire business in one sitting. They open a blank document, feel immediately overwhelmed by the scale of it, and close it. Nothing gets written, and the problem stays exactly where it was.
Don't do that.
Pick ONE process. The one that's costing you the most time, the most errors, or the most repeated conversations. That's where you start.
If you're not sure which one that is, think back over the last 30 days. What did you have to explain more than twice? What task, when you look at the output, makes you think "this isn't quite how I'd do it"? What process, if someone on your team was suddenly unavailable, would cause the most chaos?
That's your first SOP. Start there.
And here's how you'll actually write it (this is the part most guides skip, but NOT us ;)
Most advice on SOPs tells you to "document your processes." I mean... cool. But how?
1. Open a blank document and do the task.
Don't write from memory. Actually do it, in real time, and write down every step as you go.
Not the steps you think you're taking. The ones you're actually taking. Because these are not always the same thing.
We automate so much of our own expertise that we skip over steps without even noticing, and those are exactly the steps your team needs documented.
Use whatever tool you already have. A Google Doc. A Notion page. A page inside your project management system. The tool doesn't matter as much as the habit. The best SOP lives where your team already works.
2. Get specific about the details that feel obvious.
"Send the welcome email" is not a step.
"Send the welcome email using the [Client Welcome] template saved in the Templates folder.
Personalise the subject line with the client's first name. In the first paragraph, reference their project start date and the name of their dedicated point of contact. CC the project manager. Send within 24 hours of the contract being signed." — that is a step.
The difference between those two things is the difference between a team that executes consistently and a team that guesses.
Specificity is not micromanaging. It's clarity, and clarity is what lets your team work without you hovering.
Every time you catch yourself thinking "well, obviously you'd..." — write that part down. Because it is not obvious to someone who hasn't done it before.
3. Be clear about who owns what — especially at the handoff points.
Most process breakdowns don't happen in the middle of a task. They happen at the beginning or the end of the task execution. When one person thinks they're done and the next person doesn't know they're supposed to start.
For every SOP that involves more than one person, name the handoff explicitly. Who starts it, and what "done" looks like for their part. Who picks it up next and what they need from the first person in order to do that. What's the deadline or trigger is for the next step to begin?
If this feels like a lot of detail, good! That detail is what stops the "I thought you were handling that" conversation from happening.
4. Show, don't just describe.
For anything that happens inside a tool—a CRM, a project management platform, an email system—a screenshot or a short screen recording will do more work than three paragraphs of description. Tools have interfaces, and the interface does half the explaining for you.
A quick Loom walking through the steps takes 5 minutes to record and will save you hours of back-and-forth over time. Add it to the SOP. Link it right next to the relevant step. Your future self and your team will thank you.
5. Test it before you trust it.
This is the step most people skip, and it's the most important one.
Hand the SOP to someone who has never done this task before.
Ask them to follow it exactly as written, without asking you questions. Then watch. Not to grade them, but to see where they slow down, where they hesitate, and where they look up with that expression that means "I'm not sure what this is asking me to do."
Every one of those moments is a gap in your documentation. Fill it. Then test it again. An SOP is only finished when someone unfamiliar can follow it start to finish without you in the room.
Where to keep your SOPs so your team actually uses them
This matters more than people think.
An SOP that nobody can find is the same as an SOP that doesn't exist. So wherever you store them, the structure needs to make sense, and it needs to be somewhere your team already goes.
If your team works inside a project management tool, build your SOPs there. Attach them directly to the relevant projects or task templates so they're visible at the moment someone needs them, not buried in a folder they have to go looking for.
If your team lives in Google Drive, create a dedicated folder with a clear naming convention — something like [Team SOPs] > [Department or Function] > [Process Name] — so nothing takes more than 10 seconds to find. Bookmark it in your team Slack channel. Make it stupid easy to find.
The structure honestly matters less than the consistency. Pick a system, commit to it, and make sure every person on your team knows where to look.
One more thing: as your business grows, your processes will change. Build in a review rhythm — quarterly works for most businesses — where you go through your SOPs and update anything that no longer reflects how things actually get done.
An outdated SOP can be just as damaging as no SOP at all, because your team will follow it and then you'll have to redo the whole damn thing all over again.
The bottom line
The thing nobody tells you about building systems at this stage.
Writing the SOP is the easy part.
The harder part is the moment you realise your business has grown beyond what one person can hold in their head , and that what got you here, your instincts, your standards, your way of doing things — now needs to be transferable. That's a different skill., and it's it's one most people underestimate.
The founders who scale without burning out aren't the ones working harder. They're the ones who figured out how to take what lives in their head and build it into the structure of their business. SOPs are the foundation of that.
You don't need to do it all at once. You just need to start with the one process that's costing you the most right now. Write it down. Test it. Hand it off. Then do the next one.
That's how a business stops being dependent on one person, and starts being able to run without you.
Creating SOPs is the first step toward building a more streamlined and scalable business. But if you’re ready to implement sustainable tech solutions that will grow with you, we’re here to help. Reach out to us here to discover how we can help build your ideal tech and process ecosystem.