How to Create an SOP: A 10-Step Guide with Examples

A standard operating procedure (SOP) turns important work into something anyone can repeat correctly. This guide shows you how to create an SOP in 10 steps — what to include, which format to choose, how SOPs differ from policies and work instructions, and how to avoid the mistakes that leave procedures unread.

Key takeaways

• A good SOP explains what needs to be done, who does it, and how the task should be performed.
• Define the purpose and audience before you document a single step.
• Map the process first, so you understand dependencies, decisions, and hand-offs before writing.
• Test the SOP with the people who will actually use it, then revise it on their feedback.
• Every SOP needs a named owner and a review cycle, or it drifts out of date.

What is an SOP?

SOP stands for Standard Operating Procedure. A standard operating procedure is a detailed, written set of instructions that outlines the steps involved in completing a specific task or process. The primary goal is to ensure that routine operations are carried out with consistency, quality, and efficiency — regardless of who performs them.

In a business context, SOPs serve as the rulebook for how work gets done. They define the sequence of steps, the roles responsible for each step, and the standards that must be met along the way. That makes them foundational documents in any organisation that cares about quality, compliance, or scalability.

A quick example: a company that onboards new employees might have an SOP covering which systems to set up, which training to complete, and which manager to contact — in what order, and by when.

Without a documented procedure, every onboarding looks different. With one, the experience becomes predictable and repeatable.

SOP vs policy vs process vs work instruction

SOPs sit within a broader set of documents that organisations use to manage how work is done. Four terms are routinely confused, and the difference between them is a difference of altitude.

Policy: Sets rules and intent. Answers “what must we do and why?” Example: all customer data must be encrypted.

Process: Describes the flow of work. Answers “who does what and in what order?” Example: the customer data handling process involves sales, IT, and legal.

SOP: Provides step-by-step instructions for a specific task within a process. Answers “how exactly do we do this?” Example: how to encrypt a file before sending it to a client.

Work instruction: Even more granular than an SOP. Work instructions cover a single activity in microscopic detail, and are typically used on the factory floor or in highly regulated environments. See work instruction examples for how they look in practice.

Why are SOPs important in business?

SOPs do more than document how work gets done. They create the conditions for an organisation to operate reliably at scale.

Consistency. When everyone follows the same procedure, outputs become predictable. Errors drop and quality improves, because success no longer depends on individual memory. This also prevents process drift, where each person gradually develops their own version of the task.

Efficiency. A well-written SOP removes ambiguity. Employees spend less time working out what to do next and more time doing it.

Compliance. In regulated industries — healthcare, finance, manufacturing — procedures must meet external standards. SOPs provide auditable evidence that the organisation follows the required steps.

Training and onboarding. New employees can learn the right way to do things from day one, which reduces the burden on experienced staff. Research shows that work instructions boost new hire onboarding speed by up to 5x — and SOPs play a central role in that.

Risk reduction. When a key person leaves, their knowledge does not leave with them. SOPs capture institutional knowledge and make it accessible to whoever takes over — which matters most in high-turnover roles and specialist functions.

A consistent customer experience. Service teams use SOPs to handle enquiries, complaints, and escalations the same way every time, which protects both the brand and the customer relationship.

When should you create an SOP?

Not every task needs a formal SOP. Creating, reviewing, and maintaining one takes time, so focus on work where standardisation pays for itself.

When scaling. If a team is growing, documented procedures help new employees reach competency faster and reduce dependence on individual knowledge.

When error rates are high. Repeated mistakes are usually a sign that a process is unclear or inconsistently applied. Writing an SOP forces the organisation to define the expected way of working.

When compliance is required. In regulated environments, documented procedures provide the evidence that required steps are being followed consistently.

When knowledge needs to be shared. SOPs capture institutional knowledge so that important ways of working do not disappear when an experienced employee leaves.

When processes are changing. During a digital transformation or a system migration, documenting the current and future ways of working makes the transition far easier to manage.

The organisations that get the most value from SOPs treat them as living documents rather than one-off pieces of documentation.

How to create an SOP in 10 steps

Writing a good SOP takes preparation. The following 10 steps will help you create a procedure that is accurate, practical, and easy to maintain.

1. Define the purpose and goal

Start by asking why the SOP is needed. Are you trying to reduce errors, improve consistency, speed up onboarding, standardise a growing team’s work, or meet a compliance requirement?

A clear purpose helps you decide what belongs in the SOP and what does not. It also gives you something to measure later: if the purpose is to reduce errors, you can use error rates to assess whether the procedure works.

2. Identify the audience and stakeholders

Before writing anything, establish who will use the SOP and who is involved in the work. Who performs the task? Who reviews or approves the result? Who owns the wider process? Who needs to understand the procedure without performing it?

The answers shape the language, level of detail, and format. An experienced specialist may need a concise reference, while someone new to the task needs more context.

3. Map the process and its dependencies

Do not start by writing instructions. First understand the work. Trace the full sequence of activities and identify inputs and outputs, decisions and branching points, hand-offs, dependencies, systems and tools, likely exceptions, and the roles involved.

Process mapping is the right tool at this stage. Mapping shows how the task fits into the wider way of working — and it often reveals problems before you turn them into documented instructions.

4. Choose the right SOP format

No single format works for every SOP. Choose based on the complexity of the task and how the reader will use the document: a step-by-step list for linear tasks, a checklist for routine work, a flowchart for branching processes, or a hierarchical document for complex procedures. The section on SOP formats and templates below covers each option in detail.

5. Define roles and responsibilities

Make ownership explicit. For every important step, clarify who performs the work and who needs to review, approve, or be informed. This prevents the most common problem in operational work: everyone assuming that someone else is responsible.

It also makes the SOP easier to maintain, because someone — usually the process owner — carries overall responsibility for keeping it accurate as the underlying process changes.

6. Write the instructions clearly

Now document the actual procedure. Write each step in plain language, using active voice and present tense, and start with a clear action: “Open the system.” “Enter the reference number.” “Confirm with the line manager.”

Each instruction should contain enough information for the reader to complete the task without asking someone what to do next. At the same time, avoid documenting every conceivable detail — an SOP that is unnecessarily complicated is as hard to use as one that is too vague.

7. Document tools, resources, and risks

A person should know what they need before starting: software and system access, physical materials, reference documents, templates, safety equipment, approvals, and escalation paths.

Then consider what could go wrong. Document error-handling procedures, safety precautions, decision points, and escalation routes. This matters most in regulated or high-risk environments.

8. Test the SOP with real users

Do not publish the SOP as soon as you finish writing it. Ask someone from the intended audience to follow the procedure without additional explanation, and watch where they hesitate, make mistakes, or need information that is not there.

This is where the biggest improvements emerge. The person who knows a process best is rarely the person who will follow the SOP, and testing closes that gap.

9. Get approval, implement, and train

Once the SOP has been tested and refined, get formal approval from the relevant authority — a process owner, department head, or quality manager. Then make it available to everyone who needs it.

An SOP that is technically correct but hard to find will not have much impact. Make it accessible where the work happens rather than burying it in a shared drive, and include it in onboarding. Training is worth the time whenever the procedure introduces a new way of working or carries compliance or safety weight.

10. Review and update the SOP

An SOP is not finished when it is published. Processes, systems, regulations, and responsibilities all change. Set a review cycle and define who keeps the procedure current — at a minimum, review it annually and whenever the underlying process changes significantly.

A version history helps users see which procedure is current. If the documented procedure and the actual process drift apart, the SOP loses its value fast. Our Academy lesson on defining the process owner role covers who should carry that responsibility.

What are the 5 key components of an SOP?

The exact structure varies, but most useful SOPs contain five core elements.

1. Title and purpose. Identify the task or process the SOP covers and explain why the procedure exists.
2. Roles and responsibilities. Define who performs each step and who oversees the work.
3. Step-by-step instructions. Document the actions required to complete the task in a clear, logical order.
4. Tools, materials, and resources. List what the user needs before starting — software access, physical materials, reference documents, or safety equipment.
5. Review and governance. Record who approved the SOP, when it was last reviewed, and when it is due for review again.

Together, these elements make the SOP clear, actionable, and easier to maintain.

SOP formats and templates

The right format depends on the task and the audience. Here are the four most common options.

Step-by-step list. The most common format. Each action is numbered in sequence. Best for linear tasks where the order of steps matters and there are few decision points. Easy to follow and easy to audit.

Checklist. A simplified version of the step-by-step list, focused on confirming that each item has been completed. Particularly useful for routine inspections, pre-flight checks, or end-of-day routines. Checklists reduce cognitive load — the reader is not thinking about what to do next, only whether this item is done.

Flowchart or BPMN diagram. Best for processes that involve decisions and multiple paths. A BPMN diagram makes branching logic easy to follow visually, which also makes it useful for training — the reader gets a mental model of the whole process before starting.

Hierarchical SOP. A longer, structured document covering a complex process with multiple sub-processes. Each section works as its own mini-SOP. Useful in highly regulated environments where comprehensive documentation is required by law.

Wherever you find SOP templates — from standards bodies, industry associations, or software vendors — you will always need to adapt them. A generic SOP template is a starting point, not a finished product. The value comes from making it specific to your organisation’s context, language, and workflows.

SOP examples by industry

SOPs look different depending on the context. Here are short examples from five common sectors.

Manufacturing. A production-line SOP specifies how to set up a machine, which quality checks to run at each stage, and what to do if a defect is detected. Every step is numbered and includes the relevant safety precautions.

Finance. A month-end close SOP lists every reconciliation task, who owns it, and the deadline for each. It gives the finance team a consistent way to close the books while reducing errors and audit risk.

Healthcare. Clinical SOPs cover activities such as medication administration and patient handover. They must be kept current and aligned with clinical guidelines, because deviations can carry serious consequences.

Government and regulatory bodies. Public sector organisations use SOPs to deliver decisions and services consistently, fairly, and in line with legislation. Transparency and auditability are central concerns.

IT and cybersecurity. An incident response SOP defines what happens when a security event is detected: who to notify, what to isolate, what to log, and when to escalate. When time matters, clear procedures keep the response consistent.

When SOPs fail: three real examples

Examples are just as instructive when they go wrong. These three cases show what happens when a procedure is unclear, ambiguous about responsibility, or simply not there when it is needed.

1. A maintenance SOP that never said “shut the machine down”

The Wall Street Journal reported on a 65-year-old worker at a Wisconsin furniture factory who was crushed to death in 2020 because the conveyor system had not been completely shut down during maintenance.

This was a failure of clarity and specificity. The procedure did not explicitly instruct the worker to shut the conveyor down before servicing it. A short safety checklist, completed before opening any machinery, would have made the missing step impossible to skip.

2. Emergency protocols nobody could act on

A study of tabletop exercises with regional first responders in Norway found that ambiguous SOPs actively hindered cross-organisational emergency response. Unclear procedures made information sharing and decision-making harder at exactly the moment both mattered most.

This was a failure to define responsibility. A swimlane diagram solves it directly, because it shows which department or role owns each step rather than leaving it to be inferred under pressure.

3. The UK Post Office Horizon scandal

Hundreds of UK postmasters were accused of fraud or theft over accounting discrepancies produced by the faulty Horizon IT system. Investigations found that the Post Office had not adequately followed procedures to verify the system’s reliability, and the result was wrongful convictions with severe personal and financial consequences.

This was a failure of availability. Procedures for testing a system in live use either did not exist or could not be found inside an organisation of that size — which amounts to the same thing.

The three failures point at the same three qualities. Clarity: plain, unambiguous language, with visuals where they help and every technical term defined. Specificity: precise steps with measurable outcomes (“turn off the machine by pulling the power plug”), explicit roles, and named exceptions. Accessibility: the procedure is readable in the actual work situation, on whatever device is to hand. An SOP that fails any one of the three will eventually fail the person relying on it.

How to make an SOP people actually use

Creating an SOP is only half the job. The procedure also has to work for the people who rely on it.

Keep the language simple. Use short steps and clear headings. Remove information that does not help the reader complete the task, and make the SOP easy to find where the work happens.

Most importantly, involve the people who perform the work. A procedure written entirely by someone who manages the process will miss practical details that are obvious to the people carrying it out every day. Good SOPs are built with users, tested with users, and improved based on how users actually work.

Common SOP mistakes to avoid

Even well-intentioned SOP programmes run into the same five problems.

Making it too complex. An SOP that nobody can follow is worse than no SOP at all. Keep language plain, steps short, and formatting clean. If the document runs to twenty pages, consider splitting it into several narrower SOPs.

Failing to update it. Processes change, systems change, regulations change. An SOP that was accurate eighteen months ago may now be dangerously wrong. Build a review cycle into the governance model from the start.

No clear ownership. SOPs without an owner drift. Someone has to be responsible for keeping each document current and accurate — typically the process owner, the person accountable for how the process performs.

Hard to find in the moment of need. If the SOP lives three levels deep in a shared drive, people will not look for it when they need it. Documentation should be accessible in the flow of work — ideally in the same tool people use to do the task.

Not tested with users. Writing an SOP in isolation and publishing it without user testing is a common failure mode. Watch the actual audience follow the procedure, and use what you learn to improve it.

How SOPs support process excellence

SOPs do not exist in isolation. They are one component of a larger business process management system, and they become significantly more powerful when connected to that broader framework.

In a mature process organisation, SOPs sit within a process architecture that maps how processes relate to each other and to the organisation’s strategic goals. Each SOP covers a specific process or sub-process within that architecture. When processes change — because of a new system, a new regulation, or a continuous improvement initiative — the affected SOPs are updated in step.

SOPs are also a critical enabler of digital transformation. Before automating a process or migrating it to a new system, the organisation needs to understand exactly how it currently works. SOPs provide that understanding, and they serve afterwards as the formal record of how the new process should operate.

In essence, a well-maintained SOP library is both a starting point and an output of process excellence work. It captures what works, makes it available to everyone, and provides the baseline for ongoing improvement.

FAQ – standard operating procedures