Most therapy practices have more procedures than they have useful SOPs.
The distinction matters.
Your practice already has a way of handling a new client inquiry. Someone knows what to do when a clinician calls out sick. Your admin knows how to fix an insurance problem, onboard a new therapist, process a cancellation, update the website, or respond when something unusual happens in the EHR.
The work gets done.
But ask where those processes are documented, and things get less clear.
Maybe there is a Google Drive folder called "SOPs." Maybe someone created an operations manual three years ago. Maybe there are instructions scattered across emails, Slack messages, old meeting notes, and documents with names like "NEW Intake Process FINAL v2."
Or maybe the real answer is simpler: Melanie knows how to do it.
That is not an SOP. That is a person remembering what to do.
And writing a 40-page operations manual probably won't fix it.
Most SOPs Are Written to Exist
Practice owners often approach documentation backward. We decide we should have SOPs, so we start documenting everything.
The result is usually a collection of long, formal documents that look impressive and slowly become obsolete.
They describe what is supposed to happen rather than what actually happens. They include obvious steps while missing the weird exceptions that cause problems. Nobody knows when they were last updated. New employees may read them during onboarding, but experienced employees rarely consult them because asking someone is faster.
Eventually the SOP becomes something the practice technically has rather than something the practice actually uses.
That distinction is important.
The purpose of an SOP is not documentation. The purpose is reliable execution.
If an employee can follow the process correctly without needing to find the person who usually does it, the SOP is doing its job. If the document exists but everyone still asks Melanie, you have documentation theater.
Start With the Work That Actually Happens
Useful SOPs are surprisingly concrete.
Imagine documenting your process for responding to new client inquiries.
A weak SOP might say:
Technically correct. Operationally useless.
The difficult part was never knowing that somebody should respond.
The difficult part is everything underneath it.
Which clinicians are actually accepting clients right now? Who takes the person's insurance? Who works with couples? Who sees teenagers? What happens when someone specifically requests the owner, but the owner is full? Can the admin recommend another clinician? What happens if the inquiry suggests a higher level of care? Where is the response recorded? Who follows up if the person never replies?
Those are the decisions that make the process work.
A good SOP captures enough of that reality that another competent person can execute the process without reconstructing it from scratch.
That doesn't mean every SOP needs to be enormous. Usually the opposite is true.
The best documentation I've built tends to get shorter as it gets better. Unnecessary explanation disappears. The decision points become clearer. Screenshots replace paragraphs where appropriate. Links point directly to the system being used. Exceptions are documented because they actually occur, not because someone imagined every possible scenario.
The test is simple: could someone reasonably do the work from this?
Document Reality, Not Aspiration
There is another reason SOPs fail in therapy practices: we write down the process we wish we had.
That is tempting because documenting a messy workflow forces you to look at it.
Maybe your admin really does check three different spreadsheets before assigning an inquiry. Maybe clinician availability really is being tracked through a combination of memory, SimplePractice, and messages from therapists. Maybe payroll requires a strange manual reconciliation every two weeks because two systems don't quite agree.
Writing the polished version doesn't make those problems disappear.
It just makes the SOP inaccurate.
Document what actually happens first. Then improve the process. Then update the documentation.
That order matters because an honest SOP exposes operational problems. If a process takes 17 steps, documenting all 17 may reveal that five of them should not exist. If a process depends on one employee remembering six exceptions, writing those exceptions down may reveal that the underlying system needs to change.
Documentation isn't just about transferring knowledge. Done correctly, it is a diagnostic tool.
You begin to see where the practice is unnecessarily complicated.
An SOP Needs an Owner
Even a good SOP eventually becomes wrong.
Your EHR changes. An insurance company changes its portal. You hire another clinician. A form moves. A policy changes. Someone discovers a better way to perform the task.
This is where most documentation systems quietly die.
Someone creates the SOP, everyone celebrates having documented the process, and nobody is responsible for it again.
Six months later, an employee follows the instructions and discovers that step four no longer works.
After that happens a few times, people stop trusting the documentation.
Once employees believe the SOPs might be outdated, they go back to asking each other.
The system has failed.
Every important process needs an owner. Not necessarily the practice owner — the person closest to the work is often better. That person doesn't need to obsessively review documentation every month. They simply need responsibility for keeping it accurate when the process changes and periodically confirming that it still reflects reality.
There should also be one obvious place where the current version lives. Not an attachment in an email. Not three copies in different folders. Not the version somebody downloaded to their desktop. One source of truth.
Don't Document Everything
This may be the most important part.
You do not need an SOP for everything your practice does.
Documentation itself has a maintenance cost. Every new process you document becomes another thing that can become outdated.
Start with the places where failure is expensive, frequent, or dependent on one person.
Ask yourself what would happen if your admin manager disappeared for two weeks tomorrow.
What would stop? What would everyone suddenly realize they don't know how to do? Where would money get stuck? Where would clients fall through the cracks? Which deadlines might get missed? Which tasks would require someone to text the person who is supposed to be on vacation?
Those are your SOPs.
Start there.
A therapy practice does not become operationally mature because it has a massive handbook. It becomes mature when important work can happen reliably without depending on the right person remembering the right thing at the right moment.
That is a much higher standard than having documentation.
It is also much more useful.
The next time you think, "We really need an SOP for this," don't start by opening a blank document. Watch how the work actually happens. Find the decisions, exceptions, dependencies, and failure points. Write down only what someone needs to execute it correctly. Give the process an owner. Put the current version somewhere everyone can find it.
Then see whether someone can actually use it.
If they can't, you don't have an SOP yet.