Should a Multi-Site Physician Group Automate Scheduling or Standardise Its Templates First?

The answer you already got, and why it is the wrong one

You run four sites, maybe nine. Each one books its own providers. The phones are bad, the front desks are tired, and a vendor has just shown you a demo where a patient books herself in forty seconds and a bot fills the cancellation before the coffee is cold. You asked the reasonable question: do we roll this out now, or do we clean up the schedules first?

Every answer you will find says clean up first. Standardise the templates, then automate. That advice is written by the people who sell template standardisation as a service, or the scheduling engine that runs on top of it. The advice and the invoice point the same way.

We sit on the other side of that table, and our read is different. Templates are not the unit of standardisation. Appointment types are. A group that standardises its grids and leaves its appointment types alone has done the visible half of the work and skipped the half that decides whether any automation will hold.

Templates are the grid. Appointment types are the meaning

A template is a provider's week: which hours are open, how long each slot is, which blocks are held for urgent visits or procedures. Standardising templates means every site uses the same slot increments, the same block colours, the same naming for a Tuesday afternoon clinic. It is real work and it is worth doing. MGMA's write-up of Penn Medicine Lancaster General Health's scheduling overhaul lists "complexity and frustration with template management" and protocols living in "paper notes and Excel sheets" as the pain points that started the project, and that description will sound familiar to any multi-site administrator.

But a template only says when. An appointment type says what. New patient visit, established follow-up, annual wellness, post-op check, nurse visit, procedure. Each type carries a duration, a set of scheduling rules, a preparation requirement, and a link to billing. The scheduling engine reads the appointment type to decide which slots are eligible, how much time to hold, and what to tell the patient. The template is the shelf. The appointment type is the thing on it.

Here is the problem we see in almost every group past its second site. Two locations run identical grids, every slot twenty minutes, every block colour matching the corporate standard, and one site defines a new patient visit as forty minutes with intake paperwork while the other defines it as twenty minutes because their nurse does intake by phone the day before. Both are called "New Patient" in the system. Both sit on the same template. Both produce completely different books.

No scheduling engine reconciles that. It cannot. It reads the type and the type says two things at once.

The definition problem underneath the definition problem

It gets worse than duration, because the words themselves disagree.

CPT is unambiguous about what a new patient is: someone who has not received professional services from a physician of the same specialty in the same group practice within the past three years. That definition drives the 99202 to 99205 codes, which reimburse higher than the established-patient series because they carry more work. The coding side of your organisation lives by it.

The scheduling side usually does not. Ask a front desk at site A what makes a patient "new" and you will hear "new to this office" or "new to this doctor." Site B will say "never been seen by the group." Site C has a "new to provider" type that nobody at site A has heard of. Each of those is defensible from inside the building. None of them is the coding definition, and every mismatch between what scheduling calls the visit and what billing calls it becomes a slot that was either too short for the work or too long for the reimbursement.

The three-year rule is a good example of why this matters when you automate. A self-scheduling tool has to decide, at the moment a patient clicks, whether to offer them a new-patient slot or an established one. It can only do that if the appointment type it is offering means the same thing at every site the patient might pick. If it does not, the tool will do exactly what it was configured to do, which is to encode the disagreement and serve it to patients at scale.

The test that tells you where you are

We use one question to find out whether a group is ready to automate, and it has nothing to do with software.

Could a scheduler at site A staff site B's book for a day without asking anyone a question?

Not "could they log in." Could they look at a request for a follow-up visit with a specific provider and know, from the appointment type alone, how long to hold, whether the patient needs labs first, and whether that provider even sees that visit type on that day. If the honest answer is "they would need to ask Denise," then Denise is your scheduling system. The software is a front end on top of her.

That is the state most groups are in when they buy. The automation vendor's implementation team will discover it in week three, build a rules layer to paper over it site by site, and hand you a system that works until Denise retires or a fifth site opens. The bill for that rules layer is real, and it is rarely in the quote.

What your own data already shows

You do not need a consultant to see whether this is your problem. The diagnostic sits in reports most practice management systems can produce today, and we would rather you run it before a vendor does.

Three things to pull, per site:

• The count of active appointment types. Two sites doing the same specialty work should have the same list. If one has thirty-one types and the other has fifty-four, the extra twenty-three are either local inventions or the same visit under a different name. One pediatric network reported retiring almost a third of its templates once it audited slot logic and naming, and the appointment type list is usually messier than the templates.
• Slot length variance for the same code. Take your highest-volume E/M codes and look at the scheduled duration behind each one, by site. A 99213 that is booked at fifteen minutes in one office and thirty in another is not a provider preference. It is a definitional gap dressed as one.
• The share of visits overbooked or bumped. When the type does not match the work, staff compensate. They double-book to hit volume, or they bump the visit that turned out to need more time. Both show up in the data as noise. Sorted by site and by appointment type, the noise clusters around the types that are defined differently.

We cannot give you a benchmark for template drift across sites, because nobody has published one, and we would rather say so than quote a number we made up. What we can tell you is that in every multi-site group we have looked at, the variance was concentrated in a handful of types, and those types were always the ones that carried the most revenue or the most clinical risk. New patient. Procedure. Post-op. The everyday nurse visit is fine everywhere.

Why the vendor is happy either way

If you standardise first and buy their tool second, the vendor gets a cleaner implementation and a reference customer. If you buy first and standardise inside the tool, the vendor gets a longer implementation, a rules engine contract, and a customer who cannot leave because the definitions now live in their product. Both outcomes are good for the vendor. Only one is good for you, and it is the one where the definitions live in a document your group owns and could hand to any system.

This is the same pattern we described for hotel groups running one property management system six different ways, and for retailers whose siloed systems cost the back office more than the customer. The software is rarely the problem. The disagreement encoded in it is.

So which one first, honestly

Neither of the two options you were offered, because the choice was framed wrong.

Do not standardise templates first as a project. Grids follow definitions, and a grid standardised around undefined types will drift back within a quarter. And do not automate first hoping the tool will force consistency. It will force consistency on the patient-facing surface while the definitions underneath keep diverging, which is the worst of both, because now the disagreement is invisible.

Standardise the appointment types first. The list, the duration, the rules, and the mapping to billing, agreed across sites and owned by operations rather than by any one office. It is a shorter project than template standardisation and a much less glamorous one, which is why nobody sells it. Then let templates follow, because a template built on agreed types mostly standardises itself. Then automate, and expect the implementation to go quickly, because the vendor's rules engine will finally have something to read.

The order matters more than the speed. MGMA's December 2025 poll of practice leaders found no-shows and online scheduling tied at the top of the 2026 access priority list, and a separate July 2025 poll found that seven in ten groups had fewer than one patient in four using digital tools to book. The pressure to automate is real and it is going to grow. Groups that automate on top of disagreement will spend the next two years discovering the disagreement one patient complaint at a time.

We should probably note that the appointment type work sounds like a filing exercise, and it is. It is also the only filing exercise we know of that can save a scheduling rollout. Call it a case of the type being mightier than the sword.

If you are weighing a scheduling platform across several sites and cannot say with confidence that every location means the same thing by "new patient," that is exactly the question we help groups answer before they sign. The consult starts with the three reports above, and it usually ends with a shorter vendor list than the one you walked in with.