Writing SOPs (Standard Operating Procedures) for Small Teams
Productivity

Writing SOPs (Standard Operating Procedures) for Small Teams

How to write SOPs that actually get used — what to document first, the format that works, AI-assisted SOP creation, and the review cadence.

Daniel Park
By Daniel Park
11 min read

Why Most SOP Initiatives Fail

The pattern is familiar: a founder decides "we need to document our processes." Two weeks later, the team has written 30 SOPs. Six months later, nobody has read any of them, the processes have evolved, and the docs are out of date. The SOP initiative quietly dies, often blamed on the team's "lack of discipline."

The problem usually isn't discipline. It's prioritization. Most SOP failures come from documenting too much, in the wrong format, without a review cadence. This guide covers what to document, what to skip, the format that works, and the rhythm that keeps SOPs alive.

For broader operational thinking, pair this with automating repetitive tasks and delegation for founders.

What Deserves an SOP (And What Doesn't)

Not every process needs documentation. The decision matrix:

TraitDocuments Justified?
Done by multiple peopleYes
Done frequently (>1×/month)Yes
High failure cost (legal, financial, security)Yes
New hires need to learn it within first 60 daysYes
Done once, by one personNo
Done quarterly by one person who knows itNo
Done by one person who's about to leave or be replacedYes (transition)
Inherently judgment-based, hard to specifyNo (write a framework instead)
Highly variable from instance to instanceNo

The 80/20: in a 10-person team, roughly 15–25 SOPs cover most operational risk. Documenting 60 processes produces documentation nobody can find or trust.

The Format That Works

Every SOP follows the same template. Consistency matters more than format details — when documentation is consistent, the team learns where to find specific information quickly.

SectionPurpose
TitleSpecific, action-oriented (e.g., "Onboarding a New Enterprise Customer," not "Customer Onboarding")
OwnerOne named person responsible for keeping the SOP current
Last reviewedDate of most recent review (visible at top)
PurposeOne sentence: why this SOP exists and what it produces
PrerequisitesTools, access, information needed before starting
StepsNumbered, specific actions in order
Success criteriaHow you know the process is done correctly
Edge casesThe 3–5 most common variations and how to handle each
EscalationWhen and to whom to escalate if blocked
Related docsLinks to relevant other SOPs, forms, templates

Example Skeleton

# Onboarding a New Enterprise Customer

**Owner:** Sarah K. (Head of CS)
**Last reviewed:** 2026-05-15

## Purpose
Get a new enterprise customer from signed contract to first successful login
within 5 business days.

## Prerequisites
- Signed master service agreement
- Procurement-approved billing setup
- IT contact identified

## Steps
1. Create company workspace in production: ...
2. Send welcome email (template: /templates/enterprise-welcome): ...
3. ...

## Success criteria
- Primary user has logged in
- Workspace contains at least one project
- 30-min kickoff call scheduled

## Edge cases
- Customer requires SSO setup: ...
- Customer is on a custom data residency tier: ...

## Escalation
If blocked >24h: ping Sarah in #cs-emergencies

This format consistently outperforms longer, more discursive SOPs.

What to Document First

Most teams document the wrong things first (often the things that are easiest to describe). The right starting set:

  1. Customer onboarding (highest revenue impact, easiest to learn)
  2. Customer offboarding / cancellation handling
  3. New hire onboarding (use the new-hire onboarding checklist as a starting point)
  4. Production incident response (security, downtime, data issues)
  5. Refund / billing dispute handling
  6. Tier 2 support escalation
  7. New customer security review process
  8. Monthly close / financial reconciliation
  9. Marketing campaign launch checklist
  10. Hiring process and interview rubric

These ten SOPs cover the highest-stakes operational moments in a typical small B2B company. Document these first; expand the library after these are stable and used.

How AI Cuts SOP Writing Time

Documenting a process from scratch is slow. Documenting it from a recording is fast. The pattern:

  1. Record the process happening. Use Loom, Granola, or a recorded screen share with audio narration. Capture the actual workflow as someone does it.

  2. Transcribe. Most recording tools auto-transcribe. If not, ChatGPT/Claude can transcribe from audio.

  3. Convert to SOP format. Paste the transcript into Claude or ChatGPT with the prompt:

    "Convert this transcript into an SOP using the following format: [your template]. Be specific, use numbered steps, identify prerequisites, and flag edge cases the person mentioned."

  4. Edit for clarity. The AI output gets you 70–80% there. The remaining 20% is removing filler, tightening language, and adding what was missed.

This pattern cuts SOP authoring time from 3–4 hours to 45–60 minutes for a typical process. Combined with our AI tools stack for founders recommendations, SOPs become realistic to write at scale.

Where to Store SOPs

Storage matters as much as content. The wrong storage choices kill adoption.

StorageStrengthsWeaknesses
Notion / CodaSearchable, hierarchical, easy to updateCan get messy without discipline; permissions complexity
ConfluenceEnterprise-friendly, good versioningSlower to update; older UX
Google DriveUniversal accessHard to maintain structure
GitHub / GitLabVersion-controlled, code-team friendlyWrong tool for non-technical SOPs
Slab / TettraBuilt for documentation specificallyYet another tool
Inline in Slack / LoomEasy to createImpossible to find again

For most small teams, Notion is the right answer — search works, hierarchy is flexible, embedding video and images is trivial. Build a single "Playbook" or "Operations" workspace; don't scatter SOPs across personal pages.

The Review Cadence That Keeps SOPs Alive

SOPs rot. The process changes; the doc doesn't. The team stops trusting the docs because they're often wrong. To prevent rot:

Quarterly Review

Every quarter, each SOP owner reviews their docs:

  • Is this still accurate?
  • Has the process changed since the last review?
  • Are there new edge cases to add?
  • Should this SOP be retired (process no longer exists)?

The review takes 5–15 minutes per SOP. Block 60 minutes per quarter per owner to handle their library.

Update-on-Change Discipline

When a process meaningfully changes, the person making the change updates the SOP in the same session. Not "I'll update it later" — within the hour. Late updates rarely happen.

Last-Reviewed Date at the Top

The visible "last reviewed: YYYY-MM-DD" at the top of every SOP is the lightweight enforcement mechanism. Anyone using the doc can immediately see if it's been touched in 6+ months — and treat it skeptically if so.

Sunset Old SOPs

If an SOP hasn't been used or updated in 12 months, archive it. Active documentation libraries are smaller than people expect; sprawl kills usability.

Common SOP Mistakes

Documenting Too Much

The temptation is to document everything. The reality is the team can't use a 200-document library — they can't find specific docs, they can't trust which ones are current, they default to asking colleagues instead. A small, well-maintained library beats a sprawling one every time.

Writing in Prose, Not Steps

"To onboard an enterprise customer, you'll first want to create their workspace. Then it's important to send the welcome email..." This format is slower to read and harder to execute than:

  1. Create the workspace
  2. Send the welcome email
  3. Schedule the kickoff call

Use numbered steps. Always.

No Named Owner

SOPs without owners rot fastest. Every SOP needs one named person responsible for keeping it current. When that person leaves, the ownership transfers explicitly.

Documenting Judgment-Based Work

Some processes are inherently judgment-based — sales discovery, hiring decisions, design choices. These can't be SOPs; trying to document them produces brittle, wrong-feeling docs. Use frameworks and checklists instead. See our decision-making frameworks for an alternative pattern.

No Review Cadence

The SOP library written once and never updated is the most common pattern. Six months later, nothing is current; nobody trusts the docs; the initiative is declared a failure. Build the quarterly review into your operating cadence from day one.

Hiding SOPs Behind Permission Walls

Documentation that isn't discoverable doesn't get used. Default to broad read access; tighten only when there's a real reason. The team that finds the docs is the team that uses them.

When You Don't Need SOPs (Not For You)

Skip the formal SOP investment if:

  • You're a team of 3 or fewer. Tribal knowledge works at this scale. Documentation effort outpaces value.
  • Every customer journey is genuinely unique. Highly bespoke consulting or services work doesn't benefit from rigid SOPs; document frameworks and decision criteria instead.
  • You're pre-product-market fit. Processes shift weekly. Documenting them creates more confusion than clarity. Wait until processes are stable for at least 60 days.
  • Your team uses a single product / tool that has its own runbook. Don't duplicate what the vendor's docs already cover.

Conclusion

SOPs are an investment that compounds — or rots, depending on whether the discipline is real. Document the right things (high-frequency, multi-person, high-failure-cost processes). Use a consistent format. Store in a searchable system. Review quarterly. Update on change.

Most small teams benefit from 15–25 well-maintained SOPs. Beyond that, you're documenting for documentation's sake. Pair SOPs with the operational discipline of automation, strong time management, and a coherent AI tool stack — and you've built the operating system that lets a small team punch above its weight.

Frequently Asked Questions

What is an SOP?

A Standard Operating Procedure (SOP) is a documented, step-by-step process for completing a specific operational task consistently. SOPs reduce dependency on individual knowledge, accelerate onboarding, and maintain quality when the same work is done by multiple people. Common examples: customer onboarding, incident response, monthly close, hiring process.

What should I document as an SOP first?

Document processes that are (1) done by multiple people, (2) done frequently, or (3) have high failure cost. Skip the rest. Typical first 10: customer onboarding, customer offboarding, new hire onboarding, incident response, refund handling, support escalation, security review, monthly close, marketing launch checklist, and hiring process.

How long should an SOP be?

Long enough to cover the process; short enough to actually be read. Most useful SOPs are 1–3 pages. Anything longer suggests the process should be split into multiple SOPs. Use numbered steps, not prose. Specificity matters more than length.

What's the best tool for storing SOPs?

Notion is the right answer for most small teams — searchable, hierarchical, easy to update, supports embeds. Confluence works at enterprise scale. Slab and Tettra are built specifically for documentation. Avoid Google Drive (hard to maintain structure) and GitHub (wrong tool for non-technical SOPs). Choose one and use it consistently.

How often should SOPs be reviewed?

Quarterly minimum. Every SOP owner reviews their docs once per quarter for accuracy. Additionally, any time a process meaningfully changes, the SOP gets updated in the same session — not later. The visible 'last reviewed' date at the top of each SOP is a lightweight enforcement mechanism.

Can AI write my SOPs?

AI accelerates SOP writing dramatically when paired with recordings. Pattern: record the process happening (Loom, screen share), get the transcript, paste into Claude or ChatGPT with your SOP template, edit the output for clarity. This typically cuts authoring time from 3–4 hours to 45–60 minutes per process. Pure AI-generated SOPs without grounding in real process recordings tend to miss the edge cases that matter.

How many SOPs does a small team need?

A 10-person team typically needs 15–25 well-maintained SOPs. Below 10, you can get by with 8–12. Above 25, you're documenting for documentation's sake — the library becomes hard to navigate and trust. Smaller, current libraries outperform sprawling, partially-current ones.

SOPsdocumentationoperationsprocesssmall teams
Daniel Park

About Daniel Park

CTO & Technology Editor

Daniel Park spent eight years as an engineering lead at Google before leaving to build his own SaaS company, which he bootstrapped to $3M ARR and eventually sold. With an MS from Carnegie Mellon and an AWS Solutions Architect certification, he writes about the technical decisions that make or break startups — from choosing your stack to hiring your first engineers.

View All Articles →