Every dental group grows into the same wall. The model works at three locations, strains at ten, and by twenty the things that were minor frictions have hardened into structural problems — the kind you can’t fix by working harder or hiring a sharper operator. If you’re running or building a DSO, the structural problems of a multi-location dental group aren’t a sign you’re doing it wrong. They’re the predictable physics of the model, and almost every group hits the same seven.
What’s worth seeing is that these seven aren’t unrelated. Underneath, each one is the same thing in a different costume: a cost that scales with your location count, rooted in operating knowledge that lives in people and processes that live in habit rather than in a system. Name them clearly, and the common cause — and the common fix — comes into focus.
1. Knowledge walks out the door
The most valuable knowledge in a practice isn’t in the PMS — it’s in the head of the person who’s run the front desk for eight years. Front-desk turnover in dentistry routinely runs above 30% a year, so across twenty or fifty locations you’re constantly losing experienced people and the undocumented knowledge they carry, then paying months of ramp to rebuild it with each new hire. At a single practice it’s a manageable risk; across a group it’s a permanent structural bleed. Here’s the knowledge-loss problem in full, and how to stop storing institutional memory in people who can leave.
2. Every location quietly runs differently
The premise of a DSO is standardization — yet it’s the thing DSOs are worst at, because process lives in habit, not in a system. The same task gets done five different ways across five locations, each feeling correct locally. That variance erodes a consistent brand, creates compliance exposure, and makes performance impossible to compare. A policy binder states the standard; it doesn’t enforce it. Here’s why standardization fails in a document and works in the system applying it.
3. The standardize-vs-autonomy fight
Most DSOs grow by acquisition, and the deal often depends on promising the selling dentist they can keep running things their way. That collides head-on with the mandate to standardize the group. Most software forces you to pick one — total central control or total local autonomy — and either choice breaks something that matters. Here’s why it was never actually a binary, if your system can decide it per decision.
4. Your next acquisition is on a different PMS
Every acquisition is also an integration project, and the hardest part is rarely clinical — it’s getting the new practice to operate like the rest of the group when it runs on different software. Operating standards have always felt tied to the PMS, so a new location can’t simply inherit them: you re-implement, work around, or migrate (slow, costly, disruptive). That bottleneck limits how fast you can acquire. Here’s how a new practice can run your playbook on day one, whatever PMS it’s on.
5. You can only see the group at month-end
A single-practice owner can walk the floor. A DSO operator running fifty locations gets the picture in roll-up reports, assembled by hand, delivered well after the period they describe — and pulled from several PMS systems that don’t speak to each other. By the time you see a location is behind, the moment to act has passed. Here’s how a mixed-PMS group becomes glanceable in real time, without a migration.
6. You have to defend your AI to your board
A solo practice can adopt a tool because the owner likes it. A DSO answers to investors, a board, often a PE sponsor, and frequently a compliance function — and the “set it and forget it” autonomy most AI pitches lead with is exactly what a risk officer is trained to block. The questions that decide deployment aren’t in the sales deck: Is data protected? Is access scoped? Can we audit what the AI did? Does it make decisions no human reviewed? Does our knowledge stay ours? Here’s the bounded, governed, auditable, private posture that actually clears the bar.
7. The overhead won’t stop scaling
Strip a DSO to its financial premise and it’s one idea: operational leverage — grow revenue and locations faster than the cost of running them. The problem is that overhead traditionally scales almost as fast as locations do: every new practice needs more front-desk staff, more billing capacity, more management attention. The margin expansion the model promises gets eaten, location by location, by the headcount each one requires. Here’s how the right architecture bends the overhead curve instead of resetting it at each location.
The common cause — and the common fix
Read the seven together and the pattern is unmistakable. Knowledge that lives only in people. Process that lives only in habit. Standards that live only in a binder. Visibility assembled only by hand. Each is a cost that grows linearly with your group because the thing it depends on doesn’t scale — and none of them is fixed by a single feature. A receptionist tool doesn’t change how knowledge survives turnover. A scheduling app doesn’t resolve the standardize-vs-autonomy fight. A dashboard doesn’t make an AI defensible to your board.
What addresses all seven is a layer underneath the features — where the practice’s knowledge lives, where the rules are governed, where autonomy is bounded, and where the whole group becomes visible and consistent. ELVA calls that layer the Practice Brain. Two foundational pieces explain it: the architecture of the Practice Brain, and how it learns your specific practice. The seven problems above are each a spoke off those two ideas — which is why they share a cause, and a fix.
If you operate a group, the practical move is to read the problem that’s biting you hardest right now (the links above go straight to each), and then the two pillars that explain the layer underneath all of them. You can also see it in product form as ELVA for DSOs and group practices.
Frequently Asked Questions
What are the main structural problems of running a multi-location dental group?
Seven recur in almost every DSO: knowledge lost to staff turnover, operational variance between locations, the standardize-versus-autonomy tension from acquisitions, integrating practices on different PMS systems, lack of real-time visibility across the group, defending AI and operations to a board or compliance function, and overhead that scales almost as fast as locations.
Why do these problems get worse as a DSO grows?
Because each is a cost tied to something that doesn’t scale — knowledge that lives in people, process that lives in habit, standards that live in a binder, visibility assembled by hand. As you add locations, those costs grow roughly linearly, eating the operational leverage the DSO model exists to capture.
Can individual tools fix these problems?
Not durably. A receptionist tool, scheduler, or dashboard each helps one task at one location but doesn’t change how the cost of the group scales. The structural problems share a root cause — knowledge and rules that don’t live in a system — so the fix is a layer underneath the features, not another feature.
What is the common fix for all seven?
A layer beneath the individual features where the practice’s knowledge lives, rules are governed across locations, autonomy is bounded, and the whole group is visible and consistent. ELVA calls this the Practice Brain; the seven problems are each addressed by a different facet of it.
Where should a DSO operator start?
With whichever problem is biting hardest right now — each section above links to a full treatment — and then the two foundational pieces on the Practice Brain architecture and how it learns your practice, which explain the layer underneath all seven.
See the layer underneath all seven. Start with the architecture of the Practice Brain, or explore ELVA for DSOs and group practices.
