Running several dental branches without losing the thread

The first branch hides how much runs on proximity

In a single location, a surprising amount of the clinic runs on people being in the same room. The manager knows the day is busy by looking at it. Stock gets reordered because somebody opened the cupboard. A patient who is unhappy is dealt with before it becomes a review.

None of that survives a second address, and the failure is quiet. Nothing breaks on the first day. It shows up a quarter later as a branch whose numbers nobody can explain.

The useful way to think about a second branch is not "more of the same" but "the same clinic, now needing to be legible at a distance".

The report that matters is the comparison

Single-branch reporting asks how the clinic did. Multi-branch reporting asks which branch did better, and why — and that second question is where the value is.

Revenue per chair, no-show rate, collection rate, average treatment value, new patients per month. Any of these in isolation is noise. The same figure across three branches for the same period is a management conversation.

It only works if the definitions are identical everywhere, which is the real argument for one system rather than three. Three branches each running their own spreadsheet will produce three different definitions of a completed treatment, and every comparison after that is an argument about the data instead of a decision about the business.

Opening a branch is a configuration problem

The branches that open smoothly are the ones that inherit. Price lists, procedure catalogue, consent forms, invoice templates, automation rules — all of it should already exist and apply from day one, with only the genuinely local things set per branch.

When a new branch starts by rebuilding its own price list, you have not opened a branch. You have started a second clinic that happens to share a logo, and the comparison reports you wanted will never quite line up.

The third branch is the test of the second

Opening the second branch is always a project. What tells you whether the group works is how much of a project the third one is. If it is a checklist — inherit the catalogue, set the rota, scope the permissions, open — the structure is holding. If it is another project, you have built one clinic twice and are about to do it again.

Rotas and capacity are the part that genuinely belongs to the branch. The dentist who covers Tuesdays in one location is a scheduling fact in that location only, and a group that tries to run one combined diary ends up with a calendar nobody trusts at either address.

Everything else should inherit by default and be overridden deliberately. A branch that can invent a procedure will, and within a quarter two branches have different names for the same crown — after which no comparison between them is worth reading.

What a visiting specialist does to the model

Most dental groups share people before they share anything else: an implantologist across three sites, an orthodontist on Thursdays. That makes two things per-branch facts that owners usually assume are central — the rota, and which room is free — and one thing emphatically not: the commission.

Sessions have to carry the clinician who delivered them and the branch they happened in, or the month end produces an argument that cannot be settled. The specialist wants one statement across all three sites; each branch manager wants their own revenue to include the work done in their chairs. Both are reasonable and both need the same underlying record.

Patients travel too, and that is the point of a group rather than a problem with it. A patient charted in one branch and treated in another is one record, one chart and one balance — which is the single decision that is nearly impossible to retrofit, and the reason to settle it before the second branch opens rather than after the third.