Standard operating procedures (SOPs)

Why it matters

Without procedures, quality depends on memory and on who is rostered. Training takes longer because it happens by shadowing. Mistakes repeat because the fix lives in one person’s head. And the business is worth less to a buyer or lender, because it cannot run without the owner. SOPs are one of the cheapest ways to make a business consistent, trainable and saleable.

Decide which tasks deserve a procedure

Not everything needs an SOP. Documenting every task produces a binder nobody reads. The tasks worth writing down share some features: they recur, more than one person does them (or will), the cost of getting them wrong is real, and there is a right way that is not obvious. Compliance tasks such as food safety checks, workplace safety procedures and handling customer personal information under the Privacy Act are usually first on the list.

A good test is to ask: if the person who normally does this were away for a month, what would break? Those tasks go first. Judgement-heavy work, such as pricing a complex job or handling an unusual complaint, suits a checklist of considerations rather than a rigid step list.

• Recurring tasks done by several people, now or soon.
• Tasks where an error costs money, safety or a customer.
• Compliance tasks that regulators or insurers expect to see documented.
• Anything a new starter must be able to do in their first month.

Write for the person doing the job

The most common failure is writing an SOP from the owner’s point of view: long paragraphs of context and policy, with the actual steps buried near the end. Write instead for a competent new starter standing at the counter or the workstation. Lead with the outcome, list what they need, then give numbered steps, one action per step, in the order they will do them.

Use the words and screen names your team actually uses. Add a screenshot or a photo wherever a step involves a screen or a physical setup. Keep it to one or two pages; if the procedure runs longer, split it. Where a step requires a decision, state the rule plainly: "If the refund is over $200, get the manager to approve before processing."

Test it on someone who has never done the task

An SOP is only finished when someone who did not write it can follow it without asking questions. Hand the draft to a team member unfamiliar with the task and watch them use it. Every pause, question or mistake marks a step that is missing, ambiguous or in the wrong order. Fix those and test again.

This step is routinely skipped, and it is why so many procedures gather dust. A procedure that has been tested by a novice is a procedure the team trusts.

Store, find and keep procedures current

Procedures are useless if nobody can find them at the moment they are needed. Keep them in one place the team already uses: a shared drive folder with a sensible structure, a wiki, or the knowledge base inside your job or practice management software. Name them consistently and link the relevant SOP from the place the work happens, such as the till, the workshop wall or the onboarding checklist.

Give every SOP an owner and a review date. When a process changes, the owner updates the document that week, not at the annual review. A small library of twenty accurate procedures is worth far more than two hundred stale ones.

How to build your first set of SOPs

1. List candidate tasks Ask what would break if each person were away for a month. Rank by frequency and cost of error.
2. Pick five to start Choose high-frequency, high-cost tasks and compliance items first. Resist the urge to document everything.
3. Record the expert Have the person who does it best narrate a video while performing the task.
4. Draft one page per procedure Outcome, trigger, what you need, numbered steps, how to check, what to do if it goes wrong.
5. Test with a novice Watch someone unfamiliar follow it. Fix every point where they hesitate.
6. Approve, store and link Owner signs off with a version date. Store centrally and link from where the work happens.
7. Train and review Introduce it in a team meeting, then review on the set date or when the process changes.

Real-world example

A Sunshine Coast café writes its opening procedure

Shoreline Café employs eleven casual staff and opens at 6 am. The owner, Marcus, has been doing almost every open himself for three years because the two times he delegated, the coffee machine was not warmed up, the float was wrong and the online ordering tablet was left off until 8 am. He films himself doing the open on a Tuesday, narrating as he goes, and turns the recording into a one-page SOP with eighteen numbered steps and four photos.

He asks a barista who has never opened to follow it on Thursday while he watches. She hesitates at three points: where the float bag is kept, the alarm code process, and the order the machines should be switched on to avoid tripping the circuit. He fixes all three. Within a month, four staff can open the café, Marcus takes his first weekday morning off in three years, and the procedure is linked from the roster so whoever is on the opening shift can check it on their phone.

Common mistakes

• Writing policy instead of procedure Pages of context and rules with the steps buried at the end. Lead with the steps; put background in a separate note if it is needed at all.
• Never testing on a novice The author cannot see their own gaps. If a new person cannot follow it unaided, it is not finished.
• Documenting everything A huge library is expensive to maintain and nobody reads it. Twenty accurate procedures beat two hundred stale ones.
• Storing SOPs where nobody looks A binder in the office or a forgotten folder is as good as nothing. Link the procedure from the place the work happens.
• No owner or review date Procedures drift from reality as tools and processes change. Without an owner, nobody notices until something goes wrong.

KPIs to track

• Critical tasks documented Share of your high-frequency, high-cost tasks that have a tested SOP. Aim for all of them within a year.
• Time to competence for new starters Days until a new team member performs core tasks unsupervised. Good SOPs shorten this noticeably.
• Procedure-related errors Mistakes traced to a step being skipped or done wrong. They should fall as procedures are tested and adopted.
• SOPs past their review date Count of stale procedures. Keep it near zero; it is a simple health check for the library.

Frequently asked questions

How long should an SOP be?

Usually one page, two at most. If a procedure needs more, split it into separate procedures that each produce a clear outcome.

Who should write SOPs: the owner or the staff?

The person who does the task best should provide the content, ideally by recording themselves. The owner or process owner edits and approves. Staff-written procedures are more accurate and more likely to be followed.

Do I need software to manage SOPs?

Not at first. A well-organised shared folder works for a small library. Dedicated tools help once you have dozens of procedures, several locations or need to track who has read what.

What about tasks that need judgement?

Use a checklist of considerations and decision rules rather than a rigid step list. Document what must always happen and who to escalate to, and leave room for judgement in between.

Key takeaways

• SOPs make quality independent of memory and rostering, and make the business trainable and saleable.
• Document the tasks that would break if a key person were away, not everything.
• Write for the new starter: outcome, what you need, numbered steps, how to check.
• A procedure is finished only when a novice can follow it without asking questions.
• Store SOPs where the work happens and give each one an owner and a review date.