Standard Operating Procedures rot in Drive folders. Founders write them once, never update them, and discover them again three years later when an employee leaves and nobody else knows how the work was done. The problem isn't writing SOPs. It's writing SOPs that anyone reads.

This is the framework we use with operations-heavy businesses to build documentation that actually gets followed — not because we said so, but because the format makes it easier to follow than to ignore.

Why Most SOPs Fail

The pattern is consistent across every business we audit:

  • They're too long. Twenty pages explaining a 5-step process. Nobody reads twenty pages.
  • They're too generic. Vague language ("ensure quality is maintained") that doesn't tell anyone what to actually do.
  • They have no owner. When the SOP is wrong, nobody knows whose job it is to fix it.
  • They're stored where nobody looks. A folder in Drive that requires three clicks to reach.
  • They're never updated. The version from 2023 is still being referenced in 2026, and the process changed twice.

The Format That Works: One Page, Five Sections

Every SOP fits on one page. If it doesn't, you've got two SOPs glued together and you should split them. The five sections:

1. Trigger (1–2 lines)

What event causes this SOP to run? "When a new customer order is placed in Shopify." Specific enough that there's no ambiguity about when this applies.

2. Owner (1 line)

The role responsible for this SOP being current. Not "the operations team" — a specific role: "Operations Manager." If the role doesn't exist, this SOP is orphaned.

3. Steps (5–10 numbered actions)

Each step is one verb-led action. "Verify the order ships from the right warehouse based on customer pincode." Not "ensure correct dispatch routing." Anyone reading should know exactly what to do, not need to interpret.

4. Failure Modes (3–5 bullets)

What can go wrong? What does the operator do if it does? "If the warehouse is out of stock, escalate to Inventory Manager via Slack #ops-alerts within 30 minutes." Specific channel, specific person, specific timing.

5. Last Updated + Version (1 line)

"v3.2 — updated by Priya R., Feb 2026." If this is more than six months stale, it's a candidate for review.

An SOP that fits on one page gets read. An SOP that takes ten pages gets ignored — and an ignored SOP is worse than no SOP, because it creates the illusion of process where there is none.

Versioning and Ownership

Every SOP has a single owner. The owner is responsible for:

  • Reviewing the SOP every quarter (calendar reminder, not vibes).
  • Updating it when the process changes — within 7 days of the change.
  • Bumping the version number and noting what changed.

Without ownership, SOPs decay. Within ownership, they stay live.

Where to Store Them

Two rules:

  • Searchable, not navigated. An employee shouldn't need to know where an SOP lives. They should be able to type a keyword and find it. Notion, Confluence, or even a well-tagged Google Drive works.
  • Linked from where the work happens. The SOP for "process a return" should be linked from inside your returns ticketing tool, not buried in a folder. Friction kills SOP usage.

The Onboarding Hack

Every new hire's first week task: read the SOPs for their function, identify three things that are wrong or unclear, and propose updates. This serves three purposes:

  • The new hire learns the function deeply.
  • The SOPs get updated by fresh eyes who haven't normalised the process drift.
  • You signal that documentation is a living thing, not a write-once artefact.

The "Friday rule"

Every Friday, the operations lead spends 30 minutes asking: "Which SOP did I reference this week? Was it accurate?" If not, fix it before Monday. This single habit keeps documentation alive in a way nothing else does.

What Not to SOP

Not everything needs an SOP. Things that benefit from documentation:

  • Repeated processes done by multiple people (returns handling, customer onboarding, vendor payments).
  • Processes with compliance or quality consequences (POSH process, financial close).
  • Processes where institutional knowledge would be expensive to lose.

Things that don't:

  • One-off founder decisions.
  • Strategic discussions.
  • Anything that changes faster than you can document it.

Over-documentation is its own problem. The goal is institutional resilience, not bureaucratic theatre.

Working through this and want hands-on help? Explore our Operational consulting services — we offer retained partnerships, project sprints, and 30-day audits.