SOP vs Playbook: What Each Is and When to Use It

Structured steps beside branching decision paths

An SOP (standard operating procedure) tells someone how to complete one task, step by step. A playbook tells a team which tasks and decisions come into play in a given situation, who owns them, and what good looks like. Most businesses need both, and the playbook is built on top of the SOPs, not instead of them.

This guide sets out the difference in plain terms, gives examples of each, and shows how to write an SOP and assemble a playbook without creating a document nobody opens.

Strategic-concierge

Build capability that lasts

Strategic Concierge helps businesses build, improve and embed the capability they need for clearer direction, stronger execution and sustainable growth.

Explore Strategic Concierge

TL;DR

An SOP covers one repeatable task in numbered steps. A playbook groups SOPs, policies, decision rules and owners around a whole function or scenario.
Write SOPs first for tasks where errors hurt customers, safety or compliance, or where only one person knows how the work is done.
Build a playbook around your most important client flow, then link each stage to the SOPs beneath it.
Both documents go stale. Give each an owner and a review rhythm, or staff will stop trusting them.
Pick the format to suit the reader and the cost of getting it wrong, not the other way round.

SOP vs playbook at a glance
What an SOP is, and what goes in one
What a playbook is, and what goes in one
When to use an SOP, a playbook, or both
How to write an SOP
How to build a playbook from your SOPs
Keeping documentation current
Our perspective
Build your playbook with us
FAQ
Sources

SOP vs playbook at a glance

The quickest way to separate the two is by the question each answers. An SOP answers “how do I do this?” A playbook answers “what do we do now, and who does it?”

One company guide puts it this way: an SOP gives step-by-step instructions for one task, while a playbook is a collection of SOPs organised around how a business runs, showing which SOPs and policies sit under each stage. Another describes SOPs as rigid, step-by-step instructions for routine tasks, with playbooks offering higher-level guidance for decisions in variable situations.

	SOP	Playbook
Scope	One task	A function, client journey or scenario
Answers	How do I do this?	What do we do, in what order, and who owns it?
Style	Numbered steps, little discretion	Guidance, decision rules, scripts, roles
Changes when	The tool, rule or method changes	The strategy, market or client journey changes
Typical reader	The person doing the task	The team lead, new starter or whole team
Example	Processing a customer order	Handling a new enterprise enquiry from first call to signed contract

The two sit alongside other documents that people often confuse with them. A policy sets the rules and boundaries. A runbook guides reactive work: SOPs document routine operations, while runbooks guide incident response and troubleshooting. A procedure is a wider blueprint for a multi-step process involving several roles, and an SOP provides granular instructions for one or more steps within it.

What an SOP is, and what goes in one

A standard operating procedure is a written, agreed way of carrying out a routine task so that the result does not depend on who does it. The UK Health and Safety Executive describes procedures as agreed safe ways of doing things, usually made up of instructions and related information that may include steps, checklists, decision aids, diagrams or flow-charts.

A useful SOP usually contains:

A title and purpose. One sentence on what the task achieves.
Scope. Where the procedure starts and stops, so it does not sprawl.
Roles. Who performs each step and who approves the result.
Numbered steps. One action per step, with a clear actor and action.
Decision points. What to do if a check fails or information is missing.
Tools and inputs. Systems, templates and access needed.
Owner and review date. Someone accountable for keeping it current.

If your reader works in a regulated setting, the content may be set by the regulator. For example, the Home Office expects controlled drug licensees to have SOPs covering end-to-end management at each site, taking account of regulatory requirements and security practices. Most small businesses will not face anything so prescriptive, but the principle holds: the stricter the consequences, the tighter the SOP.

Types of SOP, and other names for it

When people ask about the types of SOP, they usually mean format. Three are common: step-by-step, hierarchical and flowchart SOPs. Use a step-by-step list for short, linear tasks. Use a hierarchical layout when a step has sub-steps or when detail varies by experience. Use a flowchart when the right action depends on a series of yes or no decisions.

There is no single new name for an SOP. You will see “work instruction”, “procedure”, “process document” and, in safety settings, “safe operating procedure”. The terms overlap and teams use them loosely, so agree on your own definitions and apply them consistently.

SOP vs work instruction

A work instruction is usually the narrowest layer: the exact keystrokes or physical actions for one step, often with screenshots or photos. An SOP wraps several such steps into a complete task with roles, checks and an outcome. If you find your SOP filling with tool-specific clicks, split those out into work instructions and keep the SOP readable.

What a playbook is, and what goes in one

A playbook explains how a function or scenario works as a whole. One guide describes it as containing a company’s processes, policies and SOPs, explaining how work gets done, who does it and what to do in specific scenarios. Where an SOP focuses on a single task, a playbook often brings together several SOPs with decision frameworks, scripts and role responsibilities.

A business playbook typically needs:

A critical client flow. The path from first contact to delivered outcome that matters most to revenue.
The systems under each stage. Which tools and SOPs apply where.
Clear ownership. A named role for every stage.
Company foundations. Values, standards and policies people need to make judgement calls.
A review rhythm. When and how it gets updated.

Those five elements come from a guide to building a business playbook, and they are a sound checklist whichever sector you work in.

Examples of a playbook

The commonest examples are commercial. A sales playbook might describe how to approach different types of customers, while an SOP gives the detailed steps for a task such as processing customer orders. Others include:

Onboarding playbook. The sequence of welcome, set-up, training and check-ins for a new client or employee, linking to SOPs for account creation, contract signature and first-week reviews.
Customer success playbook. Triggers for a health-score drop, who contacts the client, what is offered. We cover this in detail in our customer success playbook guide.
Lead response playbook. What happens in the first hour after an enquiry: who replies, how it is qualified, when it is escalated. Many service businesses now support this with automated lead follow-up, but the playbook still needs to say who owns the handoff and what happens next.
Incident response playbook. Common in IT and security teams, where it lays out roles and decisions while runbooks hold the technical steps.

When to use an SOP, a playbook, or both

Use the situation, not the label, to choose.

Write an SOP when the task repeats, the correct method is known, and variation causes errors. Priority goes to tasks where mistakes harm customers, safety or compliance, or where knowledge is held by only one person. Invoicing, onboarding a new supplier, running a monthly report and publishing a proposal are typical.

Write a playbook when people must choose between actions depending on context, several roles must coordinate, or a new starter needs the whole picture. Examples are a renewal conversation, a pricing negotiation, or the way a founder-led firm hands a client from business development to delivery.

Use both when a process is critical and also contains variable decisions. The playbook says which SOP to run at each stage, and the SOP gives the detail. A short way to remember it: an SOP tells you how to do the task, and a playbook tells you which task to run when the situation arrives.

Decision guide for choosing SOPs and playbooks

What goes wrong when the two blur

When the boundaries between policy, SOP, playbook and runbook are lost, documentation becomes hard to use: SOPs fill up with tool steps, playbooks with governance text, and runbooks with unclear explanations. The reader then cannot find the answer in the moment they need it. Keep each document to one job and link between them.

There is also a limit to what any procedure can do. The HSE notes that procedures may not be appropriate as the sole defence against major hazards and should be supported by training and competence arrangements informed by risk assessment. In a business context, that means documentation works best alongside coaching, not as a substitute for it.

How to write an SOP

This sequence follows the approach set out in a UK small-business guide to documenting processes.

Choose a process that deserves documentation. Start where errors are costly or knowledge sits with one person.
Define its boundary. Name the trigger that starts it and the result that ends it.
Observe the real work. Watch someone do it, rather than asking for a description. People often skip steps they no longer notice.
Map steps and decisions. Show decision points explicitly.
Write it. Use numbered steps with a clear actor and action in each.
Test it. Ask someone unfamiliar with the task to follow it, and compare the documented steps with real work to find gaps.
Approve and publish. Put it where people actually look, with one current version.
Review it after incidents or changes.

The HSE advises using a format and level of detail appropriate to the user, the task and the consequences of failure, informed by risk assessment and by involving the people who do the work. A one-page checklist may be right for a routine task. A fully detailed SOP is justified when a slip is expensive.

If your team finds writing slow, one approach is to capture the work first. Some teams record a walkthrough and convert it into structured SOP documentation, then edit for clarity.

A short SOP example

SOP: Issuing a client proposal

Account manager confirms the scope in the discovery notes and flags anything unclear.
Account manager copies the current proposal template and completes the scope, timeline and fee sections.
Finance lead checks the fee against the approved price list. If it differs, go to step 4. If not, go to step 5.
Finance lead records the reason for the difference and the director approves it in writing.
Account manager sends the proposal as a PDF and logs the date in the CRM.
Account manager sets a follow-up task for three working days later.

It is short, each step has one actor and one action, and it contains one decision point. A proposal playbook would sit above it, covering how to judge which client type needs a workshop first, how to handle a pricing objection and when to escalate to a director.

How to build a playbook from your SOPs

Pick one critical client flow. Choose the journey that most affects revenue or retention, such as lead to signed client. Our guide to sales process design for B2B shows how to break one into stages.
List the stages. Five to eight is usually enough.
Attach the SOPs. Under each stage, list the SOPs, templates and policies that apply. Where an SOP does not exist yet, note the gap and rank it.
Add decision rules and scripts. This is the part SOPs cannot hold: how to qualify, when to say no, what to say in a difficult conversation.
Assign owners. One named role per stage. Our accountability framework guide sets out how to make this stick.
Set a review rhythm. A playbook that is never reviewed can become a theoretical document that staff do not trust or use.

If your processes are spread across people and tools, it can help to place the playbook within a wider system. We describe how in building a business operating system in stages, and how to find the capabilities that matter first in our capability mapping guide.

Keeping documentation current

An out-of-date SOP is worse than none, because people follow it. Set a review trigger for each document: a fixed interval for stable processes, plus a review after any incident, tool change or policy change.

The same discipline applies to access and permissions inside the tools your SOPs depend on. If a procedure says who may approve or view something, that should match reality, and a regular check such as SaaS access reviews keeps the two aligned. Put these checks in the calendar, with a named owner, rather than relying on memory.

A practical test: pick one SOP at random every quarter and ask the person who uses it to walk you through it. Every difference between their description and the page is a correction to make.

Our perspective

Most of the businesses we meet do not have a documentation problem. They have a capability problem that shows up as documentation: the work depends on two or three people, the founder is the escalation route for every decision, and nobody can say with confidence what “done” looks like.

That is why we do not start with a binder of SOPs. We start with direction, then a launch-ready foundation, which we aim to put in place within a month. Then we iterate, optimise and embed, so that the people doing the work own the documents and keep them current. A playbook that belongs to a consultant stops being used when the consultant leaves. One that belongs to your team becomes how the business runs.

Our advice is to write the few SOPs that protect your customers and your revenue, wrap them in one playbook for your critical client flow, and put an owner and a review date on both. Then build from there, in stages, at a pace your team can absorb.

Chris

Build your playbook with us

If you would rather not build this alone, our staged approach moves through Build, Iterate, Optimise, Embed and Grow. It starts with a Foundation stage and develops toward ongoing managed capability. Our Managed Capability plan is published at £999 per month, £2,850 per quarter or £10,000 per year, and you can see how each option works on our pricing page.

Strategic-concierge

To talk through which processes to document first, book a discovery call or read how it works.

FAQ

What is the difference between an SOP and a playbook?

An SOP gives step-by-step instructions for one routine task. A playbook groups several SOPs with policies, decision rules, scripts and owners to guide a whole function or scenario. The SOP is the detail, and the playbook is the map that shows when to use it.

Is a playbook the same as a runbook?

Not quite. Runbooks guide reactive work such as incident response and troubleshooting, while SOPs cover routine operations. A playbook is broader than both, and can point to the runbooks and SOPs it needs.

What are the three types of SOP?

The three formats most often cited are step-by-step, hierarchical and flowchart. Choose by the task: lists for linear work, hierarchies for layered detail, flowcharts for decision-heavy work.

Which should a small business write first?

Start with SOPs for tasks where mistakes harm customers, safety or compliance, or where only one person knows the method. Once you have those for your main client flow, write the playbook that connects them.

How often should I update them?

Review after any incident or change to a tool, rule or process, and on a fixed rhythm otherwise. Give each document a named owner so that the review actually happens.