A Multi-Location Front Office Without Merging the Schedules

A multi-location front office is usually sold as a consolidation project. Merge the schedules, standardize the appointment types, put everyone on one template, then let one team answer for all of it. Orthopedic groups that grew by absorbing practices know how that goes. The sites do not want to merge, the surgeons have their own booking rules for good reasons, and the consolidation becomes an eighteen-month project that never quite finishes.

The problem it was meant to solve is real. Six locations means six phone numbers, six front desks, and a patient who calls the wrong one and gets told to call another one. Coverage is uneven. The site with two people at the desk drops calls every afternoon, and the site with four has staff sitting idle at the same hour.

What gets missed is that those are two different problems wearing one name. Answering as one practice is a routing and coverage problem. Booking correctly at each site is a configuration problem. Consolidation attacks the second so it can fix the first, which is why it costs so much and takes so long.

They can be separated. A single front office can answer every call for every site and book each one into that site’s own athenaOne department, against that site’s own appointment types, under that site’s own rules, without anybody merging anything.

One front door, six sets of rules behind it

The unit of configuration in athenaOne is the department, and for a group that grew by acquisition the departments are already the sites. That is the whole hinge.

A caller does not need to know which building they want. What has to happen is that the intent gets captured once, then matched against open availability across departments rather than inside one. Search booked and open time across multiple departments at once, offer the patient the two or three real options that exist anywhere in the group, and write the booking back into whichever department owns that slot.

Each site keeps its own provider group, its own scheduling templates, its own appointment types, and its own rules about who can be booked into what. Nothing about that has to change for the phone to behave as one practice.

The payoff is not tidiness. It is that a patient willing to drive twenty minutes gets offered the Thursday at the other site instead of the following Tuesday at their default one, and the group captures a visit it was previously turning into a callback.

The generic slot is where multi-site booking actually breaks

Here is the complication that makes this hard, and it gets worse with every site you add.

Most templates are carved with generic slots. An Any 15 or an Any 30 that the schedule returns when you search for a specific appointment type. That generic slot is not equally eligible for everything. A new-patient orthopedic visit may need forty-five minutes and a specific type; the Any 15 that came back cannot hold it. Which specific types a generic slot is genuinely eligible for, per provider and per department, is the entire mapping problem, and at six sites you have six versions of it.

It gets more brittle when a site changes its own catalog. One practice retired its whole procedure appointment-type catalog overnight and folded it into a single fifteen-minute follow-up type, which cannot hold a forty-five minute service. Nothing broke loudly. Bookings kept happening and were simply wrong.

So the automation has to hold the eligibility map per department and notice when it moves. When an appointment type disappears or a provider’s template changes shape, the system flags it: which site, which types, when. It does not decide what the new mapping should be. A human at that site does, and until they do, bookings against the affected types route to a person.

That handoff is the design. Detection scales across six locations. Judgment about what a site meant to do does not.

The phone work that is eating the most hours is not scheduling

Groups building a central front office usually staff it for booking, and then discover the queue is full of something else.

A March 10, 2026, MGMA Stat poll of 294 applicable responses asking practice leaders which phone tasks consume the most staff time put eligibility and prior authorization at 45%, ahead of scheduling at 31%, intake at 9%, and prescription refills at 6%. In an orthopedic group that ordering is if anything more pronounced, because so much of the schedule carries an authorization requirement behind it.

That changes what a central team is for. If the shared front office only answers and books, it absorbs the 31% and leaves the 45% at each site, which is the part that was actually drowning them.

The more useful build handles the verification and status work in the same pass: coverage checked against the department and appointment type before the slot is confirmed, authorization status chased as a case that lives in athenaOne, and the exceptions routed to the site’s own authorization staff with everything already attached.

Coverage is the number that justifies the project

Central coverage is worth building because it fixes the uneven hour rather than the average day.

Asked about their top patient access focus for 2026, 27% of 236 respondents in a December 9, 2025, MGMA Stat poll chose no-shows, ahead of online scheduling at 24% and phone access at 22%, with wait times at 21%. Phone access is a fifth of the attention and, for a multi-site specialty group, it is the one that varies most by location and by hour.

A single answering layer flattens that. The site whose two front-desk staff are both with patients at 3pm stops dropping calls, because the calls were never queued at that site to begin with. Nobody at that site had to be hired or moved.

Measure it per site and in the same units. Calls that ended without a booking, by location, by hour. That number tells you which building has a coverage problem and which has a configuration problem, and those get fixed differently.

Complexity is the reason to do it, not the reason to wait

The standing objection to a shared front office at a specialty group is that the sites are too different. Different surgeons, different pre-operative rules, different payer mixes, different histories.

That is true and it is the argument in favor. Simple tools break on exactly this, which is why groups that tried a booking widget across six locations went back to six front desks. The configuration is the hard part, and a system that cannot hold per-department eligibility, per-provider template rules, and per-site authorization behavior was never going to survive contact with an orthopedic group anyway.

What makes it tractable is that the rules already exist. They are in athenaOne, in the departments and provider groups and appointment types the sites already maintain, plus a handful that live in somebody’s head and have to be written down once.

That writing-down is the real implementation work. It is also the part that pays off whether or not the sites ever merge, because a group that has its per-site booking rules in explicit form has an asset it did not have before.

Key Takeaways

Separate answering as one practice from booking as one practice; only the first requires a central team, and the second never requires consolidation.
Search open and booked time across athenaOne departments so a patient gets offered the earliest real slot anywhere in the group.
Hold the generic-slot eligibility map per provider and per department, because that mapping is where multi-site booking breaks.
Alert on appointment-type and template changes a site makes on its own, and route affected bookings to a person until someone confirms the new mapping.
Staff the shared front office for eligibility and authorization work, not just scheduling, because that is where the hours actually go.
Track calls that ended without a booking by site and by hour to tell a coverage problem apart from a configuration problem.

Six orthopedic locations that never merged their schedules can still answer as one practice. The departments, provider groups and appointment types already in athenaOne are the routing map, and keeping them separate is not the obstacle. It is what makes each site bookable correctly once the calls arrive in one place.

Sources