# AI Receptionists for Multi-Location DSOs > A tool that works for one practice can quietly break across twelve. Here is what changes at scale, and the questions that separate a real multi-location product from a single-office one with a group discount. **Author:** gethelpdesk-ai **Published:** 2026-09-12 **Category:** guides **Tags:** DSO, multi-location, operations, front-desk, scheduling, evaluation **Canonical:** https://gethelpdesk.ai/blog/ai-receptionist-multi-location-dso/ --- ## The Demo Was One Office. You Have Fourteen. Most AI receptionist demos are built around a single practice. One phone number, one schedule, one set of rules, one person who knows how the office runs. It looks great. Then you roll it out to fourteen locations and the questions start. Which office does a caller reach when they dial the group number? What happens when the Ridgeview office runs a different hygiene interval than the downtown office? Who gets the after-hours emergency page when the on-call dentist covers three sites this week? Which manager can change the scripts, and can they change them for everyone by accident? None of that is exotic. It is just what happens when the same software has to serve offices that share a brand but not a workflow. A product designed for one office handles it by making you pick a compromise. A product designed for a group handles it by letting the offices differ on purpose. If you run a DSO or a small group, the evaluation is different from a single-practice evaluation. Here is what actually changes. ## What Breaks First at Scale **Routing stops being obvious.** In one office, every call goes to that office. In a group, a caller might dial a location directly, dial a central number, or call the number from a Google listing that points somewhere else entirely. You need to know how the system decides where a call belongs, and what it does when it cannot tell. A caller who gets booked at the wrong location is worse than a caller who got voicemail, because now you have a no-show and an annoyed patient. **Rules stop being universal.** Offices differ on the things that matter most to scheduling: appointment lengths, which providers see which procedure types, how far out new patients can book, whether Saturday is a real day, what counts as an emergency worth paging someone. If the AI has one rulebook, some of your offices are getting the wrong one. **Data stops being one pile.** Some groups run one practice management instance across all sites. Many run separate instances, sometimes separate systems entirely after an acquisition. That difference decides what an AI receptionist can realistically do for you, and it is the single biggest technical fact about your group. **Permissions start to matter.** In one office, the manager changes the greeting. In a group, you need to know who can change what, and whether a regional manager editing a script for their four offices can accidentally change it for the other ten. ## The Practice Management Question Comes First Before anything else, establish what your estate actually looks like. Not what the org chart says, what the software says. Do all locations run the same system? If yes, is it one shared database or one instance per office? If no, which systems are where, and is there a consolidation project that will change the answer in six months? This matters because an AI receptionist that writes appointments into your schedule has to authenticate against something. One shared instance is the easy case. Separate instances mean the vendor needs a working connection per site, and you should ask how they handle fourteen of them rather than one. Mixed systems after an acquisition are the hard case, and the honest answer from a vendor might be that some of your offices get full booking and others get accurate message-taking until the migration finishes. A vendor who says "we support all of that" without asking which systems you run has not understood the question. For what it is worth, GetHelpdesk integrates with Dentrix, Open Dental, Eaglesoft and iDentalSoft. If your group runs something else at some sites, say so early and get a straight answer about what those offices would actually get on day one, rather than discovering it during rollout. ## Questions That Separate Real Multi-Location Support Ask these specifically. Vague answers here predict painful rollouts. **On routing** - If a patient calls the central number, how does the system decide which location to book them into? Does it ask, use the caller's history, or use the number they dialed? - What happens when a caller wants an office that has no availability? Can it offer a sister location, and can we control which ones it offers? - Can we route by procedure? Some groups keep oral surgery at two sites only. **On per-location configuration** - Can each location have its own hours, providers, appointment types and durations? - Can we set a group default and let individual offices override specific rules, or is it all-or-nothing? - When we change something at the group level, what happens to offices that had overridden it? **On emergencies and escalation** - Can the after-hours escalation path differ per location and per night? On-call rotations do not respect office boundaries. - Who gets paged when nobody answers the first escalation? **On permissions and audit** - What roles exist? Can a location manager be limited to their own site? - Is there a log of who changed which setting and when? When a script goes wrong across ten offices, you need to know how. **On reporting** - Can we see call volume, booking rate and after-hours activity per location, and compare locations? - Can we export it, or is it trapped in a dashboard? **On rollout** - Can we pilot at two or three sites without committing the group? - What does adding a fifteenth location involve, and how long does it take? ## What Good Looks Like in Reporting Per-location reporting is where a group tool earns its keep, because it turns a vague sense that "the phones are bad at Ridgeview" into something you can act on. The comparison you want is simple. For each location, over the same period: calls received, calls answered, calls answered after hours, appointments booked, and booking rate. Sorted by booking rate, that list tells you where to look. A site with high volume and low booking rate has a capacity or a scripting problem. A site with low volume has a marketing or a listings problem, and no AI receptionist will fix it. Ask to see this report during evaluation, populated with real demo data. If the vendor can only show you a single-office view, you have learned something important. ## Pilot Design That Actually Tells You Something Do not roll out to the whole group at once, and do not pilot at your best location. Pick three sites: one high-volume office, one that is chronically short-staffed at the front desk, and one that runs differently from the rest, whether that is a different system, a different specialty mix, or a different patient population. The awkward site is the point. It is where you will find out whether per-location configuration is real. Run it for at least four weeks so you catch a full recall cycle and a couple of weekends. Before you start, write down what you expect: current after-hours missed call volume, current booking rate, and how many calls per week the front desk currently cannot get to. Without a before number, the after number means nothing. Test the failure paths on purpose. Call the central number and ask for a location that is booked solid. Call as an existing patient of one office asking to be seen at another. Call after hours with something that sounds like an emergency. Ask for a provider who left. How the system handles the calls it cannot complete matters more than how it handles the easy ones. ## What Your Group Still Owns An AI receptionist does not remove the work of running a group. It changes where the work sits. You still need someone who owns the configuration, because fourteen locations of drifting scripts becomes unmanageable fast. You still need to include the service in your compliance review and your vendor risk process, the same as any other system that touches patient information. You still need to train front desk teams on what the AI handles and what gets handed to them, or you get two systems quietly duplicating each other. And you still need to decide what the AI is for. A group that deploys it to cut front desk headcount will evaluate it differently from a group that deploys it to stop losing after-hours new patients. Both are legitimate. They are not the same project, and they do not have the same success measure. ## Key Takeaways - Establish your practice management estate first. One shared instance, separate instances, or mixed systems decides what is actually possible. - Per-location configuration is the real test. Ask whether offices can differ on hours, providers, appointment types and escalation, and what happens when a group-level change collides with a local override. - Routing from a central number is where groups get hurt. Know how the system decides, and what it does when it cannot. - Demand per-location reporting you can compare and export. It is how you find the site with the problem. - Pilot at three sites including your most awkward one, for at least four weeks, with a written before number. ## Talk to Us About Your Group If you run multiple locations and want a straight answer about what would work on day one and what would need to wait, tell us which practice management systems are at which sites. That single fact shapes everything else. [See how GetHelpdesk works with your practice management system](/integrations/)