Multi-location dental groups: keeping operations consistent

A three-clinic dental group acquires a fourth practice. The clinical lead moves a hygienist over from the original clinic for a Tuesday rotation. She signs in to the chairside iPad at the new location and discovers that her practice management credentials do not work the same way. The intake form she uses daily at clinic one is configured slightly differently. The shared drive is mounted at a different path. The Wi-Fi password is different. By end of day she has filed three small tickets, each of which a different person solves on a different timeline. The owner sees this and asks the right question: why does any of this differ at all?

The answer is that the four clinics were set up at four different times by four different people with four different ideas about what “good enough” meant. None of them were wrong individually. The aggregate cost shows up in metrics nobody tracks directly. Slower onboarding. Higher per-clinic IT spend. Inconsistent compliance posture. Staff who cannot move between locations without retraining.

What multi-location consistency actually means

Consistency is not “every clinic uses the same software.” Most dental groups already have that part. The practice management system, the imaging system, and the clinical apps are usually the same across locations because the vendor relationships are at the group level.

Consistency is one layer down. It means every clinic looks the same at the device, network, and identity layer that staff actually interact with day to day.

Device layer. Every chairside iPad at every clinic is the same model, the same operating system version, the same passcode policy, the same set of installed apps, the same set of restrictions. A hygienist moving between locations sees the same screen.

Network layer. Every clinic’s network follows the same design pattern. The same Virtual Local Area Network (VLAN) structure, the same Wi-Fi naming convention, the same separation of patient and clinical networks. An IT issue at clinic three can be diagnosed by someone whose primary site is clinic one.

Identity layer. Every staff member has one identity that works at every clinic. A single sign-on (SSO) flow. A single Managed Apple Account. A single set of credentials that follows them across locations. No per-clinic local accounts.

The tooling that holds it together

Three pieces of infrastructure make consistent multi-clinic operations possible.

Apple Business Manager (ABM). The enrollment layer that brings every Apple device, at every clinic, into the same management surface. Every new iPad shipped from the reseller arrives ready to join the group’s MDM, regardless of which clinic it was destined for.

Mobile Device Management (MDM). The configuration layer that pushes the same device definition to every clinic. Mosyle, Jamf, Kandji, or SimpleMDM. The vendor matters less than the discipline of using it consistently.

Identity provider. Microsoft Entra ID, Google Workspace, or Okta. The system that holds the group’s staff identities and decides what each staff member can access. Without an identity layer, every clinic builds its own list of who is who, and the lists drift.

These three together turn a multi-clinic group into one fleet. Each clinic still has its local character. The IT foundation underneath does not.

The clinic-setup playbook

The artifact that holds the whole thing together is the playbook. Not the abstract policy document. The concrete, step-by-step list of what gets configured at a new clinic and in what order.

A useful starting frame:

Network build. Pre-planned VLAN structure, switch configuration, Wi-Fi controller, firewall rules. Done before any clinical equipment arrives.

ABM enrollment. Every device the group purchases for the new clinic goes into the group’s ABM tenant. Existing devices at acquired clinics are enrolled where possible.

MDM profile assignment. Devices receive the standard role profiles. Reception, chairside, surgical, office. Same profiles as every other clinic.

Identity provisioning. Staff at the new clinic are added to the group identity provider. Access decisions are made at the role level, not the clinic level.

Operational handoff. The playbook ends with a walk-through with clinic staff that confirms the configuration matches the documented standard.

The playbook lives in the group’s documentation. Every clinic build updates it where the build revealed a gap. Each acquisition gets cheaper than the last because the playbook absorbed the lessons.

When to think about this

The right time to standardise is before the next clinic, not after. Multi-clinic groups that build consistency in early absorb new locations almost as fast as the legal paperwork closes. Groups that try to retrofit consistency after five clinics often spend a quarter just untangling what diverged.

A consistent multi-clinic Apple footprint is not a vanity exercise. It is what lets the group scale without the IT cost scaling faster than the revenue does.