Adding a Location Without Rebuilding the Schedule

Adding a location gets treated as a technology decision when it is mostly a configuration one. Somewhere in the planning a question appears about whether the current setup can carry a second site, and that question quietly turns into a conversation about changing platforms, which is a far larger and far riskier thing than what is actually being asked.

The fear behind it is legitimate. Nobody wants to discover in month two that every schedule has to be rebuilt because a site was added the wrong way.

But the work is knowable in advance, and most of it is decisions rather than construction. The groups that struggle are not the ones with the wrong system. They are the ones that opened a site before deciding what the site was going to be.

Decide what a location is before you configure one

A second site can mean three different things and they behave differently. A genuinely separate operation with its own staff and its own patients. An overflow room for the same patients and the same providers. Or a specialised site where certain work happens and nothing else does.

That choice determines everything downstream. Whether a patient can be offered either site interchangeably. Whether providers float. Whether the two calendars should ever be looked at together. Whether a cancellation at one site should be offered to someone waiting at the other.

On athenaOne this decision is expressed as departments, and departments are the ground truth for what a site is. Get that mapping right at the start and the rest is configuration. Get it wrong and every report and every routing rule inherits the error, which is the expensive kind of mistake because it only becomes visible months later.

The useful test is a sentence somebody can say out loud. Patients booked at either site are the same population and can be moved between them, or they are not. If the group cannot answer that cleanly, the answer is not a system, it is a meeting.

The complication: generic slots do not travel

Here is the specific thing that turns an easy expansion into a bad quarter. Most scheduling templates are built on generic slots, the fifteen or thirty minute openings that exist to be flexible, and what they are actually eligible for is knowledge that lives in the schedulers rather than in the configuration.

When you search for a specific appointment type, the system returns a generic slot. Whether that slot can genuinely hold this type depends on the provider, the department, and the room, and an opening labelled as fifteen minutes may need to be an hour for a new patient. At one site that mapping is folklore and it works, because the same three people have been doing it for years.

Copy the template to the new site and the folklore does not come with it. New staff book against generic openings using the same names, and the schedule fills with appointments that do not fit their slots. The error surfaces on the day, in the room, where it is most expensive.

So write the mapping down before the site opens. Which specific types each generic slot may hold, per provider, per department. It is a tedious afternoon and it is the single highest-value hour of the whole expansion. Once the mapping is explicit, automation can offer only slots that genuinely fit, and anything that would require reshaping a template goes to a scheduler instead of being booked.

Capacity is what patients notice first

The reason a group is adding a site is usually demand it cannot serve, and demand shows up as wait time before it shows up anywhere in the financials.

A July 14, 2026, MGMA Stat poll found that 46% of medical groups reported new-patient appointment wait times had stayed the same year to date compared with the same period a year earlier, with another 4% unsure. A year before, in a July 1, 2025, poll, 40% of groups reported no change, 31% reported longer waits and 26% reported shorter ones. Wait times are sticky, which means added capacity has to be routed deliberately to actually relieve them.

That is the argument for treating a second site as a scheduling problem rather than a real estate one. Opening rooms does nothing if the booking flow still sends everybody to the original location out of habit.

So decide the offer order before the doors open. Which site gets offered first, under which conditions, and when the patient should be given a choice rather than an assignment. That rule is worth more to your wait times than the square footage is.

Say the location out loud, everywhere

The most common failure after an expansion is not a scheduling error. It is a patient arriving at the wrong building, which is a no-show that was manufactured by the practice.

It happens because location was implicit for years. One site meant the address never had to be part of the conversation, and every script, reminder, and confirmation was written on that assumption. The day a second site opens, all of them are quietly wrong.

Audit the whole chain before opening. The booking confirmation. The reminder. The prep instructions. The message a patient gets when something is rescheduled. Each one has to name the site explicitly, and a reschedule has to re-state it, because a patient who moves from Tuesday to Thursday may also be moving buildings without realising it.

The same applies to anything the patient has to do beforehand. Arrival time, what to bring, whether they need a driver. Those differ by site more often than groups expect, and getting them from the wrong site is the same as not getting them.

Self-scheduling is where a bad mapping becomes public

Groups usually want to open the new site to online booking, and that is exactly when a loose configuration stops being an internal problem.

Adoption is still modest across medical groups. A July 29, 2025, MGMA Stat poll found that 71% of practices have less than 25% of their patients using digital tools to self-schedule, while about one in five, 21%, have between 25% and 50% self-scheduling. Only 5% reported 51% to 75%, and 3% more than 75%.

Low adoption is not a reason to be careless with it. A staff member booking against an ambiguous slot applies judgment you cannot see. A patient booking the same slot applies none, and every gap between what the configuration says and what the site can actually do becomes a booking somebody has to unwind.

So open self-scheduling at the new site only for the types where the mapping is explicit and the constraints are encoded. Add the rest as they are pinned down. That sequencing costs nothing and it keeps the first months of a new location from being spent apologising.

Key Takeaways

Decide whether the new site shares a patient population with the old one before configuring anything, because every routing rule inherits that answer.
Map the site to its own athenaOne department cleanly, since departments are the ground truth every report and rule will read.
Write down which specific appointment types each generic slot may hold, per provider and per department, before staff at the new site book against them.
Set the offer order between sites explicitly, or the booking flow will keep sending patients to the original location out of habit.
Audit every confirmation, reminder, and reschedule message to name the site, because location was implicit for as long as there was only one.
Open self-scheduling at the new site one appointment type at a time, starting with the ones whose constraints are fully encoded.

Adding a location does not require a new platform. It requires deciding what the location is, mapping it to its own department, making the slot rules explicit instead of tribal, setting the offer order between sites, and saying the address in every message that touches a patient. Do those five things before the doors open and the expansion is a configuration afternoon. Skip them and it becomes the project everybody was afraid of.

Sources