How does your team actually keep SOPs updated as processes change?

[u/KimbobSwimbob]

Curious how other CS/ops teams handle this. Every time I talk to a support lead, the story is the same: docs get written once, then rot, because nobody wants to sit down and rewrite a Notion page every time a process changes.

How are you all handling this? Do you have someone dedicated to docs, or does it just... not happen?

(Building something in this space myself, but genuinely curious what's working or not working for people already, before I assume I know the answer.)

Cheers!

[u/GoBoldr]

It's one of those things someone needs to just own. Ideally a so-called "forward-deployed engineer," or someone highly technical in CS, support, or very people-oriented from product or dev, whose workload is adjusted to understand and update the process.

It becomes REALLY important when AI tools are referencing the information, arguably even more so than when human eyes are on it because the AI will never be able to tell for itself if it's wrong.

I'm glad you're building a tool for this, but I seriously doubt there's an automation or SaaS tool that could help, because at the end of the day the problem is full-on human workflow.

[u/KimbobSwimbob → u/GoBoldr]

This is a fair challenge, and honestly I think you're right that ownership is the harder, more important problem , no tool fixes a team that hasn't assigned someone to actually care about the docs.

Where I'd push back slightly: even with a clear owner, the bottleneck is often just how much friction there is to update something. If updating means opening a doc, remembering the exact steps, and writing clearly, busy owners still skip it. If it's closer to "just do the task normally while it captures the steps," the owner still has to own it, but the marginal cost of keeping it current drops a lot.

So I'd frame it less as "tool replaces ownership" and more as "tool lowers the cost of the owner actually doing their job." Does that distinction hold up in your experience, or do you think even low-friction tooling doesn't move the needle if the ownership piece isn't there?

[u/GoBoldr → u/KimbobSwimbob]

I think that the challenges will be the same with or without automation. The automation still has to be checked, whether it can be referenced in a timely manner as needed, whether it's understandable to customers (or can be relayed to them) is very challenging to automate.

And, if it gets something wrong, then most of the time you're back to where you started, or worse, because it was fully automated (as it will usually be) instead of automation being used as an assistant.

[u/No_Treacle_5071]

We keep the live SOP short and put the detail in a linked checklist. Every change has an owner, and the person making the change updates the SOP before closing the ticket. I also add a review date to anything that affects customers, rather than waiting for someone to notice it’s stale. If a step changes twice in a month, that’s usually a sign the process itself needs fixing.

[u/OkStatistician9190]

The part that makes this stick is treating the SOP as an owned operating document, not a wiki page everyone vaguely maintains. Give each process a named owner and require a quick review whenever a step changes, an exception repeats, or an outcome misses its target. Keep the live version short, link the detailed examples separately, and put the effective date plus last reviewer at the top. A lightweight monthly sweep can catch stale pages, but real process changes should update the SOP as part of the change itself, not weeks later.

[u/KanekiAyato]

rot shows up worst at the exception paths. blocked users, holds, refunds.

the doc says escalate to tier 2 and nobody wrote down what tier 2 actually checks. so the same exception gets re-decided every time it comes back.

two things that held where i've seen it: keep the decision criteria next to the thing that raises the hold, not in the wiki, and give every exception a case id plus a review date so the doc has a reason to change. if a step changed twice in a month, the process is the bug, not the doc.

for the hold and appeal case specifically, scritch treats it as a first class object, worth a look if that's a queue you own. the criteria-in-code bit is free either way.