Ask most founders of small service businesses why they don't have systems and you'll hear the same thing: "I wrote some SOPs once. Nobody read them."
That's usually true. The SOPs were long, written by the founder from memory, stored in a folder nobody opens, and out of date within three months. The team went back to asking the founder how things are done, which is what the SOPs were supposed to stop.
SOPs that get used look different. They're short, written with the people who do the work, stored where the work happens, and someone owns keeping them right.
What counts as an SOP in a small agency
A standard operating procedure is just the agreed way to do a recurring task, written down so it happens the same way whoever does it. In a ten-person agency, that's not a binder of 80 policies. It's maybe 10 to 15 short documents covering the things that happen every week and go wrong when they're done differently each time.
Which processes to write first
Don't start by documenting everything. Start with processes that score high on these three questions:
- How often does it happen? Weekly beats yearly.
- How expensive is it when it goes wrong? A missed QA step that ships a broken checkout costs more than an inconsistent folder name.
- Does it live in one person's head? If that person is off sick, does it stop?
For most agencies, studios and dev shops, the first five are:
| Process | Why first |
|---|---|
| New client onboarding | Sets expectations for the whole relationship |
| Project kickoff | Where scope, access and timelines get agreed |
| QA before anything goes to a client | Mistakes here are visible and costly |
| Sending invoices and following up | Cash depends on it happening on time |
| Onboarding a new hire | Repeats with every hire, and usually depends on the founder |
The one-page format
Every SOP uses the same headings, so people know where to look:
Title: [Verb + object, e.g. "QA a website before client review"]
Owner: [Name of the person who keeps this current]
Applies to: [Roles]
When: [Trigger: what starts this process]
Last reviewed: [Date]
Why this matters (one line):
Steps:
1.
2.
3.
Done when:
If something goes wrong:
The "when" line is the one most SOPs skip, and it's the most important. "QA a website" is a task. "Before any link is sent to a client for review" is a trigger. People follow SOPs when they know exactly when one applies.
Three examples
QA a website before client review
Owner: Priya (QA lead)
Applies to: Developers, designers
When: Before any staging link is sent to a client
Why: Clients judge us on the first thing they click.
Steps:
1. Open the staging link in Chrome, Safari and on a phone.
2. Click every link in the nav and footer. None should 404.
3. Submit every form with test data. Check the submission arrives.
4. Check page titles and favicons are set (no "React App").
5. Read every heading for typos and placeholder text.
6. Run the page speed check and note any red scores in the ticket.
7. Add "QA done" with any known issues to the ticket before sharing.
Done when: The ticket has a "QA done" comment and the link is sent.
If something goes wrong: Don't send. Post in the project channel and tell the PM.
Kick off a new client project
Owner: Sam (delivery lead)
Applies to: Project managers, account leads
When: Within 2 working days of a signed proposal
Steps:
1. Create the project with the scope from the signed proposal attached.
2. Book the kickoff call with the client's decision-maker, not just their PM.
3. Send the access request list (hosting, analytics, brand files, logins via their password manager).
4. Agree the feedback process: who gives it, by when, how many rounds.
5. Set the first three milestones with dates and confirm them in writing.
6. Create the internal channel and add only the people on the project.
Done when: Client has confirmed milestones in writing and access is received.
Send monthly invoices
Owner: Lena (operations)
Applies to: Operations
When: First working day of each month
Steps:
1. Pull logged hours for every hourly client for last month.
2. Check them against any cap in the contract; flag overages to the account lead.
3. Draft invoices; account leads approve by end of day 2.
4. Send by day 3, with the payment terms on the invoice.
5. Diary a check at the due date. If unpaid, send the reminder template.
Done when: Every invoice is sent and its due date is in the calendar.
Notice what's not in these: background on the agency's values, a history of why the process exists, or every edge case. Edge cases go under "If something goes wrong" or in a separate note.
How to write one in 30 minutes
- Ask the person who does it to talk you through the last time. Record it or take notes. Don't write from your memory of how it should work.
- Turn what they said into numbered steps. Each step starts with a verb.
- Add the trigger and the "done when". Ask them: how do you know when to start, and how do you know you've finished?
- Have someone who's never done it follow the draft. Wherever they get stuck, add a step or a screenshot.
- Name an owner and a review date.
Step four matters most. An SOP that only makes sense to the person who wrote it isn't an SOP yet.
Getting people to read and follow them
Writing is half of it. The other half is making sure the SOP reaches the right people and stays current.
Put them where the work happens. Link the QA SOP from the QA column on the board. Link the kickoff SOP from the project template. An SOP people have to go looking for is one they won't use.
Send each SOP to the roles it applies to. Developers don't need the invoicing process. Sending everyone everything means nobody reads anything.
Check it's been read. It's reasonable to ask people to confirm they've read a procedure, especially new joiners and especially after a change. In Suprwork, SOPs are assigned by role, people confirm they've read them, a new version asks everyone to confirm again, and you can see who hasn't. It doesn't send reminders to staff, so following up on the stragglers is still on you.
Review on a schedule. Each SOP gets a review date. When it comes up, the owner checks it against how the work is actually done now. An outdated SOP is worse than none, because people follow it and get it wrong.
Fix it the moment someone finds a problem. If someone says "step 4 doesn't work any more", update it that day. It tells the team the documents are live.
Where to keep them
A folder of Word files works for five SOPs. Past that, you want them in one searchable place with owners and dates. A shared wiki, Google Docs with a clear index, or a documents area inside the tool your team already uses all work. What matters is that there's one place, everyone knows where it is, and every SOP has an owner.
This week
Pick the one process you get asked about most. Ask the person who does it best to talk you through it, write it in the one-page format, and have a newer team member follow it. Fix what confuses them. That's your first SOP. Do one a week and you'll have your core set in a quarter.