A process that only exists in one person’s head isn’t a process. It’s a bottleneck. Most content teams have several of these: the way a specific person handles internal linking, the informal checklist someone runs before publishing, the review sequence that changes depending on who’s free that week. None of it is written down, which means none of it survives that person going on leave, changing roles, or leaving the company.
Turning it into an SOP isn’t about bureaucracy. It’s about making the good parts of how your team already works survive without any one person holding it in memory.
The real problem: undocumented workflows don’t scale
Most content teams run into this constantly: every writer works differently, not because anyone decided that was fine, but because nothing was ever written down to standardize against. New hires take weeks to ramp up because there’s no reference document, only a series of Slack messages and half-remembered conventions. When someone leaves, their specific way of doing things leaves with them.
Undocumented processes carry a real cost: B2B organizations waste hundreds of millions of dollars each year on inefficient content processes, and most of that waste traces back to workflows that were never written down. The instinct is often to solve this by adding more review cycles: a senior editor catches the inconsistency after the fact. That’s a patch, not a fix. It treats the symptom every time instead of documenting the standard once.
The framework: the SOP Conversion Decision Tree
Not every process deserves a full SOP. Use this decision tree before documenting anything:
- Does more than one person do this task? If no, it’s personal preference, not a team process. Skip documentation for now.
- Does it happen more than once a month? If no, a lightweight checklist is enough; a full SOP is overkill.
- Does getting it wrong cause rework, delays, or quality issues? If yes to both 1 and 2, and yes here, this is a documentation priority.
For anything that clears all three, write the SOP in this structure: Purpose (one sentence: why this exists), Trigger (what starts this process), Steps (numbered, each with an owner), Quality Gate (what “done correctly” looks like, not just “done”), Exceptions (the two or three situations where the standard steps don’t apply, and what to do instead).
Keep it to one page. An SOP that’s three pages long won’t get read during a busy week. It’ll get skipped, which defeats the purpose. If the process genuinely needs more depth, split it into a short SOP plus a linked reference doc for edge cases.
How it holds up in practice
SOPs decay if nobody owns updating them. Assign one person per SOP as the owner, responsible for a quarterly five-minute check: does this still match how we actually work? If reality has drifted from the document, either the document needs an update or the team needs to be reminded why the documented way exists.
They also fail when they’re written by someone who doesn’t actually do the task. An SOP written by a manager without input from the person who runs the process daily usually misses the real judgment calls. Draft SOPs with the person doing the work, not just for them.
Who this is for
Any content team with more than two people touching the same workflow: writers, editors, freelancers, or agencies. If you’re a team of one, you don’t need SOPs yet; you need a personal checklist, which is a lighter-weight version of the same idea.
Common mistakes
Teams often try to document everything at once, producing a pile of SOPs nobody has time to read or maintain. Others write SOPs that are really just to-do lists with no owner assigned per step, so accountability is unclear. The most damaging mistake is writing the SOP once and never revisiting it. Six months later it no longer matches reality, and the team quietly stops trusting the documentation altogether.
FAQ
What’s the difference between an SOP and a playbook?
An SOP documents one specific repeatable task. A playbook usually bundles several related SOPs into a broader strategy for a goal, like “launching a new content pillar.”
How long should an SOP take to write?
Most single-page SOPs take 30 to 45 minutes to draft once you’ve talked through the process with whoever runs it.
Should SOPs live in Notion, Google Docs, or somewhere else?
Wherever your team already looks for reference material daily. A perfectly formatted SOP nobody can find is worthless.
Who should own SOP maintenance?
Whoever is closest to running the process day-to-day, not necessarily the content manager. Ownership should sit with the practitioner.
Do freelancers need access to SOPs?
Yes, especially onboarding SOPs. This is one of the fastest ways to cut ramp-up time for new freelance writers.
How do I know if an SOP is actually being followed?
Spot-check outputs against the quality gate step periodically, rather than assuming documentation equals compliance.
Next step
Pick one process this week that more than one person touches and run it through the Decision Tree above. If it qualifies, write the one-page SOP using the Purpose, Trigger, Steps, Quality Gate, and Exceptions structure. A strong first candidate is the process behind your content brief template, since more than one person already uses it and it already causes rework when skipped. Once that’s documented, apply the same treatment to reporting workflows like content-to-MQL attribution, which tend to live in one person’s head longer than they should.
What would you add to this framework?