1 October 2026 · 8 min read · Delegation
Most SOPs get written once and ignored forever. Here's how to write one your first hire can actually follow, without losing a weekend to a manual.
You know you need to document things before you hire. You've known for months. Maybe you even opened a blank Google Doc, typed "Client Onboarding Process" at the top, and closed it twenty minutes later with nothing underneath.
That's normal. Most founders don't avoid SOPs because they're disorganised. They avoid them because the idea of an SOP is so much bigger and heavier than the thing it actually needs to be.
An SOP isn't a manual. It's a set of instructions clear enough that someone who has never done the task can do it the way you'd want it done, without messaging you halfway through.
That's the whole test. Here's how to pass it.
The instinct is to document the big stuff first. Sales process. Client delivery. The things that feel like the business. Don't. Start with something you do every week that takes under an hour and bores you slightly. Sending invoices. Scheduling the newsletter. Uploading a podcast episode.
Small, repetitive tasks are easier to write up and easier to test, and they get off your plate faster. You also learn how you write instructions, which makes the bigger SOPs quicker later.
This is the shortcut almost nobody uses. Next time you do the task, record your screen and talk through what you're doing out loud. Loom works. So does the screen recorder already on your laptop.
Talk the way you would if someone was sitting next to you. "Okay, I open the client folder, and I always check the date on the last invoice first, because if it's more than 30 days old I send a reminder instead."
That last bit, the "because" and the "if", is gold. It's the judgment you apply without noticing, and it's exactly what's missing from most SOPs.
Then hand the transcript to an AI assistant like Claude and ask it to turn it into numbered steps. You'll have a first draft in a few minutes instead of an afternoon.
That last item saves you the most messages. Spell out the two or three situations where you actually want to be pulled in. Everything else, they decide.
"Set up the client in Dubsado and send the welcome sequence" is two steps pretending to be one. When someone gets stuck, they need to know exactly where.
Start each step with a verb. Open. Click. Copy. Check. Send. If a step won't start with a verb, it's probably a decision rather than an action, and decisions need their own line explaining how to make them.
Not everywhere. Just at the points where a button is hard to find, a setting is buried, or the screen looks different depending on which view you're in. A screenshot with a red circle around the right button prevents more mistakes than a paragraph of explanation ever will.
Founders skip this step, and it's the one that matters most. Hand the SOP to your new hire, a friend, or even your partner, and watch them follow it without helping. Every time they hesitate, frown or ask a question, you've found a gap.
Write the answer into the SOP. Then test again. Two rounds usually gets you something solid.
If your first hire keeps asking you questions, the SOP isn't finished yet. That's useful information, not a sign you hired the wrong person.
Somewhere your team already looks every day. If you run projects in ClickUp, attach the SOP to the recurring task itself, so the instructions sit right next to the work. If you live in Google Workspace, one shared folder called SOPs with a simple naming pattern is enough to start.
Nobody should have to ask you where the SOP lives. If they do, it's in the wrong place.
SOPs go stale. Tools update, you change how you do something, and suddenly step four points to a button that no longer exists. Make the person who does the task responsible for updating the SOP whenever something changes. They're closer to the work than you are, and it gives them real ownership.
Once a quarter, skim the list and archive anything nobody uses anymore.
Fewer than you think. Three to five, covering the tasks you're handing over first, is plenty. Write the rest as you delegate them. Writing twenty SOPs before anyone joins usually means half of them describe a version of the business that's already changed.
As long as it needs to be for someone new to do the task without asking. For most weekly tasks, that's one or two pages. If it's running past five, it's probably two or three separate tasks.
It can write a strong first draft from your recording or rough notes. It can't know the judgment calls you make unless you say them out loud. Use it to save the typing, then check every step against how you actually do the work.
Once they've learned a task, yes. Having them document what they learned from you is a great way to catch gaps. For the first handover though, the knowledge is in your head, so the first version has to come from you.
A checklist reminds someone who already knows the task. An SOP teaches someone who doesn't. Your new hire needs the SOP first. After a month or two, a checklist is usually enough.
Getting the knowledge out of your head and into documents your team can actually use is a big part of the 90-Day AI Operations Sprint. The AI Operations Audit is where it starts. Ninety minutes, an honest look at what's undocumented, and a written plan for what to capture first.
Or get in touch and tell me which task you'd hand off first if the instructions already existed. I'll tell you how I'd document it.