SOPs vs Playbooks vs Runbooks: What the Actual Difference Is (And Which One You Should Write)

Here is the one line difference. An SOP tells you how to do a repeatable task the same way every time. A playbook tells you how to think and decide when the situation varies. A runbook tells you exactly what to do when something specific happens, usually under pressure.

Three genuinely different jobs. Most businesses do not distinguish between them. They write one enormous document, call it an SOP, put it in a folder, and cannot understand why nobody opens it after week two.

The reason is simple. The document type did not match the work. Writing an SOP for a judgement-heavy sales conversation produces a script nobody follows. Writing a playbook for invoice processing produces waffle when what the person needed was step four. Writing neither for a system outage or a lost client means the response depends on who happens to be online.

This piece sets out what each document type is, when each is right, how to structure them, who owns them, how long each takes to write, and how the three fit together. If you are still deciding whether to document anything at all, start with why your business needs SOPs, then come back here to pick the format.

SOPs vs Playbooks vs Runbooks at a Glance

Read that table by the third row. Steps, plays, response. If the work is genuinely the same every time, you want steps. If the work changes depending on the client, the deal, the person or the market, you want plays. If the work only starts when something breaks, you want a response.

What an SOP Is and When It Is the Right Document

A standard operating procedure is a set of ordered steps that produces the same output every time, regardless of who performs it.

The defining feature is low variation. If two competent people can follow the document and land in the same place, it is an SOP. If they legitimately land somewhere different, it was never an SOP and forcing it into that shape will make it worse.

SOPs work best on tasks that are frequent, consequential when done wrong, and currently trapped in somebody's head. Raising an invoice. Onboarding a new starter to your systems. Closing month end. Processing a refund. Running payroll. None of these need creative thinking. They need to be done the same way at 9am on a Monday and at 4pm on a Friday by a person who joined three weeks ago.

Good SOPs are short. One to three pages. If yours is running past five, you have either bundled several procedures together or padded it with context that belongs in a playbook. Split it.

The point of an SOP is not compliance theatre. It is transfer. An SOP is how a task leaves the founder's head and becomes something the business owns rather than something a person owns. That is exactly the problem described in when your business runs on the founder's memory, and it is why documentation is usually the first structural fix we make. If you want the mechanics of writing them, how to create SOPs for a growing team covers the process and our SOP template for small businesses gives you the format to fill in.

What a Playbook Is and When It Is the Right Document

A playbook explains how your organisation approaches a category of situation. It gives principles, options, criteria and worked plays rather than a single fixed sequence.

The defining feature is variation with pattern. Every enterprise sales cycle is different, but they rhyme. Every difficult client conversation is different, but the good ones share a structure. Every hiring round differs by role, but your standards should not. Where the situation varies and the judgement is what matters, a playbook is the correct format.

A sales playbook contains your ideal customer profile, qualification criteria, objection responses, pricing guardrails, discount authority, and what to do when a deal stalls. It does not say "on day three, send email two". It says what a healthy deal looks like at each stage, and what to do when it does not look like that.

Playbooks are longer than SOPs. Eight to fifteen pages is normal for a well-built one, because they need to carry context, examples and reasoning. Context is not padding here. It is the product. A person following an SOP does not need to know why. A person using a playbook needs to know why, because they are the one making the call.

Playbooks are the natural documentation format for management. When you build a layer of team leads between yourself and delivery, what you are really transferring is judgement, not tasks. That is the harder handover, and it is the one covered in how to build a management layer when scaling.

What a Runbook Is and When It Is the Right Document

A runbook is the response to a specific trigger event. Something happens, you open the runbook, you work the list.

The term comes from IT operations, where a runbook covers what to do when a server falls over or a deployment fails. Businesses outside technology use them far less than they should, because the concept applies to any event that is rare, high stakes and time sensitive.

Your business almost certainly needs runbooks for a few of these: a key client gives notice, your main system goes down during working hours, a data breach is suspected, a critical supplier fails, a senior person resigns without warning, a complaint escalates publicly.

Runbooks are short and unambiguous. One to two pages. They open with the trigger condition, name the owner, then move straight into numbered actions with verification points. No background. No philosophy. The reader is stressed and scanning, not studying.

The single most important field in a runbook is the first one: who owns this right now. Most incident responses fail not because nobody knew the steps but because everyone assumed someone else had started. Clear ownership is the difference between a fifteen minute recovery and a three hour one, which is the same accountability problem that a RACI matrix for small businesses solves at the process level.

Where Checklists and Policies Fit Alongside Them

Two other document types keep getting conflated with these three, and both are useful once you place them properly.

A checklist is a verification tool, not an instruction. It confirms that things happened. Quality assurance sign-offs, month-end close confirmations, new starter equipment lists. A checklist assumes competence and guards against omission. The pattern that works is an SOP for the person learning the task and a checklist for the same person once they are fluent.

A policy states a rule and its boundaries. It says what is and is not permitted, who can approve exceptions, and what happens if the rule is broken. Expenses. Remote working. Discount authority. Data retention. A policy never contains steps. The moment it does, you have written a procedure and buried it inside a rule where nobody will find it.

The clean separation is this: policy sets the boundary, SOP delivers the task, checklist verifies it happened, playbook guides the judgement, runbook handles the exception. Five artefacts, five jobs. Businesses that mix them end up with twelve-page documents that are simultaneously too vague to follow and too long to read. If your existing documentation feels like that, how to document business processes walks through untangling it.

The Decision Rule for Choosing Which to Write

Before writing anything, answer three questions in order. The answers determine the format.

One: does this work start on a schedule, or on an event? Scheduled and routine points to an SOP. Event-triggered and urgent points to a runbook. Situational and ongoing points to a playbook.

Two: if two capable people did this independently, would the output be the same? If yes, SOP. If no, and that difference is legitimate rather than sloppy, playbook.

Three: is speed under pressure the main constraint? If yes, runbook, no matter what the answer to question one was.

That last row matters more than it looks. Automating an undocumented process just makes the mess run faster. Write the SOP, run it manually for a fortnight, fix what breaks, then automate. The sequencing is covered properly in how to automate business workflows without breaking what works.

The Same Business Area Documented Three Ways: Customer Onboarding

Customer onboarding is the clearest example because it genuinely needs all three, and most businesses only write one.

The SOP: setting up a new client account. Ten to fifteen steps. Create the record in the CRM. Generate the contract from the template. Send it for signature. On signature, create the project workspace. Add the client to billing. Set up the shared folder. Send welcome email template A. Book the kickoff call. Add to the reporting dashboard. This is identical for every client. There is no judgement in it. A new coordinator should be able to do it correctly on day three, which is precisely what onboarding new employees faster using SOPs is built on.

The playbook: running the first ninety days of a client relationship. This is where variation lives. What a good kickoff looks like and how it differs for a technical buyer versus a commercial one. How to identify the real decision maker when it is not the person who signed. What early warning signs of a bad fit look like at week three. How to handle scope expansion. When to escalate to the founder. None of this can be stepped. All of it can be taught, and a playbook is how you teach it once instead of eleven times.

The runbook: a new client is at risk in the first sixty days. Trigger: the client has missed two consecutive scheduled calls, raised a formal complaint, or gone silent for ten working days. Owner: the account lead, escalating to the founder within twenty-four hours. Actions: pull the delivery history, check every commitment made in the sales process against what was delivered, phone the client rather than email, document what you hear, decide within forty-eight hours whether to remediate or exit, notify finance if the commercial position changes.

Three documents. One business area. Roughly two pages, twelve pages and one page. Write only the SOP and your team executes admin flawlessly while relationships quietly fail. Write only the playbook and account setup is different every time. This is the shape we implement under our process design engagements.

How Each Document Type Should Be Structured

Structure is not decoration. Layout determines whether the document is usable at the moment someone needs it.

Three specific rules make the difference in practice.

For SOPs, one action per numbered step. If a step contains the word "and", split it. Screenshots for anything involving a screen, because a screenshot removes ambiguity faster than three sentences.

For playbooks, lead each play with the situation, not the response. People search by symptom. "The deal has gone quiet after a strong demo" is findable. "Re-engagement approach" is not.

For runbooks, put a verification after every action. Not "restart the service" but "restart the service, then confirm the status page shows green before continuing". Under pressure, people execute steps without checking whether they worked.

Who Owns Each One, and How Long Each Takes to Write

Ownership is where documentation systems die. A document without a named owner is stale within one quarter and actively misleading within two.

SOPs are owned by the person who does the work most often, not by the founder and not by a central operations team. That person reviews every six months and updates immediately when the process changes. Central ownership feels tidier and fails every time, because the centre never notices that the CRM field changed.

Playbooks are owned by the function head. Review quarterly, ideally in the same session where you review the function's numbers, because the numbers tell you which plays are not working.

Runbooks are owned by whoever holds the duty rota for that domain. The review trigger is usage, not calendar. Every time a runbook is used, the person who used it updates it within twenty-four hours while the friction is still fresh. A runbook that was wrong in the moment is the most expensive kind of stale document.

On time: budget 30 to 45 minutes per SOP if you write it while doing the task, screen recording as you go. A playbook is a different order of effort, one to three days of drafting plus a workshop with the people who actually make the calls. A runbook takes 45 to 90 minutes, most of which is arguing productively about who owns the response.

For a 20-person business, a realistic first pass is 25 to 40 SOPs, three to five playbooks and six to ten runbooks. That is roughly 6 to 8 weeks of part-time effort internally, or a focused engagement if you want it done without pulling your operators off delivery. Externally, expect £3,000 to £9,000 depending on scope and how much of the writing you keep in house. Broader engagement pricing is set out in business operations consultant cost.

Where Each Document Should Live in Your Tool Stack

The right tool is the one your team already has open. Documentation that lives somewhere people do not go is functionally deleted.

SOPs belong in your knowledge base, linked directly from the task that needs them. If your team runs on ClickUp or Asana, the SOP link goes in the task template, not in a folder someone has to remember exists. That link is the whole game. A team of twenty will not navigate three levels of wiki to find step four.

Playbooks belong in the same knowledge base but in a browsable, well-indexed section, because they are read in preparation rather than in execution. Notion suits playbooks particularly well thanks to its database and tagging structure, and using Notion as a business operating system shows how to lay that out. If you are still choosing a home, Notion vs ClickUp vs Asana compares the realistic options.

Runbooks need to be reachable when your systems are not. If your runbook for "our main platform is down" lives inside that platform, you have a problem. Keep a mirrored copy somewhere independent, even a shared drive or a pinned message in your chat tool. Test that the on-call person can reach it from their phone.

One rule above all: one home, not four. The most common documentation failure we find is not absence, it is duplication. Three versions of the same SOP in Drive, Notion and someone's Slack DMs, and no way to tell which is current. Before adding documents, run an audit of your business tool stack and decide where the single source of truth lives.

How the Three Work Together as a Documentation Layer

Individually these documents are useful. Together they form the operating layer that lets a business run without the founder in every conversation.

Think of it in three tiers. The playbook layer sets direction and judgement. The SOP layer executes the routine. The runbook layer handles the exceptions. A healthy business has all three, linked to each other.

Linking is what most businesses miss. Your customer onboarding SOP should link to the ninety-day playbook, so a coordinator can see where their task sits in the bigger relationship. Your playbook should link out to every SOP it depends on. Documentation without cross-links becomes a pile. With cross-links, it becomes a map.

The test of whether the layer is working is not how many documents exist. It is what happens when someone goes on holiday. If a two-week absence generates seven messages to the founder, the layer is incomplete and the gaps are visible in exactly which questions got asked. That diagnostic is the same one behind signs the founder is the bottleneck and the structural fix described in how to remove yourself from day-to-day operations.

Done well, this layer is what lets you grow headcount without growing chaos, and it is the precondition for the structural work in how to structure a growing team.

The Failure Modes of Each Document Type

Each format fails in its own characteristic way. Recognise the symptom and you can diagnose which document was written wrong.

SOPs fail by drifting. The process changes, the document does not, and within four months the SOP is describing a system that no longer exists. New starters follow it, get the wrong result, and quietly stop trusting documentation altogether. The fix is a review date on every SOP and an owner who does the task themselves.

SOPs also fail by over-specification. A twelve-page SOP for a task that takes eleven minutes is a document nobody will read. It usually means the writer was documenting for an imagined auditor rather than a real colleague.

Playbooks fail by becoming essays. Forty pages of strategy called a playbook is never opened, because there is no way to find the bit you need. A playbook is a reference document, not a manifesto. Index it by situation and make every play skimmable in ninety seconds.

Playbooks also fail when they are written by someone who does not do the work. A sales playbook written by a consultant who has never sold your product describes a generic process. The plays have to come out of your best people, which is why we run playbook workshops rather than writing them in isolation.

Runbooks fail by never being tested. A runbook written in a calm moment and never rehearsed will contain at least two broken assumptions: a permission the on-call person does not have, or a contact who left the business. Run a dry test twice a year. It takes twenty minutes and it is the highest return activity in this entire article.

And the systemic failure: writing all three at once for the whole business. That produces a three-month documentation project, a beautiful wiki and no behaviour change.

Rolling Out a Documentation System Without Stalling the Business

The rollout is where most attempts collapse. Not because documenting is hard, but because businesses try to do it comprehensively instead of sequentially.

Weeks one and two: find the pain, not the gaps. Do not audit everything. List the ten things that most often go wrong, get escalated to you, or stop when a specific person is away. That list is your backlog and it is already prioritised by cost. Auditing your business operations in one weekend gives you a fast way to build it.

Weeks three and four: write the top ten SOPs only. Written by the people who do the work, in 30 to 45 minute slots, screen recorded rather than typed from memory. Ten SOPs at 45 minutes is seven and a half hours of total effort across the team. That is genuinely achievable inside a normal working fortnight.

Weeks five and six: write two playbooks and three runbooks. Pick the two functions with the most judgement in them, usually sales and delivery. Pick the three events that would hurt most: your biggest client leaving, your core system failing, a key person resigning.

Weeks seven and eight: wire it in and stop writing. Link every SOP from the task that triggers it. Put the runbooks somewhere reachable offline. Assign owners and review dates. Then stop. Do not write document eleven until documents one to ten have been used by someone other than their author.

Two rules make this stick. Nothing enters the system without a named owner and a review date. And every new starter's first week includes following three SOPs and reporting what was wrong with them, which turns onboarding into free quality assurance.

Rolled out this way, 6 to 8 weeks gets a 20-person business to a documentation layer that holds. Rolled out as a big-bang project, the same effort produces a wiki that is out of date before it is finished. If you would rather not run it internally, this is the work we do under our SOP service, and it is usually the first phase of a fractional COO engagement. See how we work before committing to anything.

Frequently Asked Questions

Is a playbook just a long SOP? No. The difference is not length, it is whether the work requires judgement. An SOP removes decisions so the output is identical every time. A playbook supports decisions so the person makes a better call in a situation the document cannot fully predict.

Can one document be both an SOP and a playbook? It can, but it usually should not. Mixed documents are too long for the person executing and too prescriptive for the person deciding. If you find yourself writing "it depends" inside an SOP, that paragraph belongs in a playbook and the SOP should link to it.

How many SOPs does a small business actually need? For a 20-person business, 25 to 40 covers the tasks that genuinely matter. Anything beyond that tends to document work that happens rarely enough that a knowledgeable person can just be asked. Prioritise by frequency multiplied by cost of getting it wrong, as set out in how to improve business processes in an SME.

Do runbooks only apply to technology businesses? No. The concept came from IT but the format suits any triggered, time-critical event. A professional services firm needs runbooks for client escalations and key person departures far more than it needs one for a server restart.

Who should write our SOPs, the founder or the team? The team, with the founder reviewing. Founders write SOPs from memory and skip the steps they do unconsciously. The person who does the task weekly writes a more accurate document in less time, and writing it builds their ownership of the process.

How often should each document be reviewed? SOPs every six months or immediately on process change. Playbooks quarterly, ideally alongside the function's performance review. Runbooks after every single use, within twenty-four hours, by whoever used them.

What if our processes change too fast to document? That is usually a sign the process is unstable rather than the documentation being pointless. Document the current version anyway, lightly, and treat it as version one. A stable process is easier to see once it is written down, and an unstable one is easier to fix.

Should we automate instead of documenting? Document first, then automate the documented version. Automating an unclear process encodes the confusion and makes it faster and harder to unpick. The right sequence is written, stabilised, then automated.

How do we get people to actually use the documents? Link them from the point of work rather than storing them in a library, make the owner someone on the team rather than a central function, and build a habit of updating during use. Documentation gets used when finding it is faster than asking a colleague.

Can we outsource writing all of this? Partly. SOPs and runbooks can be drafted externally from observation and interviews. Playbooks should not be, because the judgement in them belongs to your best people and has to be extracted from them rather than imported. We tend to run the system and the workshops, and have your team supply the content.

How much should this cost if we bring in help? For a 20-person business, a full documentation layer typically runs £3,000 to £9,000 depending on how much writing stays in house and how much process redesign is needed first. If your processes need fixing before they are documented, that is a separate and larger piece of work, described in what a business operations consultant does.

What do we do first if we have nothing at all? Write the five SOPs for the tasks that stop entirely when one specific person is on holiday. Those five documents remove more risk than the next fifty combined, and they will show you quickly whether your real problem is documentation or structure.

Related Reading

• ·How to create SOPs for a growing team
• ·Why your business needs SOPs
• ·How to document business processes
• ·Why founders become the bottleneck
• ·Our SOP and documentation service
• ·Systems and tools implementation
• ·Talk to us about your operations