The SOP Playbook: Documentation That Actually Gets Used

If your business would stall the week a key person is off sick, your processes live in people, not in the business. This playbook shows you how to move them out of heads and into a system your team actually uses — without a six-month documentation project that ends in a shared drive nobody opens.

Who this is for

This guide is written for businesses turning over roughly $1M–$20M (£1M–£15M), with 10 to 150 people, where:

• The CEO is still the escalation point for decisions a manager should own.

• Quality depends on who does the work, not how the work is done.

• Onboarding a new hire takes months and leans on whoever has time to shadow them.

• You have tried documenting processes before, and it didn’t stick.

How to read it

The guide has two reading paths. Each takes under 30 minutes.

Every section opens with its point in one sentence. If that sentence is all you need, move on.

Executive summary

SOPs fail because nobody owns them after they’re written. Fix the ownership and the loop, and the writing becomes the easy part.

The problem. Most growing businesses run on tribal knowledge. It works at 10 people because everyone sits near the person who knows. Past 20–30 people, it becomes a tax: on the CEO’s time, on onboarding, on quality, and on the valuation of the business itself. A buyer or investor pays less for a company that only works when its founding team is in the room.

Why previous attempts failed. Documentation projects are usually treated as a one-off writing exercise. Someone is told to “get the processes down”, produces a folder of long Word documents, and the library is out of date within a quarter. The failure is structural, not a matter of effort.

The system. Documentation that gets used has four properties:

1. The right format — a checklist, decision tree, narrative, playbook or video, matched to the task.

2. The right location — inside the tool where the work happens, one click from the task.

3. A named owner — one person accountable for each document’s accuracy, reviewed quarterly.

4. A loop — onboarding, the weekly meeting rhythm and a quarterly audit, which together keep it alive.

What it takes. A realistic first phase is 90 days: five priority SOPs written, embedded and in use, owners named, and the review rhythm running. Expect roughly two to four hours a week from an operations lead and one to two hours from each process owner during that period. The CEO’s role is sponsorship and enforcement, not authorship.

What you get. Faster onboarding, fewer escalations to the top, more consistent client delivery, and a business that is less dependent on any one person — including you.

The decision for you. Name an accountable owner for the programme, approve the first five workflows, and commit to asking “where’s the SOP?” every time an avoidable problem reaches your desk.

The business case: what undocumented operations cost you

In a typical 40-person business, undocumented processes quietly cost six figures a year — and almost none of it shows up as a line on the P&L.

The cost hides in four places. None of them is labelled “missing SOPs” in your accounts, which is why the problem is easy to tolerate and hard to fund.

1. Leadership time. Every question that should be answered by a document is answered by a person — usually the most expensive one available.

2. Manager time. Managers re-explain the same tasks, check work that should be self-checking, and shadow new starters for weeks.

3. Slow ramp-up. New hires take longer to reach full productivity when the only training material is a colleague’s memory.

4. Rework and errors. Inconsistent execution produces mistakes that cost refunds, write-offs, overtime and client goodwill.

There is a fifth cost that matters most at exit or investment: key-person dependency. Buyers and investors look hard at whether a business can run without its founders and senior people. Documented, owned processes are part of the evidence that it can.

A worked example

The model below is illustrative. It uses assumptions for a $6M, 40-person service business. Replace each input with your own numbers — the structure is what matters.

What the fix costs. The 90-day programme in this guide needs roughly 3 hours a week from an operations lead and 1.5 hours a week from each of five process owners. At the same loaded rates, that is under $9,000 of internal time, plus whatever your documentation tool costs.

The honest read. No documentation system removes all of these costs. But recovering even a third of them — about $53,000 in this example — returns the investment several times over in year one. The bigger prize is the CEO’s freed time, redirected to the work only the CEO can do.

Run this for your business: for one week, ask every manager to log each time they answer a question or fix an error that a written process would have prevented. Multiply by 46. Most leadership teams are surprised by the answer.

Why most SOPs die

Teams don’t ignore documentation because they’re lazy. They ignore it because it was written once, stored somewhere else, and never became part of how work happens.

Adoption is a systems problem. Almost every failed SOP library traces back to one or more of five failure modes. Diagnose which ones apply before you write a single new document — otherwise you’ll rebuild the same graveyard.

The most common pattern is a burst of effort — often led by the CEO or a new operations hire — that produces a large volume of documents in a few weeks. Volume feels like progress. But a library of 60 untested SOPs is worse than five that are used daily, because it teaches the team that documentation is something to ignore.

The principle for the rest of this guide: an SOP is not finished when it is written. It is finished when someone who has never done the task can complete it correctly using only the document.

Diagnostic: where is your business today?

Score yourself honestly on the ten statements below; your total tells you which level you’re at and where to start.

Score each statement: 0 = not true, 1 = partly true, 2 = fully true. Ask two or three managers to score it independently — the gaps between your answers are as revealing as the total.

What your score means

A warning for Level 1 businesses: do not start by writing more. Start by deleting. A smaller library people trust beats a large one they don’t.

What to document first

Document the work that happens often and hurts badly when it goes wrong; leave the rest until the loop is running.

Most businesses have 50 to 150 recurring workflows. You will not document them all, and you shouldn’t try. Rank them on two questions:

• How often does it happen? Daily and weekly tasks compound errors fastest.

• How much does it cost when it goes wrong? Think revenue, client relationships, compliance and cash.

Then apply one override: any workflow only one person knows goes up a tier, whatever its score. That is your key-person risk, and it is the cheapest risk in the business to remove.

what to document first · frequency × consequence

The top-right quadrant is your first wave; a single-person task anywhere on the grid moves up a tier.

Scoring your list

List your workflows in a spreadsheet. Score each from 1 to 5 on frequency and consequence, multiply the two, and add 5 points if only one person can do it. Sort by total. The top five are your first wave.

Don’t confuse “important” with “documentable”. Strategy, senior hiring decisions and complex negotiations need judgement frameworks, not step-by-step procedures. Document the repeatable parts — the hiring process, the proposal template, the approval thresholds — and leave the judgement to the people you hired for it.

The five formats and when to use each

Choosing the wrong format is the second-biggest killer of adoption after the wrong location; match the format to the kind of thinking the task needs.

A single company template, used for everything, guarantees that most of your SOPs will be the wrong shape. A checklist cannot explain a judgement call. A narrative cannot be followed at speed. Pick the format first, then write.

Choosing in 30 seconds

1. Does the person need to understand why, not just what? → Process narrative, with steps linked out.

2. Does the task involve a choice between outcomes based on rules? → Decision tree.

3. Does it happen inside a piece of software? → Video walkthrough plus a short checklist.

4. Does it span several people and several days? → Playbook that links smaller SOPs.

5. Otherwise → Checklist.

Formats combine. The strongest SOP sets are layered: a one-page narrative explains the process, links to the checklist people run, which links to a two-minute video for the tricky software step. Each piece does one job.

Writing SOPs people can follow

Write for the person doing the task on their worst day: tired, interrupted, new to the role, and under time pressure.

If the SOP works for that person, it works for everyone. Most SOPs are written for the author — someone who already knows the process and skips the steps that feel obvious.

The anatomy of a usable SOP

Every SOP, whatever its format, carries the same seven elements at the top or bottom:

Seven writing rules

1. One action per step. “Open the CRM and update the deal” is two steps.

2. Start every step with a verb. Open, check, send, record, confirm.

3. Name the exact thing. Not “the template” but “the Kickoff Agenda template in the Delivery folder”, with a link.

4. Show the interface. Add a screenshot wherever the person has to find something on screen.

5. Flag the traps. Mark the steps where people usually go wrong with a short warning.

6. Two pages maximum. Past that, split it into smaller SOPs and link them from a playbook.

7. Test it before you publish. Hand it to someone who has never done the task. Watch them, without helping. Every question they ask is a gap in the document.

Before and after

Before (typical first draft):

When a new client signs, make sure delivery knows about it and has everything they need from sales. The account manager should set up the kickoff and make sure the client is happy with the next steps.

After:

1. Within 24 hours of Closed Won, complete the Handover Form in the CRM deal record.

2. Attach the signed proposal and the scope summary to the form.

3. Tag the delivery lead in the deal and assign them the task “Review handover”.

4. Book a 30-minute internal handover call within 2 working days.

Done when: the delivery lead has marked “Review handover” complete and the kickoff is booked.

The first version describes an intention. The second describes behaviour — and can be checked.

Worked example: the sales-to-delivery handover

This is what a finished SOP looks like — the handover is the single workflow where growing service businesses most often lose margin and client trust.

When sales promises something delivery didn’t hear, the client experiences it as a broken promise in the first week of the relationship. Use this example as a pattern; adapt the steps, tools and timings to your business.

SOP: Hand a signed client over to delivery

Part A — Account Executive, within 24 hours of Closed Won

• Open the deal record and complete every field of the Handover Form.

• Write the scope summary: what we will deliver, by when, and what is explicitly out of scope.

• Record every promise made outside the proposal — discounts, extras, named people, deadlines.

• Note the client’s stated reason for buying, in their words.

• Attach the signed proposal and contract.

• Assign the task “Review handover” to the Delivery Lead.

Trap: verbal promises are the most common source of first-month disputes. If it was said on a call, it goes in the form.

Part B — Delivery Lead, within 2 working days

• Review the Handover Form and flag anything unclear or undeliverable.

• Hold a 30-minute internal handover call with the Account Executive.

• Confirm the delivery team and start date.

• Send the client welcome email (template: Client Welcome v3).

• Book the client kickoff call.

• Mark “Review handover” complete in the CRM.

Definition of done: the handover task is complete, the kickoff is booked, and the client has received the welcome email — all within 3 working days of Closed Won.

If something is undeliverable: the Delivery Lead escalates to the Head of Delivery the same day. The Account Executive does not contact the client about scope changes until that conversation has happened.

Why this example works: it has a trigger anyone can see in the system, one action per line, named templates, a clearly marked trap, a time limit, an escalation route, and a definition of done a manager can check in ten seconds.

Where SOPs live

An SOP more than one click from the task it describes will not be used; put documentation where the work is triggered, not where documents are stored.

The question is not “which tool should hold our SOPs?” It is “where is the person standing when they need this?” The answer is usually the CRM, the project management tool, the helpdesk or the finance system — not a documentation platform.

The two-layer model

The library is the source of truth. The trigger points are where adoption actually happens. Most failed SOP projects build the library and skip the trigger points.

Practical embedding patterns

• Project and task tools (such as Monday.com, Asana or ClickUp): build the checklist into a task template, so every new project starts with the SOP’s steps already assigned.

• CRM (such as HubSpot or Pipedrive): link the SOP from each deal stage, or make required fields enforce the key steps.

• Helpdesk: link the relevant SOP inside saved replies and ticket categories.

• Recurring meetings: link the reporting SOP in the calendar invite for the meeting it supports.

• Software tasks: record a short screen walkthrough and link it from the step where people get stuck.

Choosing the library tool

The best tool is the one your team already opens every day. For most $1M–$20M businesses, a well-organised wiki in your existing workspace beats a new specialist platform, because it removes one more login. Move to a dedicated training or SOP platform only when you need features you can’t get otherwise — for example, tracking who has read and acknowledged each document for compliance.

Rule of thumb: if introducing the tool needs its own adoption project, it is the wrong first step.

Ownership and governance

Every SOP needs exactly one named owner — not a team, not a department — with the authority to change it and the duty to review it.

Shared ownership is no ownership. When “Operations” owns a document, nobody updates it when the process changes, and within months the team learns to distrust it.

What an owner does

• Keeps the SOP accurate whenever the process, tool or team changes.

• Approves edits suggested by the people who use it.

• Runs the quarterly review and records the date.

• Retires the SOP when the process no longer exists.

The owner is usually the person who manages the work, not the person who does it. The person who does the work writes and suggests changes; the owner decides.

Roles across the programme

Version control, kept simple

You don’t need a document management system. You need three habits:

1. One master copy. No local versions, no attachments in email. Everything links to the library.

2. A change line at the bottom. Date, what changed, who approved it. One line per change.

3. Visible review dates. Every SOP shows its last and next review date at the top. Anything overdue is flagged in the monthly report.

Watch for the owner who leaves. When an owner changes role or leaves, reassigning their SOPs is part of the exit checklist. Orphaned documents are how libraries start to rot.

The embed-and-audit loop

Documentation becomes real through three mechanisms running together — onboarding, the weekly rhythm and a quarterly audit; without the loop, the library rots within a quarter.

Each mechanism catches a different kind of decay. Onboarding catches SOPs that are unclear. The weekly rhythm catches SOPs that are wrong. The quarterly audit catches SOPs that are out of date or no longer needed.

embed-and-audit loop · 3 mechanisms, 1 library

Remove any one loop and that kind of decay goes uncaught.

1. Onboarding: the stress test

New starters are your best testers, because they don’t know the shortcuts. Train them from the SOPs, not around them.

• Give every new hire a list of the SOPs for their role in week one.

• Ask them to complete core tasks using the document first, then check with their manager.

• Ask them to log every point where the SOP was unclear, missing or wrong.

• The SOP owner fixes those gaps within two weeks.

This turns every hire into an improvement cycle — and gives the new person a fast way to contribute.

2. The weekly rhythm: fix it this week

Add one standing question to your weekly leadership or team meeting: “Did anything go wrong this week that a missing or wrong SOP caused?”

• Trace each recurring problem to its root: no SOP, wrong SOP, or SOP not followed.

• No SOP or wrong SOP → assign the owner to fix it before next week’s meeting.

• SOP not followed → a management conversation, not a documentation one.

If you run EOS or a similar operating system, this fits naturally into the Issues list. Recurring issues are usually a process problem wearing a people costume.

3. The quarterly audit: keep or kill

Once a quarter, each owner reviews their SOPs against four questions:

1. Is it still accurate? (Walk through it against how the work is done today.)

2. Is it being used? (Ask the people who do the task.)

3. Is it in the right place? (Is it linked where the work happens?)

4. Is it still needed? (Archive anything that describes a process you’ve stopped.)

The programme lead reports the results: SOPs reviewed, updated, archived and overdue. Overdue reviews go to the executive sponsor.

Deleting is a success. A smaller, accurate library is healthier than a large, partly wrong one.

Adoption mechanics: what makes SOPs stick

People follow SOPs when their managers do; adoption is driven by five manager behaviours, not by the quality of the documents.

A perfect SOP that managers bypass will be ignored within a month. An average SOP that managers consistently point to will improve and become standard. The behaviours below are what separate the two.

The five manager behaviours

Make the right way the easy way

Behaviour is shaped more by friction than by instruction. Wherever you can, design the process so that following the SOP is easier than skipping it:

• Build the checklist into the task template, so it’s already there.

• Make key steps required fields in the CRM, so the record can’t move forward without them.

• Use templates for emails, proposals and reports, so the standard version is the fastest version.

The CEO’s role in adoption

In practice, the strongest signal of whether adoption will hold is whether the CEO enforces it. When an avoidable problem reaches your desk, your first question should be “Is there an SOP for this, and was it followed?” — not “Let me sort it.” Every time you solve it yourself, you teach the business that the real process is to ask you.

This is uncomfortable for many owner-led businesses, because solving problems is how the CEO built the company. It is also exactly the habit that caps the company’s growth at the CEO’s personal capacity.

Your first five SOPs

Start with the workflows where a single absence or mistake hurts most; for most businesses in the $1M–$20M range, these five deliver the fastest return.

Use your own prioritisation score if it points elsewhere. But if you’re starting from zero, these five cover the points where revenue, client trust and team capacity most often leak.

What “done” means for each

Each of the five is complete only when all of these are true:

• Drafted by the person who does the task, approved by the owner.

• Tested by someone who has never done it, and the gaps fixed.

• Linked from the tool where the work is triggered.

• Owner and next review date shown at the top.

• Used at least twice in live work, with any issues raised at the weekly meeting.

Resist the urge to do more. Five SOPs in daily use will change how your business runs. Fifteen half-finished ones will not. Expand only once the first five pass the checklist above.

The 90-day rollout plan

In 90 days you can move from tribal knowledge to five live, owned SOPs and a running review loop — if you sequence it in four phases and don’t skip the gates.

Each phase ends with a gate: a short check the executive sponsor signs off before the next phase starts. Gates stop the most common failure — writing lots of documents before anyone has agreed who owns them.

90-day rollout · 4 phases, 4 gates

No phase starts until the gate before it is signed off.

Phase 1 — Foundation (days 1–14)

• Name the executive sponsor and programme lead.

• Run the diagnostic with the leadership team.

• List and score your workflows; agree the first five.

• Name an owner for each of the five.

• Choose the library location and agree the SOP template.

Gate: five workflows agreed, five owners named and briefed.

Phase 2 — Build (days 15–45)

• Authors draft each SOP in the right format, using the template.

• Owners approve the drafts.

• Each SOP is tested by someone unfamiliar with the task; gaps are fixed.

• Add the standing SOP question to the weekly meeting.

Gate: five SOPs tested and approved.

Phase 3 — Embed (days 46–75)

• Link every SOP from the tool where the work is triggered.

• Build checklists into task templates and CRM stages where possible.

• Managers adopt the five behaviours; the sponsor models them.

• Train the next new starter from the SOPs and capture their feedback.

Gate: all five SOPs used in live work at least twice.

Phase 4 — Audit and extend (days 76–90)

• Run the first quarterly-style audit on the five.

• Report results to the leadership team: used, updated, gaps.

• Re-score the workflow list and choose the next wave.

• Set the quarterly audit dates for the next year.

Gate: audit complete; next wave agreed; review calendar set.

Measuring it

Track whether SOPs are being kept alive (leading indicators) and whether the business is getting better because of them (lagging indicators); counting documents measures neither.

The number of SOPs in your library is a vanity metric. A business with 200 documents and no reviews is in worse shape than one with 12 that are used daily.

Leading indicators: is the system healthy?

Review monthly. These tell you early whether the loop is working.

Lagging indicators: is the business better?

Review quarterly against a baseline you record before you start. Pick the three that matter most to you.

Take your baseline now. Most businesses skip this and then can’t show the board, or themselves, what changed. A rough baseline — even a one-week log — beats a precise number you never captured.

Who does what

The CEO sponsors and enforces, managers drive adoption, owners keep documents accurate, and the people doing the work write them — confuse these roles and the programme stalls.

The most common mistake in owner-led businesses is the CEO writing the SOPs. It feels efficient, because the CEO knows the most. But it produces documents that describe how the work should be done, not how it is done, and it keeps the CEO at the centre of the system you’re trying to build around them.

What we ask of the CEO, in practice

1. Approve the first five workflows and their owners in the first two weeks.

2. Protect the programme lead’s time for the 90 days.

3. Ask “what does the SOP say?” every time an avoidable problem reaches you.

4. Review the monthly health report in the leadership meeting.

5. Use the SOPs yourself — including the ones that constrain you.

Objections you’ll hear — and how to answer them

Resistance to documentation is predictable; prepare your answers before you launch, and most objections dissolve within the first month of use.

Listen for the fear under the objection. The most stubborn resistance usually comes from your most experienced people — whose knowledge is exactly what you need to capture. Involve them as authors and owners. Recognise their expertise publicly. People rarely resist a system they helped build.

Where this usually breaks — and when to bring in help

The method in this guide is simple; the hard part is holding the line for 90 days while the business keeps running at full speed.

Most SOP programmes don’t fail at the writing stage. They fail in weeks four to eight, when the first enthusiasm fades and day-to-day pressure takes over. Watch for these warning signs:

• The programme lead’s time gets taken back. Documentation always loses to the urgent. Without protected time, the work stops quietly.

• Owners approve without testing. SOPs go live untested, fail in use, and the team stops trusting them.

• The CEO keeps solving problems directly. The team learns the real process is still “ask the boss.”

• Embedding is skipped. The library exists, but nothing links to it from where the work happens.

• The first audit doesn’t happen. Once one quarter slips, the next one usually does too.

Signs you need outside support

Doing this internally works well when you have an operations lead with the time and authority to drive it. Consider outside support when:

• Nobody in the business has both the capacity and the authority to lead it.

• You’ve tried before and it stalled at the same point.

• The processes that most need documenting run through the CEO.

• You’re preparing for growth, investment or a sale, and need the operating system in place on a deadline.

• Documentation is one symptom of a wider issue — unclear roles, no meeting rhythm, decisions bottlenecked at the top.

How Markinly helps

Markinly provides fractional COO leadership to CEOs and business owners of growing companies in the UK, US and Europe. We don’t hand you a folder of documents. We embed with your leadership team, build the operating rhythm that keeps processes alive, and transfer ownership to your people so the system runs without us.

If this guide has surfaced more than you expected, that’s normal. Book a 30-minute conversation at markinly.com. We’ll look at where your operations are today and tell you honestly whether you need help, or whether this playbook is enough.

Appendix: templates you can use today

Copy these three templates into your library tool to skip the blank page.

A. The SOP template

# [Verb] + [task] (e.g. “Raise a client invoice”)

Format: Checklist | Decision tree | Narrative | Playbook | Video
Purpose: [One sentence: why this matters]
Trigger: [The event that starts this task]
Owner: [Named person]
Time to complete: [Estimate]
Last reviewed: [Date] Next review: [Date + 90 days]

## Before you start

• [Access, tools or information needed]

## Steps

1. [Verb] …
2. [Verb] …
   WARNING: [Common mistake at this step]
3. [Verb] …

## Definition of done
[What is true when the task is complete and correct]

## If something goes wrong
[Who to escalate to, and when]

## Change log
[Date] – [What changed] – [Approved by]

B. The quarterly audit checklist

For each SOP the owner reviews:

• Walked through it against how the task is done today.

• Asked at least one person who does the task whether it’s accurate and useful.

• Confirmed it’s linked from the tool where the work is triggered.

• Updated the steps, screenshots and links where needed.

• Decided: keep, update, merge or archive.

• Updated the review dates and change log.

The programme lead then records totals: reviewed, updated, archived, overdue.

C. The SOP owner charter

Share this with every new owner so the role is explicit.

As the owner of this SOP, I am accountable for:

1. Keeping it accurate whenever the process, tool or team changes.

2. Reviewing and approving changes suggested by the people who use it.

3. Fixing gaps raised in the weekly meeting before the next meeting.

4. Completing the quarterly review on time.

5. Handing ownership over formally if I change role or leave.

The SOP Playbook is published by Markinly International Management. You’re welcome to adapt these templates for use inside your own business.