Content SOPs That Survive When Your Writer Quits

Here is a pattern that shows up again and again: a business builds a steady content program, the person running it leaves, and within two months publishing stalls, the voice drifts, and nobody can remember why certain decisions were made. The writer or marketing lead who left wasn't just producing articles. They were carrying the whole operation in their head — the keyword list, the review steps, the login for the CMS, the reason you stopped targeting one topic and started targeting another.

That institutional knowledge walks out the door unless you've written it down. This piece is about what to document, how to structure it so people actually use it, and the handful of SOPs that matter most when someone new has to pick up the work cold.

What breaks first when a content person leaves

It's rarely the writing itself. Writing is the most replaceable part. What breaks is everything around the writing — the connective tissue that only exists in one person's habits.

In the first few weeks after a departure, the predictable failures are: publishing cadence collapses because nobody owns the calendar; article quality gets inconsistent because the informal review step is gone; the new person retargets keywords you already ranked for, or rewrites pages you deliberately left alone; and internal links stop getting added because nobody knew that was part of the job.

None of those are talent problems. They're documentation problems. A competent replacement can do the work — they just can't read the departed person's mind.

The five SOPs worth writing before anything else

You don't need a 60-page operations manual. You need five documents that cover the decisions and steps that repeat. If you only ever write these, you've covered most of what gets lost in turnover.

1. Topic selection SOP. How you decide what to write next. What keyword tool or method you use, how you check that a topic isn't already covered, and who approves the list. Include the actual spreadsheet or doc where the approved queue lives.
2. Article production SOP. The steps from assigned topic to finished draft — target word count, required sections, how you handle sourcing and claims, and the brief template a writer works from.
3. Voice and style guide. The rules that keep articles sounding like your business. Words you ban, the reading level you aim for, how you address the reader, whether you use first person.
4. Review and publish SOP. Who checks a draft, against what checklist, and the exact clicks to get it live — CMS steps, categories, tags, featured image rules, and the publish schedule.
5. Internal linking SOP. How new articles connect to old ones, and how old ones get updated to point at new ones. This is the first task people skip and the hardest to reconstruct later.

Everything else — social promotion, newsletter repurposing, reporting — is secondary. Get these five down first.

How do you document an SOP so people actually follow it?

Write it as a numbered sequence of actions a specific role performs, not as a description of the process in the abstract. The difference matters. "Articles should be reviewed for quality before publishing" is a description — it tells a new person nothing about what to actually do. "The editor opens the draft, runs it against the 8-point checklist below, leaves comments for each failed item, and marks the status 'Ready' when all eight pass" is an SOP someone can follow on day one.

A few rules that make SOPs stick:

• One task, one document. Don't bundle topic selection and publishing into a single wall of text. Separate files are easier to find and update.
• Name the tool and show the path. Write "log into WordPress at yoursite.com/wp-admin, go to Posts > Add New" — not "publish in the CMS."
• Include the artifacts. Link the actual brief template, the checklist, the keyword spreadsheet. An SOP that references a document nobody can find is half an SOP.
• Date it and name an owner. Put "Last updated" and "Owned by [role]" at the top. Stale SOPs are worse than none because people follow them into a wall.
• Write for someone who has never done the job. If your SOP assumes knowledge the reader has, it fails exactly when you need it — during a handover.

A worked example: the review and publish checklist

Suppose a dental practice publishes two articles a month. Their review SOP might read like this:

1. Writer marks the draft "Needs Review" in the content tracker.
2. Reviewer confirms the article answers the target question in the first two sentences.
3. Reviewer checks every clinical claim is phrased carefully and avoids guaranteeing outcomes.
4. Reviewer confirms the article links to at least two existing pages and one service page.
5. Reviewer checks the title tag is under 60 characters and the meta description is filled in.
6. Reviewer confirms the H2s match how patients actually phrase questions.
7. Reviewer sets the category, adds tags, and schedules the post for the next open slot on the calendar.
8. Reviewer marks the tracker row "Published" with the live URL.

Any competent person can run that checklist without having met the previous editor. That is the whole point.

Where should SOPs live, and who keeps them current?

SOPs should live in one shared, searchable location that isn't tied to any individual's personal account — a shared drive folder, a wiki, or a Notion workspace owned by the business, not a document sitting in one employee's personal files. The most common failure isn't writing bad SOPs; it's writing good ones that disappear when the author's login is deactivated.

Ownership needs to be a named role, not a vague team responsibility. Assign each SOP to whoever performs it most, and set a recurring calendar reminder — quarterly is reasonable — to read through it and fix anything that changed. When you switch CMS, change your keyword process, or adjust your cadence, updating the relevant SOP is part of making that change, not an afterthought.

One practical tactic: the next time you onboard anyone to a content task, have them follow the SOP without help and note every point where they get stuck. Those stuck points are the gaps. Fix them immediately while the confusion is fresh.

A 30-minute weekly habit that builds documentation for free

Most businesses never write SOPs because it feels like a big project. It doesn't have to be. Block 30 minutes a week and document one task you did that week while the steps are fresh. In ten weeks you'll have ten SOPs covering the bulk of your operation.

Do it in the order you'd miss things if someone quit tomorrow:

• Week 1: how you publish an article (every click).
• Week 2: how you pick the next topic.
• Week 3: your voice and banned-words list.
• Week 4: your article brief template.
• Week 5: your internal linking rules.
• Weeks 6–10: reporting, promotion, image handling, and the odd recurring tasks specific to your business.

This also surfaces something useful: tasks that are weirdly complicated or depend entirely on one person usually indicate a process worth simplifying, not just documenting.

Some businesses solve the turnover problem by running content through an outside program instead of a single in-house hire, so the process and the archive live outside any one person's head — that's part of why clients use services like ClearPath Content. But the principle holds whether the work is in-house or outsourced: the program has to survive the person.

The takeaway: turnover is inevitable; losing your content operation to it is not. Pick the five SOPs above, write them as numbered steps a stranger could follow, store them somewhere the business owns, and spend 30 minutes a week building the set. When your content person leaves — and eventually one will — the program keeps running.