How to create standard operating procedures that staff use

Standard operating procedures only help if people can use them in real work. This guide shows how to choose the right processes, map the actual steps, write clear instructions, test them with staff and keep them current without creating bureaucracy.

By Grace Morgan · Published 13 October 2026 · Updated 13 October 2026 · 12 min read

A busy owner often notices the same pattern at the worst possible moment: one person knows how to do a task properly, everyone else does it a slightly different way, and the work only runs smoothly when that one person is on duty. Then comes the holiday, sick leave or handover, and the cracks show up as delays, mistakes, customer complaints or awkward rework.

Standard operating procedures, or SOPs, are one of the simplest ways to reduce that dependence on memory and verbal instructions. Done well, they turn repeated know-how into a clear, repeatable way of working. Done badly, they become long manuals that nobody reads and no one trusts.

The aim is not to document every possible detail. It is to give the person doing the work enough structure to get it right first time, without making the business slower or more bureaucratic than it needs to be.

What an SOP is and why it matters in a business

An SOP is a written set of instructions for carrying out a specific task or process. In plain English, it explains what to do, who does it, when it starts, what “finished” looks like and what to do if something goes wrong.

That makes a useful SOP different from a rigid policy manual. A policy says what the business expects. An SOP shows how the work is actually done. If the procedure is too formal, too long or too theoretical, staff will ignore it and go back to asking colleagues. If it is too thin, it will not help them make the right judgement when the task becomes messy.

The benefit is practical. Good SOPs can help you keep delivery consistent, train new starters faster, delegate with more confidence, reduce avoidable errors and make handovers cleaner. They also help when you need cover at short notice, because the work does not depend entirely on one person’s memory.

There is a trade-off, though. The more detail you add, the more time it takes to write, read and maintain the document. If you try to capture every exception and every possible variation, the SOP becomes harder to use. Clarity matters more than completeness.

Start by choosing the right processes

You do not need to document everything at once. In fact, trying to do so is a common reason SOP projects stall. Start with the processes that are most repeated, most risky or most likely to cause questions and mistakes.

A sensible shortlist often includes customer-facing work, compliance-related tasks, finance steps, supplier handling and any process that only one person really knows. If a mistake would be costly, embarrass the business or slow down cash collection, that process deserves attention first.

Useful examples include:

• onboarding a new starter
• handling a customer order issue or complaint
• approving expenses or supplier invoices
• processing a refund or credit note
• carrying out a weekly stock check
• closing month-end accounts

Another way to choose is to ask: if the key person were absent for a week, which tasks would cause the most disruption? Those are usually the best candidates for your first SOPs.

For a small business, this also keeps the work manageable. A handful of strong procedures is more useful than a large library of half-finished documents.

Map the process before you write it

The most common mistake is to write the SOP as you would like the process to work rather than as it actually works. Before you draft anything, observe the task in real life. Watch what happens from trigger to finish. Note the detours, checks, tools and decisions that people use in practice.

Every process has a start point, a set of steps, some inputs and an output. The trigger might be an email, a customer request, a system alert, a delivery arrival or a deadline. The output is what counts as a completed job. In between, identify who does what, which systems are used and where a judgement call is needed.

A simple process map is often enough at this stage. It shows the main steps and decision points without turning the exercise into a design project. A checklist can then work well for straightforward tasks where order matters but the logic is simple. A flowchart is more useful if the process has branches, for example when different actions depend on the size of an order, the type of customer or whether a document is missing.

For example, an order issue process might begin when a customer emails about a damaged item. The first step may be to verify the order reference, then check the proof of damage, then decide whether to replace, refund or escalate. Capturing that sequence before you write the SOP helps you spot the points where staff often hesitate.

This is also the point to decide what information belongs in the procedure and what belongs elsewhere. Forms, templates and reference documents can support the SOP, but they should not be crammed into the step-by-step instructions if that makes the main process harder to follow.

Write the SOP in a format staff can follow quickly

Keep the structure simple and consistent so people know where to look. A practical SOP usually includes:

• Title – the task or process name
• Purpose – what the SOP helps achieve
• Scope – where the procedure applies and where it does not
• Owner – the person responsible for keeping it current
• Version date – when it was last reviewed or updated
• Steps – the actions the user should follow

“Scope” simply means the boundary of the procedure: which tasks, team members, locations or situations it covers. “Owner” means the person responsible for updates, not necessarily the person who wrote it.

Use short numbered steps and active verbs. Write “Check the invoice against the purchase order” rather than “The invoice should be checked against the purchase order”. The first is easier to follow quickly. Keep sentences direct and local to how your business actually works.

If a step needs extra explanation, use a short note or example rather than a long paragraph. Screenshots, photos, templates and filled-in examples are often more useful than more text, especially where staff use software, spreadsheets or repeated forms.

A practical SOP is written for the person doing the job, not for management. If the reader has to work hard to work out what the document means, the process is too complicated or the wording is too formal.

A simple format for a customer refund SOP

Purpose: Make sure refunds are handled consistently and approved correctly.

Steps:

1. Check the customer order number and reason for the refund request.
2. Confirm whether the item meets the refund criteria.
3. Check whether the refund needs manager approval.
4. Process the refund in the payment system.
5. Send the customer confirmation and any next-step instructions.
6. Record the refund in the tracking sheet.

That kind of structure is usually enough for routine work. If you need more detail, add only what removes confusion or prevents error.

Build in quality checks and exceptions

The point of an SOP is not just to describe the usual route. It is also to show what “done properly” looks like. That means defining the check points, sign-offs and deadlines that matter.

For example, if a purchase order needs approval before it goes to a supplier, say who checks it and by when. If a monthly report must be sent by a certain time, state the deadline and the person who confirms it has been sent. If a customer request can be escalated, explain when that happens and to whom.

It is equally important to cover the common exceptions. Staff often get stuck not on the normal case, but on the odd one: a missing document, an urgent request, a system outage, a supplier delay or a customer who wants a faster answer than the usual process allows.

That does not mean you need to write an answer for every possible problem. It means the SOP should show the decision path when the standard route does not work. For instance:

• If the usual system is unavailable, use the manual backup form and log the task for later entry.
• If a document is missing, pause the process and request it before approval.
• If a customer asks for urgent handling, refer to the escalation route and note who authorised the exception.

This is where SOPs become genuinely useful. A process that only covers the ideal case is not much help on a busy day. A process that also explains the exception path saves time, avoids guesswork and reduces the pressure on managers to answer the same questions repeatedly.

Test the SOP with the people who will use it

Once you have a draft, put it in front of someone who did not write it. Ask them to follow it without extra explanation. Watch where they hesitate, guess, reinterpret a step or make a wrong assumption.

That simple test is often more valuable than another round of manager review. The person using the document will show you quickly whether the steps are in the right order, whether any wording is unclear and whether you have missed a practical detail.

Try a small pilot before you roll the SOP out across the whole team. A pilot lets you improve the procedure with less disruption. It also builds trust, because staff can see that the document is based on real work rather than office theory.

When you revise the SOP, fix the issues that came from use, not just the issues someone imagines might happen. If several people get stuck at the same point, the document needs work. If one manager prefers a different style but the process still works, that is a weaker reason to change it.

Assign ownership and keep version control simple

An SOP needs an owner. That is the person responsible for making sure it stays accurate. In a small business, the owner may be a manager, team lead or operations lead. In a larger business, the owner might sit within the department that uses the process most often.

It helps to set a review rhythm based on how quickly the process changes. A procedure tied to software, pricing, supplier terms or compliance may need regular review. A stable internal task may only need checking occasionally. The point is not to update constantly, but not to let the document drift far from reality.

Keep version control basic but clear. Store the current SOP in one obvious place. Remove or archive old copies so they do not live on in email chains, personal folders or old shared-drive locations. If people cannot tell which version is current, they will use the wrong one.

A living document should still be controlled. Staff should know who can edit it, who approves changes and where the official version sits. Casual edits can create confusion very quickly, especially when several people are using the same process in different parts of the business.

Use SOPs to support training and delegation

Well-written SOPs are not just an operations tool. They are also a training tool. They help new starters learn faster because they can see the steps, standards and common pitfalls in one place. They also reduce the burden on experienced staff, who otherwise spend time repeating the same explanations.

This matters because much of what businesses rely on is tacit knowledge: the know-how people carry in their heads after doing a job for a long time. Tacit knowledge is useful, but it is fragile. If it leaves with one person, the business can lose speed and consistency at the same time.

SOPs do not replace judgement. They should not try to. Their job is to handle the routine parts of the work so people can save judgement for the exceptions. That is a sensible division: use the procedure to keep the process steady, then let experienced people deal with the unusual case.

They also support business continuity. If someone leaves, is promoted or is unavailable for a period, a documented process makes it easier for another person to pick up the task without starting from zero.

Common mistakes to avoid

Some SOP projects fail for predictable reasons. The first is length. If a procedure takes too long to read, staff will avoid it. The second is vagueness. If the document says “handle appropriately” or “check as needed”, it does not tell the user enough to act confidently.

Another common mistake is using a generic template without adapting it to the business. Templates can help you start, but they should not dictate the final structure. Your customers, systems, approval routes and team structure are what matter, not the layout of a downloaded form.

It is also easy to write only the ideal case and ignore the awkward bits. That is exactly where people need guidance. If handovers are a regular point of failure, document them. If missing information is common, explain what to do. If a supplier often responds slowly, build that delay into the process rather than pretending it will disappear.

Finally, do not write SOPs and then forget them. A procedure that is out of date can be worse than none at all, because staff may rely on it and make the wrong decision with confidence.

A simple rollout plan for the first month

If you are starting from scratch, keep the first month focused. A small, disciplined rollout is more likely to produce something usable than a large documentation exercise.

1. Week 1: Choose three priority processes that are repeated, risky or owned by one key person.
2. Week 2: Observe the work, map the real steps and draft the SOPs with the people who do the job.
3. Week 3: Test each procedure in real use, edit the weak points and add any templates or screenshots that remove confusion.
4. Week 4: Publish the approved versions, train the team on where to find them and set review dates.

After that, add procedures gradually. Build the library from the processes that matter most, not from the ones that are easiest to write about. You are aiming for a practical set of documents that the team actually uses, not an archive of nice-looking files.

Keep the first version small, then improve it

The best SOPs begin with the work itself. They are written for the person doing the task, in plain English, with enough detail to avoid confusion and enough restraint to stay usable. They cover the trigger, the steps, the owner, the standard and the exceptions that matter most. Then they are tested, corrected and kept current.

If you are not sure where to start, choose the handful of processes that would cause the most disruption if the key person were away. Write those first. Keep the document short enough to use, test it with the people who will follow it, and assign someone to maintain it. If the SOP makes the work easier to do correctly first time, it is doing its job.

Checklist for starting now:

• pick three repeated or risky processes
• observe the real steps before writing
• define the trigger, owner, standard and finish point
• keep the language plain and the structure consistent
• test the SOP with the people who will use it
• remove old versions and assign one owner for updates

If you want SOPs to support wider business control, it can also help to look at how to create a practical business risk register and how to write a practical business plan. Both are easier to keep useful when the underlying processes are clear.

Related articles

What records should a small business keep in the UK?

UK small businesses often keep too little, or far too much. The sensible answer is to keep the records that prove sales, costs, payroll, tax positions, contracts and compliance, then store them in a system you can actually use.

16 October 2026 · 16 min read

How to manage business cash flow during slow months

Slow months can expose weak cash flow even in healthy businesses. The answer is usually not blunt cuts, but better timing: forecast early, collect money faster, protect essential spending and use finance only when you know the size of the gap.

15 October 2026 · 11 min read

How to measure whether a small business is profitable

A business can look busy, generate sales and still fail to make real money. Here is a practical way to judge profitability using profit and loss, gross margin, overheads, cash flow and owner time without being misled by the bank balance.

13 October 2026 · 12 min read

How to choose KPIs for a small business

Too many small businesses track numbers that fill a dashboard but do not change decisions. The better approach is to choose a small set of KPIs that link to your goals, can be reviewed regularly and tell you whether day-to-day actions are working.

13 October 2026 · 14 min read

How to reduce operating costs without cutting staff

If costs are rising but your team is already stretched, the answer is usually not a blunt headcount cut. A better approach is to map spend, remove waste, renegotiate recurring costs, improve processes and use capacity more efficiently while protecting service and morale.

13 October 2026 · 13 min read

How to set business goals for the next 12 months

Broad aims like “grow sales” or “be more efficient” rarely help day to day. The useful job is to turn ambition into a small number of measurable 12-month goals, assign owners, and review progress regularly enough to adjust course before the year drifts.

12 October 2026 · 12 min read