Why SOPs fail in multisite healthcare (and what actually works).

Most SOPs fail for the same reason: they are written from memory by someone trying to recall what they do, which means they are partial, idealized, and out of date the day they are finished. A different starting point produces documentation that actually gets used.

The pattern almost every multisite SOP project follows

A multi-location group decides it needs SOPs. The board is not asking for them. A regulator is not asking for them. The real reason is almost always one of three things: onboarding and training are inconsistent across sites, leadership cannot hold people accountable to a standard that does not exist on paper, or the patient and team experience varies depending on which site you walk into. A project gets kicked off. Templates get circulated. A few enthusiastic managers write the first batch. Momentum stalls. The SharePoint folder fills up with documents in three different formats. Six months in, leadership realizes most of the SOPs are not being used by the people they were written for.

The diagnosis is not effort. The diagnosis is the method. SOPs written from memory have three predictable failure modes.

The three failure modes of memory-based SOPs

1. They describe the idealized version of the work

When you ask a manager to write down "how we do check-in," they describe how check-in is supposed to happen on a calm Tuesday. Not how it happens on the Monday morning after a holiday weekend with two staff members out. The SOP becomes a textbook description that does not match the texture of the actual work. New employees read it, try to follow it, hit the first real-world variation, and quietly learn to ignore the document.

2. They are missing the parts the writer forgot were parts

Experienced operators have whole categories of behavior they no longer notice they are doing. The look at the schedule before walking up to the front desk. The check on a piece of equipment that is known to drift. The mental call about which patient gets seated first. Those judgment moves are exactly what the new hire needs to learn. They are also exactly what does not make it into a memory-based SOP.

3. They are out of date the day they are finished

Healthcare workflows shift. A new payer rule lands. The PMS gets an update. A new team member changes how a hand-off works. SOPs written from memory have no relationship to the actual work, which means they do not update when the work updates. The document quietly drifts out of sync, and a year later the SOP is referenced only when someone gets in trouble.

A different starting point

The fix is not better templates or more training for the SOP writer. The fix is starting from a recording of the actual work, then turning that into documentation.

The shape of the work:

1. Record how the work actually happens

Screen recordings for digital workflows. Short observation sessions for physical ones. Recorded conversations with the operator narrating what they are doing and why as they do it. The point is to capture the work in its real texture, including the judgment moves and the recoveries when something does not go to plan.

2. Extract the SOP from the recording, not from a meeting

The first draft gets built from the recording. The operator is reviewing and editing what they actually did, which is a completely different cognitive task than recalling what they do. They catch their own assumptions. They flag the steps that vary by situation. They notice the parts they would have left out.

3. Turn it into the artifact people will actually use

Different audiences need different formats. New hires need a job aid with screenshots and decision points. Coaches need a process map they can refer to in real time. Auditors need a structured SOP document. Leadership needs a one-page summary. From a single recording you can produce all of those without rewriting the underlying work.

4. Build the update loop into the document

Every SOP gets a named owner and a review cadence. Quarterly for high-volume operational SOPs, semi-annual for stable clinical workflows, immediate when a regulatory or system change forces a rewrite. Owners get a calendar prompt. The SOP either gets updated or gets retired. Documents do not drift in silence.

Why this works in multisite specifically

Multi-location groups have a problem single-location groups do not: variability across sites. Two locations doing "the same" workflow are almost never actually doing the same workflow. When you record at three sites, you see what is genuinely standard, what is reasonable local variation, and what is drift that needs to be brought into line.

That distinction matters. Standardizing reasonable local variation breaks site-level performance. Tolerating drift creates compliance and quality risk. A recording-based approach makes the difference visible, which makes the leadership conversation about standardization productive instead of theoretical.

What good looks like at the end

Three properties:

• The documentation matches the work. When a new hire follows it, they can do the job. When an experienced operator reads it, they recognize it.
• The artifact fits the audience. Front-desk staff get job aids. Managers get process maps. Auditors get structured SOPs. Leadership gets the summary.
• The document has an owner and an update path. Six months later, the SOP is current. A year later, it is still current.

Where I come in

The documentation work I do with multi-location healthcare and dental groups starts from recordings of how the work actually happens, not from a templates exercise. The output is the set of artifacts each audience actually uses, with a named owner and a review cadence so the work stays current.

If your group has a documentation project that has stalled, or one you have been delaying because the last attempt did not stick, a 30-minute call is the fastest way to figure out the right next step. Start the conversation, or read more about how engagements are structured.