How to Write Standard Operating Procedures for a Small Business

Every small business has a handful of tasks that only one person really knows how to do. Invoicing goes smoothly until that person is on holiday. New hires learn by shadowing whoever is free, and each learns a slightly different version. Mistakes get fixed, and then made again three months later by someone else. None of this is a people problem. It's a documentation problem, and the fix is a set of standard operating procedures that are short enough to be written and clear enough to be followed.

This guide covers what a standard operating procedure (SOP) is, which processes are worth documenting first, how to write one that people actually use, and how to keep the set from going stale.

What a standard operating procedure is

An SOP is a written, step-by-step description of how a specific recurring task is done in your business: who does it, when, using what, in what order, and what "done" looks like. It's not a policy (which says what must happen) or a training manual (which explains why). It's the practical answer to "how do we do this here?", written so that someone competent but unfamiliar could follow it and get the same result.

Good SOPs make a business less dependent on individual memory. They shorten onboarding, reduce errors, make delegation possible, and give you something concrete to improve when a process isn't working.

Which processes to document first

Don't try to document everything. Start where the return is highest:

• Tasks only one person knows. Anything that stops when a specific individual is unavailable.
• Tasks that go wrong repeatedly. Recurring errors usually mean the process lives in people's heads in slightly different versions.
• Tasks you're about to hand over. Hiring, outsourcing or promoting someone is the natural moment to write the procedure down.
• Tasks with compliance or financial consequences. Invoicing, payroll inputs, data handling, safety checks, customer refunds.
• High-frequency tasks. Something done daily by several people benefits more from consistency than something done once a year.

A short list of five to ten procedures, chosen this way, will cover most of the operational risk in a small company.

How to write an SOP people will follow

1. Watch it being done. Ask the person who does the task best to walk through it while you take notes, or record their screen. What people say they do and what they actually do differ; document the real version.
2. Define the trigger and the end state. When does this procedure start (a new order arrives, it's the last working day of the month) and what does finished look like (invoice sent and logged, checklist signed off)?
3. List the steps in order, one action each. Start each step with a verb. "Open the orders sheet" and "Filter by status: unpaid" are two steps, not one.
4. Add what's needed to do each step. Links to the tools, the template to use, the login location (never the password itself), the person to contact if something is missing.
5. Include the decision points. "If the customer is outside the country, go to step 9." Most process failures happen at exceptions, so write them down.
6. Show, don't just tell. Screenshots for anything done in software, a photo for anything physical. A picture of the correct screen removes a paragraph of explanation.
7. Test it on someone else. Give the draft to a person who hasn't done the task and watch where they hesitate. Every hesitation is a missing step or an unclear one.

A simple format that works

You don't need special software. A consistent template in whatever document tool you already use is enough. A practical structure:

• Title (the task, in plain language) and a one-line purpose.
• Owner: who is responsible for keeping this procedure accurate.
• Roles: who performs it, who approves or is notified.
• Trigger and frequency.
• Tools and access needed.
• Steps, numbered, with screenshots where useful.
• Exceptions and what to do about them.
• Definition of done and any record that must be kept.
• Last reviewed date and version.

Keep the whole thing as short as it can be while still being complete. A procedure nobody reads because it's twelve pages long is worse than a one-page one with a small gap.

Common mistakes

• Writing how it should be done instead of how it is done. If you want to change the process, change it first, then document the new version. Documenting an aspiration guarantees the SOP and reality diverge on day one.
• Too much context, not enough instruction. Background belongs in a sentence at the top, not woven through every step.
• No owner. A procedure nobody is responsible for is a procedure nobody updates.
• Storing them where nobody looks. SOPs should live in one shared, searchable place that everyone knows about, linked from wherever the task is actually triggered.
• Treating it as finished. Processes change. Tools get replaced. An SOP is a living document or it's a historical one.

Keeping SOPs current

Build maintenance into how the business already works. When a tool changes or a step is added, updating the procedure is part of the change, not a separate task for later. Ask anyone following an SOP to flag anything wrong or missing as they go; a comment or a quick message to the owner is enough. Review the full set at a fixed interval, quarterly for fast-changing processes and yearly for stable ones, and record the review date so it's obvious when something hasn't been looked at. New hires are an excellent audit: they follow the documents literally, and where they get stuck is exactly where the document needs work.

FAQ

Conclusion

Standard operating procedures are the least glamorous and most useful documents a small business owns. Start with the handful of tasks that depend on one person or keep going wrong, write them the way they're actually done, one clear step at a time, give each one an owner and a home, and treat updates as part of every process change. The payoff is a business that runs the same way whoever is in the room.