SOP Stack: What to Document First

TL;DR

• Don’t document everything. Document the SOP stack in the order that reduces friction fastest.
• Start with work intake + handoffs + escalation, not “perfect” process maps.
• Aim for usable SOPs (1–2 pages) that people actually follow.

When to use this playbook

Use this when you see:

• repeated mistakes and rework
• “tribal knowledge” dependencies
• handoffs breaking across teams
• onboarding taking too long
• founders being pulled into routine ops decisions

If the company says “we need SOPs,” this playbook tells you which SOPs first.

What success looks like

By the end of Week 2–4 (even part-time), you should see:

• fewer repeated questions in Slack/email
• faster handoffs between teams
• less founder escalation for routine decisions
• smoother onboarding for new hires
• fewer “misses” caused by unclear ownership

The SOP Stack (document in this order)

Level 0: Rules of the game (before SOPs)

Before writing SOPs, document two short “rules” pages:

1. Decision Rights

• Who decides what (examples)
• Escalation path when stuck
• What must be documented vs can be ad-hoc

2. Service Levels

• Response expectations (internal + external)
• Definitions of “urgent”
• Time windows where decisions must happen

These prevent SOPs becoming suggestions.

Level 1: Intake (where work begins)

Document FIRST: how work enters the system.

Why: Most chaos starts at intake. If intake is messy, SOPs downstream won’t stick.

SOPs to create

• Request intake (form or template)
• Priority rules (simple)
• Required fields (what “good request” looks like)
• Assignment rules (who owns triage)

Minimum artifact

• One intake template used across functions

Level 2: Handoffs (where work dies)

Document NEXT: handoffs between roles/teams.

Why: Handoffs cause delays, missed context, and blame cycles.

SOPs to create

• Handoff checklist (what must be included)
• Definition of done for each handoff
• Ownership rules (who owns it until acceptance)

Minimum artifact

• A “handoff card” template or checklist

Level 3: Escalation & exception handling

Document THIRD: what happens when things go wrong.

Why: Exceptions dominate reality. If exceptions are undocumented, everything escalates to founders.

SOPs to create

• Escalation triggers (when to escalate)
• Escalation ladder (who next)
• Incident response checklist (lightweight)
• Rollback/containment steps (where applicable)

Minimum artifact

• A 1-page escalation playbook

Level 4: Core operating cadence

Document FOURTH: weekly rhythm that keeps operations stable.

Why: Cadence makes SOPs live, because people review, improve, and enforce them.

SOPs to create

• Weekly Ops Review (agenda + outputs)
• Weekly priorities (who publishes + when)
• Decision log (what is captured)
• KPI review (what “good” looks like)

Minimum artifact

• One weekly meeting that produces decisions + owners

Level 5: High-frequency workflows (the repeatables)

Only now do you document specific workflows.

Pick the top 3 workflows by:

• volume (happens weekly/daily)
• cost of mistakes (high risk)
• recurring escalations

Examples:

• customer onboarding steps
• order issue resolution
• refunds/returns approvals
• quote-to-cash handoffs
• inventory exception handling

Minimum artifact

• 3 workflows documented and adopted

Level 6: Onboarding & role scorecards

After the system is stable, document:

• role scorecards (outcomes, not tasks)
• onboarding checklists
• first 30 days expectations

Why: SOPs are useless if onboarding doesn’t teach them.

SOP format that actually gets used (simple standard)

Every SOP should fit on one screen if possible.

SOP template (use this exactly)

1. Purpose (1–2 lines)
2. Owner (role, not person)
3. Trigger (when it starts)
4. Inputs (what you need)
5. Steps (5–9 bullets max)
6. Definition of Done (clear)
7. Exceptions (what to do if…)
8. Links (forms, tools, related SOPs)
9. Last updated + version

If it needs 10 pages, it’s either:

• too complex, or
• trying to cover edge cases that should be exceptions.

Step-by-step: How to execute as a fractional Ops leader

Step 1 — Identify “highest pain” areas fast (60–90 min)

Collect:

• top recurring escalations
• top repeated mistakes
• top “stuck” handoffs

Output:

• Top 10 SOP candidates
• Ranked by impact + frequency

Step 2 — Pick the first 5 SOPs (and stop)

Start with:

1. Intake SOP
2. Handoff SOP
3. Escalation SOP
4. Weekly cadence SOP
5. One high-frequency workflow SOP

This creates a stable base.

Step 3 — Write “v1 SOPs” fast (don’t perfect them)

Aim: 60–90 minutes per SOP max.

Rules:

• write for reality, not ideal
• include exceptions
• define done + owner

Output:

• SOP v1 library (5 items)

Step 4 — Train via usage (not training sessions)

Training happens by:

• running one real workflow using SOP
• reviewing what broke
• updating SOP immediately

Output:

• SOP v1.1 quickly (build trust)

Step 5 — Assign ownership and review cadence

Every SOP must have:

• owner (role)
• review frequency (monthly/quarterly)

Output:

• SOP stewardship model (simple)

Artifacts included (publish as resources or include inline)

1. SOP template (copy/paste)
2. Intake request template
3. Handoff checklist
4. Escalation ladder template
5. Weekly Ops Review agenda template
6. SOP library tracker (SOP name, owner, status, last updated)

Common failure modes (and fixes)

Failure mode 1: Documenting the wrong things first

Fix: start with intake/handoffs/escalation, not “nice to have.”

Failure mode 2: SOPs become “documentation theatre”

Fix: SOPs must be tied to cadence + owned.

Failure mode 3: SOPs are too long

Fix: 1–2 pages, link out for edge cases.

Failure mode 4: No one owns upkeep

Fix: assign owner + review date. Non-negotiable.

Failure mode 5: People ignore SOPs

Fix: enforce via intake gates + definition of done. If the process doesn’t require it, it won’t be followed.

What to do after the first SOP stack is in place (30–60 days)

Once the foundation is set:

• expand workflow SOPs (3 → 10)
• add role scorecards + onboarding
• add metrics per SOP (cycle time, error rate)

This is how SOPs turn into an operating system.

Turn this into a buyer-ready Ops deliverable

If you want to package this playbook as a clear offer:

• “SOP Stack Sprint” (2 weeks)
• plus a retainer option to expand coverage

Build your Ops fractional profile to this standard.
Build Fractional Profile
Powered by Zeroed