Most therapy practices have more procedures than they have useful SOPs.
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.
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 tried to imagine every possible scenario.
When I'm evaluating an SOP, the practical test is whether someone can reasonably do the work from it.
Document Reality, Not Aspiration
One of the easiest mistakes to make is documenting the process you wish you had instead of the one your practice actually uses.
That's understandable. Writing down 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 and update the documentation.
I've found that this is one of the less obvious benefits of writing good SOPs: the documentation exposes problems in the operation itself. If a process takes 17 steps, documenting all 17 may make it obvious 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. It can show you where the process itself is unnecessarily complicated or fragile.
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 a lot of documentation systems quietly die. Someone creates the SOP, the practice has officially "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 and go back to asking each other.
Every important process needs an owner. That does not necessarily mean the practice owner. In many cases, the person closest to the work is better. They don'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 buried in an email, three copies in different folders, or the version somebody downloaded to their desktop. If employees have to figure out which SOP is the current SOP, you've created another problem for them to solve.
Don't Document Everything
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, so I would start with the places where failure is expensive, frequent, or dependent on one person.
A useful exercise is to ask 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 probably the SOPs you should start with.
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.
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 what someone actually needs to execute it correctly. Give the process an owner and put the current version somewhere everyone can find it.
Then see whether someone can use it without having to ask the person who already knows how.
If they can't, you don't have an SOP yet.