How to Write SOPs for Your Small Business (Without It Taking Forever)

The phrase "standard operating procedure" sounds like something from a large corporation — a thick binder on a shelf that nobody opens, filed under the ISO certification that also never gets looked at. If that's what you picture when someone mentions SOPs, I understand why you've been avoiding them.

But there's a different way to think about SOPs: they're the answer to every question you answer more than once. Every time a staff member asks "how do I handle X?", every time you explain your onboarding process to a new contractor, every time a task gets done wrong because nobody knew the right way — that's an SOP waiting to be written.

This article is a practical guide to writing SOPs for a small NZ business — one that doesn't require weeks of work, doesn't produce documents nobody reads, and actually helps your team do things right without you.

Why SOPs Actually Matter (Especially for Small Businesses)

There's a common assumption that SOPs are for big businesses with large teams. The reality is the opposite — small businesses with one to ten staff often benefit more from SOPs than large ones, because:

• You can't be everywhere. When you're the only person who knows how something is done, you become the bottleneck. SOPs break that dependency.
• Staff turnover is painful without them. Every time a team member leaves, institutional knowledge walks out the door. SOPs keep that knowledge in the business, not in a person's head.
• They reduce errors. The most expensive version of "I didn't know we did it that way" is a client complaint, a billing error, or a compliance failure. A clear process document prevents most of these.
• They free up your time. Every question you answer repeatedly is a fixed cost on your attention. An SOP converts it to a one-time investment.
• They make your business sellable. If the business only works because you personally hold all the knowledge, you don't have a sellable asset. SOPs are part of what turns "a job I do" into "a business that runs."

Where to Start: Prioritising What to Document

The biggest mistake people make with SOPs is trying to document everything at once. This leads to a six-week project, a folder full of half-finished documents, and no actual change in how the business runs.

Start with a short list of your highest-value processes. A good filter:

• Things you explain repeatedly. If you've explained a process three or more times to different people, it should be a document.
• Things where mistakes are expensive. Client onboarding, billing processes, quality checks — anywhere an error has a real cost in time, money, or reputation.
• Things that only you know how to do. These are your highest single points of failure. They're also often the hardest to write because you do them instinctively — but that's exactly why they need documenting.
• Things you're about to hire for. If you're bringing on a new person, documenting their core tasks before they start makes onboarding dramatically faster and reduces early mistakes.

Pick three to five processes and commit to documenting those before touching anything else.

A Simple SOP Format That Actually Gets Used

Good SOP format is simple. Here's a structure that works for most small business processes:

1. Process name — clear and specific ("Invoice a new client after job completion," not "Invoicing")
2. Purpose — one sentence on why this process matters and what happens if it's done wrong
3. Who does this — specific role, not "the team"
4. When it happens — trigger or frequency ("after a job is marked complete in the system," "every Friday afternoon")
5. What you need — tools, logins, materials required to complete the process
6. Steps — numbered, action-oriented, one action per step
7. What done looks like — the definition of success so the person knows when they're finished
8. What to do if something goes wrong — the most common edge cases and how to handle them

You don't always need all eight sections. A simple recurring task might only need a name, a trigger, and a numbered checklist. Don't add structure for its own sake.

How to Write Steps That Are Actually Useful

The most common failure mode in SOP writing is steps that make sense to the writer but not to the reader. Here's how to avoid it:

Start each step with a verb

"Open the job in the system" is a step. "The job should be opened" is not. Every step should be an instruction, not a description. The person reading it should know exactly what action to take.

Write for the person who doesn't know the context

What feels obvious to you often isn't to someone doing a task for the first time. Include the "why" behind non-obvious steps. "Email the invoice to billing@clientname.com, NOT the contact's personal email — this ensures it goes through their accounts system" is more useful than "email the invoice."

One action per step

"Log in, navigate to the jobs list, filter by this week, and export to CSV" is four steps, not one. Split compound actions. This makes it easier to follow in real time and easier to update later when one part of the process changes.

Include screenshots for software processes

If the process involves navigating a system, a screenshot showing exactly which button to click is worth ten lines of description. Screen recording tools like Loom let you record your screen and narrate as you go — a two-minute video can replace a detailed written procedure for visual tasks.

Specify exact values, not vague guidance

"Send a follow-up soon" is not a step. "Send a follow-up email within two business days" is. Be specific about timing, thresholds, and quantities wherever they matter.

Video SOPs: When They Beat Written Docs

For many small business processes, a five-minute screen recording with commentary is more useful than a written document — and significantly faster to create. Screen recording tools worth using:

• Loom — free for basic use, excellent for screen recording with webcam overlay. Popular with NZ remote teams.
• Scribe — automatically generates step-by-step documentation with screenshots as you complete a process. Remarkably fast for software procedures.
• QuickTime or the built-in screen recorder on Mac is fine for simple recordings — combine with a Google Doc for the written companion.

The best format is often both: a short video for the first run-through and a written checklist for subsequent times when someone needs a quick reminder without watching the full video again.

Where to Store Your SOPs

The best SOP system is the one your team actually opens. Fancy documentation platforms are useless if nobody navigates to them. Some practical options for NZ small businesses:

• Notion — excellent for linked SOPs with a clean interface. Good search. Works well for teams of 2–20 people. Free tier is sufficient for most small businesses.
• Google Docs in a shared Drive folder — simple, familiar, searchable. Not glamorous but gets the job done. Good if your team is already in the Google ecosystem.
• Confluence — powerful for larger teams, overkill for most NZ SMBs. Worth considering if you're already using Jira.
• Your project management tool — if your team lives in Asana, Monday, or ClickUp, keeping SOPs there (as templates or documentation pages) means they're in context when people need them.

Avoid storing critical SOPs only in someone's personal Drive or on a local device. If they leave, the document leaves with them.

The Maintenance Problem

An SOP that's out of date is worse than no SOP — it creates false confidence that a process is documented when it actually isn't.

Build a maintenance habit from the start:

• Put a "last reviewed" date on every SOP. When someone notices it's out of date, they should update it in the moment, not put it on a list.
• Make updating SOPs part of the process change workflow.When you change how something is done, updating the SOP is part of "done." Not an afterthought.
• Assign ownership. Each SOP should have one person responsible for it. "Everyone is responsible" means nobody is.
• Review annually at minimum. Block an hour each year to scan your SOP library and flag anything that needs updating. Most won't — but the ones that do will matter.

Getting Over the Blank Page

The hardest part of writing an SOP is starting. The trick is to do it while you're doing the process — not from memory. The next time you complete a task you know should be documented, record yourself (on Loom or just your phone), narrating what you're doing as you go. Then use the recording to write the steps. Takes 20 minutes instead of two hours.

Alternatively, have a team member or contractor shadow you doing the task and have them write the steps. They'll ask questions about things you've automated in your head — "why do you do it this way?" — and the answers will make the SOP significantly more useful.

You don't need to build a perfect SOP library. Start with three well-written documents that cover your most important processes, and build from there. Three useful SOPs your team actually references are worth more than thirty that sit untouched in a folder.