Most clinics I walk into have SOPs. They're in a binder on a shelf, or a Google Doc nobody opens, or worse, in the head of the one MA who's been there seven years. The SOPs exist. The problem is nobody follows them, and the owner has stopped pretending to enforce them.

If you run a compounding or concierge practice, this gap is expensive. It shows up as inconsistent intake, refill requests that take four days instead of four hours, new hires who take three months to ramp, and the constant low-grade anxiety that something important is going to fall through a crack. You can't fix that with a better binder. You fix it by treating SOPs as operational infrastructure: small, specific, embedded in the tools your staff already use, and revised on a schedule.

Here is how I'd build (or rebuild) that system from scratch.

Start with the work, not the document

The first mistake is opening a Word doc. Don't. Open your schedule and your inbox instead. Look at what actually happens in a day at your clinic.

Sit at the front desk for two hours. Shadow your lead MA through a full patient flow. Read the last 50 messages in your patient portal. You are looking for two things: the steps that get done well because someone good is doing them, and the steps that vary depending on who is on shift. The second category is where your SOPs need to live.

In practice, the highest-leverage SOPs in a compounding or concierge clinic are almost always the same five or six processes:

  • New patient intake and chart preparation
  • Refill requests and prescription transfers to the compounding pharmacy
  • Lab ordering, result review, and patient notification
  • Membership onboarding and renewal communication
  • Inbound message triage (portal, phone, email)
  • Visit documentation and charge capture

If those six are tight, your clinic runs. If any one of them is improvisational, you're paying for it somewhere, usually in clinician time.

Write SOPs the way people actually read them

A good SOP is not a policy document. It's a checklist with just enough context that a competent new hire can execute it without asking questions, and a veteran can scan it in 20 seconds to confirm they didn't skip a step.

The structure I use for every SOP is the same:

  • Trigger. What event starts this process? "Patient submits intake form" or "Pharmacy sends refill confirmation."
  • Owner. Which role is responsible. Not a person's name. A role.
  • Steps. Numbered, verb-first, one action per line. If a step needs a sub-decision, put it inline as an if/then.
  • Done condition. How you know the process is complete and what the final artifact is (chart note signed, task closed, message sent).
  • Escalation. What to do when something doesn't fit. Who to ping. How fast.

That's it. No mission statement. No paragraph about why this matters. If a step needs justification, put one sentence in parentheses after it. Otherwise trust your staff to execute.

A useful test: hand the draft to someone who has never done the task, and ask them to do it from the SOP alone. If they have to ask a clarifying question, the SOP is incomplete. Fix it before you publish.

Put the SOP where the work happens

This is the part most clinics miss, and it's the difference between SOPs that get followed and SOPs that get ignored.

A document in a shared drive will not be used in the middle of a busy Tuesday. Your MA is not going to alt-tab out of the chart, find a folder, open a PDF, and read step seven while the phone is ringing. They are going to do what they remember, which is whatever they did last time, which may or may not be right.

The SOP has to live inside the workflow. That means templates in the EMR, structured intake forms that enforce required fields, message macros that pre-fill the right language for common scenarios, and task templates that auto-create the right sequence of to-dos when a trigger fires. When the "SOP" is just how the software behaves, compliance approaches 100% without you having to police it.

This is the entire reason we built Qintara the way we did. If you're spending real money on staff to manually translate SOPs into clicks, you're paying twice: once for the process, once for the policing of the process. Configure the system so the right path is the easy path.

Train against the SOP, not around it

When you onboard a new hire, the SOPs are the curriculum. Not a separate training deck. Not the institutional knowledge of whoever is sitting next to them. The SOPs themselves.

Day one, they read the SOPs for their role. Day two, they shadow a senior staff member doing those exact processes and mark up the SOPs with any gaps they notice. Day three, they do the work with someone watching and the SOP open. By the end of week one, they should be able to execute every SOP in their role unsupervised, and they should have flagged at least three things in the documents that were unclear or wrong. That last part is important. New hires are the best SOP auditors you have, because they don't yet know what to assume.

Build the expectation that SOPs change. Tell every new hire: "If you find a step that doesn't match reality, your job is to tell us, and we'll fix the document." This is how you keep the system alive instead of letting it calcify.

Review on a calendar, not a crisis

SOPs decay. Vendors change, the pharmacy adds a new portal, you start offering a new service line, a regulation shifts. If you only update SOPs when something breaks, you're always behind.

Put a recurring quarterly review on the calendar. Each quarter, the owner of each SOP (the role, plus a named accountable person) reads it, runs through the actual workflow once, and either signs off or revises. Fifteen minutes per SOP. With six core SOPs and a handful of secondary ones, the whole review takes a couple of hours per quarter. That is a trivial investment for keeping your operating system current.

Keep a changelog at the bottom of each document. Date, what changed, who changed it. When a staff member asks why something is different from last month, the answer is in the document.

What "actually followed" looks like

You'll know your SOPs are working when three things happen. New hires reach productive output in weeks, not months. The same task done by three different staff members produces the same artifact. And when you're out of the office for a week, nothing important gets dropped, because the work isn't held together by your presence.

If you want to see what this looks like with the EMR and AI agents doing the heavy lifting on intake, refills, and message triage, talk to our team. We've built the system for the kind of clinic where SOPs need to actually run, not just exist.

Frequently Asked Questions

How many SOPs should a small practice have?

Fewer than you think. Six to ten well-maintained SOPs covering your highest-volume processes will do more than fifty mediocre ones. Start with the workflows that touch every patient and every revenue dollar, and resist the urge to document edge cases until the core is solid.

Who should own SOP creation in the clinic?

The person who does the work writes the first draft. The practice manager or operations lead edits for clarity and consistency. The owner approves and is accountable for review cadence. If the owner writes everything themselves, the SOPs will reflect how the owner thinks the work happens, not how it actually happens.

How do we handle SOPs that touch compliance areas like HIPAA or state pharmacy rules?

Write the operational SOP the same way you'd write any other, then have your compliance counsel review the specific steps that intersect with regulation. Don't try to embed the entire regulation into the SOP. Reference the policy document, capture the operational steps, and confirm specifics with your own counsel before publishing.

Should SOPs live in our EMR or in a separate knowledge base?

Both, with the EMR doing the enforcement and the knowledge base holding the readable version. The EMR templates, forms, and task chains are where compliance happens automatically. The knowledge base is where staff go when they need to understand the why, or when they're onboarding. If you can only do one, put the workflow inside the EMR.

How do we get veteran staff to follow new SOPs?

Involve them in writing the document. Veterans resist SOPs that feel like they were imposed by someone who doesn't understand the work. When the SOP captures the way the best person on your team already does the task, adoption follows. Then make the SOP path the path of least resistance in the software, and the question stops being about compliance and becomes about which tool to click.