Deutsch

Process Design and SOPs That Don't Rot in Notion

I ran an audit on a 47-doc Notion workspace last quarter. Thirty-one of them got archived. Not "marked for review." Archived. Gone from the sidebar. The team didn't notice for two weeks, and when they did, three people thanked me.

That's the actual state of most ops documentation. You inherit a workspace with forty-something SOPs spread across Notion, Confluence, and a Google Drive nobody has the link to. After six months, roughly 73% have drifted from the actual process. The author quit two quarters ago. New hires get walked through the "real" version verbally by whoever's free that Tuesday. The document exists for audit theatre. Nobody opens it.

This playbook is what I do instead. The 1-page SOP, Loom-first walkthroughs, a 90-day review cadence, and a ghost-doc diagnostic that tells you which 60% of your library to kill before the next quarter starts. None of it is theoretical. I've run it on three ops teams now, and the same pattern holds: cut the library by half, double the readership of what's left.

The 1-Page SOP (And What Gets Cut)

A working SOP has five fields. That's it. If you're writing a sixth, you're writing a training doc, not an SOP, and you should put it somewhere else.

Here's the literal template I paste into every new doc:

# {Process name}

**Purpose** (1 sentence): Why this exists and what breaks if it doesn't run.
**Owner**: {Named human, not a team}
**Last reviewed**: {YYYY-MM-DD}
**Next review**: {YYYY-MM-DD + 90 days}

## Steps
1. {Action verb + object + tool}
2. {...}
3. {...}

## Success criteria
- {Measurable outcome 1}
- {Measurable outcome 2}

## Escalation
If {trigger condition}, contact {person} within {timeframe}.

That fits on one printed page. It's deliberately ugly. No screenshots, no tables of context, no "background and rationale." Those things belong in a wiki, a Loom, or a kickoff meeting. Not here.

What gets cut and why:

Background sections. "This process was designed to address a 2024 incident where..." Nobody cares. The SOP is for the person doing the work today. If they need history, they'll ask.

Decision trees with more than one branch. If your SOP has nested conditionals, it's two SOPs pretending to be one. Split it.

Embedded screenshots of the tool UI. Screenshots rot faster than the process they document. Salesforce changes a button color and your SOP looks like it was written by someone who hasn't logged in this year. Use a Loom instead. More on that next.

"Pro tips" and "watch-outs" boxes. If it's important enough to call out, it's a step. If it's not a step, it's noise.

The success-criteria field is the one most ops managers skip, and it's the one that matters most. "Run the monthly close" is not a process. "Run the monthly close such that all bank reconciliations show zero variance and the GL is locked by the 5th business day" is a process. The criteria is what tells you whether the process worked. Without it, you can't tell when the SOP is broken.

Loom-First Documentation: 5 Minutes Beats 8 Pages

Here's the order I write SOPs in now, and it's the opposite of what I used to do:

  1. Record a Loom of myself running the process end to end. Five to eight minutes.
  2. Watch it back at 1.5x. Note where I pause, where I skip a step, where I correct myself.
  3. Write the 1-page SOP from those notes.
  4. Embed the Loom at the top of the doc.

The Loom is the source of truth. The 1-pager is the index. That sounds backwards because we've been trained to think of written docs as authoritative, but the math is simple: a five-minute walkthrough gets watched. An eight-page doc gets skimmed for the heading the reader thinks they need, then closed.

Watch counts back this up. On the last team I ran, our top-ten SOPs by Loom views averaged 14 plays per quarter. The same SOPs, as Notion docs, averaged 3 page-views and 22 seconds of dwell time. People watched the video, did the work, didn't open the doc.

A few rules I follow for the Loom:

  • Start with the trigger. "I'm doing this because a vendor renewal landed in my inbox." Not "Hi everyone, today we're going to talk about..."
  • Show your screen, not your face. Webcam burns time and attention. The work is on the screen.
  • Narrate decisions, not clicks. "I'm flagging this for legal because the auto-renewal clause is over 30 days." Not "I'm clicking the comments button now."
  • Re-record at 6 minutes. If you went over, you skipped a planning step. Try again.
  • Re-record on every process change. Don't edit the old Loom. Record a new one and replace the embed. The old version stays in your Loom library as historical record.

The Loom-first approach also fixes a thing nobody talks about: the writer's curse. When you write an SOP first, you describe the process you think happens. When you record it first, you document the process that actually happens. Those are almost never the same document. The Loom forces honesty.

The 90-Day Review Cadence

Every SOP in my library has two date fields: last_reviewed and next_review. The next review is always 90 days out. Not "annually." Not "as needed." Ninety days, on the calendar, with a notification.

At the 90-day mark, the named owner does one of three things:

  1. Re-runs the process. Actually executes it. Catches drift in real time.
  2. Confirms no changes. Bumps last_reviewed to today. Pushes next_review out 90 days. Done in two minutes.
  3. Edits the doc and re-records the Loom. Takes 30 minutes. Worth it.

The rule that makes this work: miss two review cycles and the doc gets archived, not "updated later." Six months without an owner touching it is a strong signal nobody needs it. If they do need it, archiving it triggers a Slack message from someone, and now you know who actually uses it. Reinstate, reassign, set a 90-day review.

I keep the audit query as a saved view in Notion. Three columns: SOP name, owner, days since last review. Sort descending. Anything over 180 days is on the chopping block. I run this at the end of every quarter, archive the dead ones, and email the team a one-line note: "Archived 9 SOPs this week. If you reach for one and it's gone, ping me."

In two years of running this cadence, I've had exactly four "ping me" responses. Of those, two were people looking for a doc that had been replaced by a newer one (I redirected them). Two were genuine archive mistakes (I reinstated). Forty-something docs disappeared without a single complaint.

That ratio tells you everything about how many of your SOPs are doing real work.

The "Ghost SOP" Diagnostic

A ghost SOP is a doc that exists in your workspace but doesn't exist in the team's daily reality. They're the largest category in most ops libraries, and the audit to find them takes about an hour.

Three tells, any of which is enough:

Orphaned owner. The owner field names someone who left the company, moved teams, or never confirmed they owned it. If you can't tag a current employee in the doc, it's a ghost.

Last edit older than 180 days. Half a year without a touch, on a process that's supposedly "live." Either the process hasn't changed (rare, in my experience) or nobody's been checking. Either way, the doc isn't being maintained.

Zero inbound links and zero recent views. If no other doc, no onboarding checklist, and no Slack message in the last 90 days links to this SOP, it's not in any workflow. It exists in isolation. It's a ghost.

The fastest version of the audit is a verbal one. Pick three people on the team. Ask each of them: "If you needed to do X right now, where would you look?" If they name the SOP, it's alive. If they say "I'd ask Jamie," the doc is dead and Jamie is the actual SOP. Replace the doc with a Loom from Jamie before Jamie quits.

I once ran this on a 47-doc workspace. Twenty-eight failed all three tells. Three more failed two of three. I archived 31 docs in a single afternoon. The team moved faster the next month, not slower, because the search results were no longer cluttered with ghost matches.

Template vs. Custom: When to Reuse, When to Write Fresh

Not every process deserves a custom SOP. Some processes are commodity, and writing a fresh doc for them is its own form of waste.

Use a template for:

  • Onboarding checklists. New-hire IT setup, software access requests, day-one walkthroughs. The pattern is identical across roles, only the access list changes.
  • Vendor reviews. Renewal date, contract value, owner, last performance check, cancellation deadline. Five fields, every vendor.
  • Incident response. Severity tiers, on-call rotation, escalation timing, post-mortem template. The frame is reusable; the incident detail goes in the post-mortem.
  • Monthly close. Same accounts, same reconciliations, same lock date. Fill in the variances.

Write fresh for:

  • Anything cross-functional. A process that touches Sales, Finance, and Legal has handoffs that are unique to your company's reporting structure. A template will hide the friction points that matter.
  • Anything with a real handoff. "Sales hands deal to Onboarding." Where does the data live? Who pings whom? What's the SLA on the response? Templates don't know your tools.
  • Anything that touches revenue. Quote-to-cash, contract approvals, deal-desk review. The cost of a generic SOP that misses your approval matrix is days of rework. Custom every time.

The shorthand I use: if I can imagine the same SOP working at three different companies with minimal edits, template it. If the process is shaped by your specific tech stack, your specific team structure, or your specific revenue model, write it fresh.

A practical note: template SOPs go in a _templates folder. When someone needs an onboarding checklist for a new role, they duplicate the template and customize the role-specific fields. The template itself is read-only. This stops the slow drift where every team's onboarding SOP becomes a slightly different snowflake over 18 months.

Ownership Rules: One Human, Never "The Team"

"The ops team owns this" means nobody owns this. I've seen the same pattern at every company: a doc lists a team as the owner, the team rotates, the doc rots, and at the 12-month mark the doc says one thing and the process does another.

The rule is: one named human per SOP, no exceptions. First name and last name in the owner field. If they leave the company, the SOP is reassigned in the same offboarding ticket that revokes their access. No SOP without a current owner gets merged into the workspace. If you're reviewing a new doc and the owner field says "Operations" or "TBD," send it back.

This sounds bureaucratic. It isn't. It's the single rule that creates accountability. The named owner is the person who:

  • Re-runs the process every 90 days.
  • Re-records the Loom when something changes.
  • Gets the Slack ping when it breaks.
  • Approves edits from anyone else.

When ownership is shared, none of that happens. When it's named, all of it happens, because the owner's name is on the doc and nobody wants to be the person whose SOP failed in production.

A pattern I use to make this stick: in the team's quarterly review, every named owner gets a list of their SOPs and their review dates. It takes me about ten minutes to generate. The list is public. Nobody wants to be the one with three overdue reviews. Within two quarters, the overdue rate dropped from 40% to under 10% on the team I ran this on, with zero process changes other than the visibility.

A second pattern, for big SOPs that genuinely span people: name a primary owner and a backup. The primary does the 90-day review. The backup is who you ping if the primary is on PTO or in a meeting. Two names. Not five. Not "the team."

If you only take one rule from this playbook, take this one. The 1-page format is helpful. The Loom-first approach is helpful. The 90-day cadence is helpful. None of them work without a named owner who knows the SOP is theirs.

What This Looks Like in Practice

Three months after I started running this on the last team, the workspace went from 47 SOPs to 19. Loom views per SOP tripled. The "where do I find the doc for X" Slack messages dropped to roughly one a week, from a baseline of five or six a day. Two new hires onboarded in their first month using only the Looms and the 1-pagers, with no shadow-walkthroughs from senior team members.

The work isn't writing more docs. The work is maintaining fewer, better ones, with one named human on each, reviewed every 90 days, and archived without ceremony when they go quiet. Most ops teams are over-documented and under-maintained. Flip the ratio.

Learn More