Operations Playbook Template: COO's Framework

When Tobi Lutke scaled Shopify from 500 to 10,000 employees in four years, the operations team faced a recurring problem: every time a new team was created or a process was handed off, weeks of productivity were lost to "figuring out how things work." The solution was not more meetings or better onboarding. It was a systematic operations playbook — a living document that codified how the company actually ran, not how anyone imagined it ran.

A 2025 Process Excellence Network survey found that 67% of mid-market companies still rely on tribal knowledge for at least half of their core operational processes. When key employees leave, that knowledge walks out the door. When teams scale, undocumented processes break. When crises hit, there is no fallback plan because the plan existed only in someone's head.

The operations playbook solves this. It is the single document (or system of documents) that answers: "How does this company actually operate?"

Key Takeaways

An operations playbook is not an SOP manual — it is the complete operating system of your company, including process documentation, decision frameworks, escalation paths, and operating cadences
Companies with documented operations playbooks scale 2.3x faster and experience 40% less productivity loss during employee turnover (Deloitte 2025 Operational Maturity Study)
Start with your top 10 revenue-critical processes — not every process. Trying to document everything at once is how playbook initiatives die
The playbook must be a living system, not a static document. Assign process owners, review quarterly, and build updates into your operating cadence
The best format is modular — each process is a standalone document that links to related processes, rather than one massive document nobody reads

What Goes in an Operations Playbook

The Five Sections Every Playbook Needs

Section 1: Operating Philosophy

This is the one page that explains how your company thinks about operations. It includes:

Operating principles (3-5 rules that guide operational decisions)
Decision-making framework (how decisions are made, who has authority for what)
Communication norms (async vs. sync, tools, response time expectations)

Example operating principles:

Default to async communication. Meetings are for decisions, not updates.
The person closest to the problem owns the solution.
Document before delegating. If a process is not written down, it is not ready to hand off.
Measure outcomes, not activity.

Section 2: Organizational Structure and Roles

Not a static org chart — a functional map that shows:

Who owns each operational domain
Decision rights by role (what each level can approve)
Escalation paths for cross-functional issues
RACI matrix for the top 20 operational processes

Process	Responsible	Accountable	Consulted	Informed
Customer onboarding	Onboarding Lead	VP Customer Success	Sales, Product	COO, CEO
Vendor procurement	Procurement Manager	VP Finance	Legal, requesting team	COO
Incident response	On-call engineer	VP Engineering	Customer Success	COO, CEO
Monthly close	Controller	CFO	Department heads	COO, CEO
New hire onboarding	HR Coordinator	VP People	Hiring manager, IT	COO

Section 3: Process Documentation

The core of the playbook. Each documented process follows a consistent template:

Process Documentation Template:

``` Process Name: [Name] Owner: [Name and role] Last Updated: [Date] Review Frequency: [Quarterly / Semi-annually]

PURPOSE Why this process exists and what outcome it produces.

TRIGGER What initiates this process (e.g., new customer signs contract, employee submits expense report, inventory falls below threshold).

INPUTS REQUIRED

[Input 1 and source]
[Input 2 and source]

STEPS

[Step with specific detail — who does what, in which system]
[Decision point: if X, go to step 3. If Y, go to step 5.]
[Step with expected duration]

...

OUTPUTS

[What this process produces]
[Where the output goes / who receives it]

SLA / TIMELINE Expected completion time: [X hours/days] Escalation trigger: [When to escalate and to whom]

TOOLS AND SYSTEMS

[System 1 — what it is used for in this process]
[System 2]

KNOWN EXCEPTIONS

[Situation that requires deviation from standard process]
[How to handle it]

METRICS

[How we measure if this process is working]

``` Section 4: Operating Cadence

Your meeting rhythm and reporting structure, documented so anyone can understand how the operational heartbeat of the company works:

Cadence	Meeting	Attendees	Duration	Purpose	Artifact
Daily	Standup	Ops leadership	15 min	Blockers and decisions	None (verbal)
Weekly	Ops review	COO + direct reports	60 min	Metrics, issues, priorities	Weekly ops scorecard
Weekly	Cross-functional sync	VP-level leads	30 min	Inter-team dependencies	Action item log
Monthly	Business review	C-suite	90 min	Financial and operational performance	Monthly ops report
Quarterly	Planning session	Leadership team	Half-day	Goals, resources, retrospective	Quarterly plan

Section 5: Escalation and Crisis Protocols

What happens when things go wrong — documented before they go wrong:

Severity levels (Sev1 through Sev4 with clear definitions)
Escalation matrix (who gets called for what, and in what order)
Communication templates for customer-facing incidents
Post-incident review process (how you learn from failures)

Building the Playbook: 90-Day Implementation Plan

Phase 1: Days 1-30 — Audit and Prioritize

Week 1-2: Process inventory

List every recurring operational process in your organization. Do not try to document them yet — just build the inventory. Categorize each process:

Revenue-critical (directly impacts revenue or customer experience)
Compliance-required (regulatory or legal obligation)
Operational support (internal processes that keep the business running)
Nice-to-have (processes that are helpful but not essential)

Week 3-4: Prioritize the top 10

Select the 10 processes that meet at least two of these criteria:

Run at least weekly
Involve more than one team
Currently dependent on tribal knowledge (one or two people who "just know")
Have caused problems in the last 6 months when something went wrong

These 10 processes are your Phase 1 documentation targets.

Phase 2: Days 31-60 — Document

Assign process owners. Each of your top 10 processes gets an owner — the person who runs it today. They are responsible for writing the documentation using your standard template. Run documentation sprints. Give process owners two weeks to complete their documentation. Hold a 30-minute review session with each owner to pressure-test their draft:

Can a competent new hire follow this process without asking questions?
Are all decision points explicitly documented?
Are tools and systems specified at each step?
Is the escalation path clear?
Are known exceptions documented?

Common documentation mistakes to avoid:

Writing aspirational processes (how you wish it worked) instead of actual processes (how it works today)
Skipping decision points — every "if/then" needs to be documented
Assuming tool knowledge — specify which system, which screen, which field
Leaving out the "why" — context helps people make good judgment calls when the process does not cover a specific situation

Phase 3: Days 61-90 — Systematize

Choose your playbook platform. The format matters less than the discipline, but options include:

Platform	Best For	Limitations
Notion	Fast setup, flexible, good for <100 people	Can get disorganized at scale
Confluence	Enterprise environments with Jira integration	Heavy, slow, often becomes a content graveyard
Slite	Clean interface, good search	Smaller ecosystem
GitBook	Engineering-heavy organizations	Less accessible for non-technical teams
Google Docs + Drive	Simplicity, universal access	No structure enforcement, hard to navigate

Build the review cadence. Every documented process gets a review date. At minimum, review quarterly. Build process reviews into your existing operating cadence — the monthly business review is a natural place to flag stale documentation. Create the onboarding pathway. One of the highest-value outputs of your playbook is a structured onboarding pathway for new hires. Map which playbook sections each role needs to read in their first 30 days.

Real-World Playbook Structure Example

Here is how a $30M B2B SaaS company might organize their operations playbook:

Level 1 — The Index (one page)

Operating Philosophy and Principles
Organizational Structure and Accountability Chart
Operating Cadence (meeting rhythm and reporting)
Core Processes (links to each documented process)
Escalation and Crisis Protocols
Tool and System Directory

Level 2 — Core Processes (one page each)

Sales-to-Customer-Success Handoff
Customer Onboarding (Enterprise)
Customer Onboarding (Self-Serve)
Support Ticket Escalation
Monthly Billing and Collections
Employee Onboarding
Vendor Procurement
Product Release Process
Incident Response
Monthly Financial Close

Level 3 — Detailed SOPs (as needed) Each core process links to more granular SOPs for specific sub-steps. These are maintained by the teams that execute them and reviewed quarterly.

The key design principle: a new VP joining the company should be able to read Level 1 and Level 2 in their first week and have a functional understanding of how the company operates. Level 3 is reference material they access when they need to go deeper on specific topics.

Measuring Playbook Effectiveness

Track these metrics to know whether your playbook is actually working:

Metric	Target	How to Measure
Process documentation coverage	>80% of critical processes documented	Audit against process inventory
Documentation freshness	100% reviewed within last 90 days	Track last-reviewed dates
New hire time-to-productivity	20% reduction from baseline	Compare onboarding cohorts
Process-related errors	Declining quarter-over-quarter	Incident tracking system
"How do I...?" questions in Slack	Declining month-over-month	Channel message analysis

Maintaining the Playbook Long-Term

The number one reason operations playbooks fail is that they become stale. After the initial documentation push, nobody updates them — and within six months, they are artifacts rather than tools.

Four habits that keep playbooks alive:

Process changes trigger documentation updates. Build this into your change management workflow. No process change is complete until the playbook is updated.
Quarterly process reviews. Each process owner reviews their documentation once per quarter and certifies it is current.
New hire feedback loop. Every new employee who uses the playbook during onboarding submits feedback on what was unclear, missing, or wrong. This is free quality assurance.
Playbook health metric. Track the percentage of documented processes reviewed in the last 90 days. Target: 100%. Below 80% is a red flag.

Frequently Asked Questions

How is an operations playbook different from an SOP manual?

An SOP manual documents individual procedures. An operations playbook is broader — it includes SOPs but also covers organizational structure, decision rights, operating cadence, escalation protocols, and the operating philosophy that ties everything together. Think of SOPs as individual chapters; the playbook is the entire book.

How long does it take to build an operations playbook from scratch?

For a company with 50-200 employees, expect 90 days to document your top 10 processes and build the framework. A comprehensive playbook covering all critical operations typically takes 6-9 months. The key is to start with the highest-impact processes and expand systematically rather than trying to document everything at once.

Who should own the operations playbook?

The COO owns the playbook as a system, but individual process owners maintain their sections. In companies without a COO, the VP of Operations or Chief of Staff typically owns it. The worst outcome is assigning ownership to a project manager who built the initial version — playbook ownership must sit at a level with authority to enforce updates.

What if people resist documenting their processes?

Resistance usually stems from one of two fears: that documentation will make them replaceable, or that it is busywork. Address both directly. People who document their work are more promotable (because they can hand off their current role), not less valuable. And frame documentation as a tool that saves them time — they will stop getting interrupted by the same questions once their process is written down.

How detailed should process documentation be?

Detailed enough that a competent professional new to your organization could execute the process without asking clarifying questions. This is the "new hire test." If your documentation requires verbal context from the process owner to follow, it is not detailed enough.

The Operations Playbook: A COO's Framework for Documenting Everything