The DSO operator's guide to AI receptionists in 2026

If you operate 5+ dental locations under one organization — formal DSO, MSO-backed group, or independent multi-location practice — the AI receptionist purchase decision looks nothing like the single-practice version. Different procurement process, different stakeholder map, different rollout playbook, different success metrics. This guide is for the operations leader doing this evaluation in 2026.

What's actually at stake for a DSO

Single-practice missed-call math gets multiplied by location count. A 10-location group missing 25% of after-hours calls per location is missing 50–80 new-patient appointments per month per location, which is 500–800 across the group. Even at conservative new-patient lifetime values of $1,500–$3,000, the group is leaving $750k–$2.4M of recoverable annual revenue on the table.

That's the upside. The downside risk is bigger: you're integrating a vendor across 10 locations' worth of patient communications, with 10 BAAs, 10 phone configurations, and 10 PMS instances. A bad rollout breaks 10 practices simultaneously. Risk management is a first-class concern, not an afterthought.

The procurement process changes

For a single practice, the procurement process is "owner watches a demo, signs the MSA." For a DSO, you're running a process: gathering stakeholder requirements, issuing an RFP, doing reference checks, security review, legal review, IT review, and getting executive sign-off.

The stakeholder map typically includes: COO or VP of Ops (decision maker), Director of IT (security review), Director of Marketing or Patient Acquisition (KPI alignment), VP of Finance (contract terms, ROI proof), regional managers (rollout sequencing), and ideally one front-desk lead from a pilot location (operational reality check). Forgetting any of these stretches the timeline.

What to put in your RFP

A good DSO RFP for AI receptionist covers:

• PMS integration depth — listed by which PMS you have at which locations. "Integrates with Dentrix" isn't enough; ask which version, which deployment model (cloud / on-prem / Ascend), and demo a live test booking.
• Multi-location administration — centralized dashboard? Per-location overrides? How does a regional manager change hours for one location without touching others?
• Voice and language coverage — Spanish at minimum. Specific Spanish dialects if your population requires them. Other languages depending on patient mix.
• Reporting at the group level — KPI dashboards rolled up across locations. What's the cadence?
• Support structure — dedicated CSM? SLA terms? Response time for P1 issues? After-hours support?
• Security and compliance — SOC 2 status, HIPAA BAA, subprocessor list, breach notification protocol, data residency.
• Contract terms — multi-location pricing, growth allowance for new locations, exit terms.
• Reference customers — at least 2 DSOs of comparable size, ideally on similar PMS mix.

The pilot — pick the right 2 locations

Don't roll out to all 10 locations at once. Pilot with 2 — and pick them deliberately.

Pilot location 1: a "hard" location — high call volume, complicated insurance mix, a strong office manager who'll give you honest feedback. If the AI can succeed here, it'll succeed everywhere. If it can't, you've found the failure mode before it broke 10 locations.

Pilot location 2: a "different" location — different PMS, different demographics, different specialty mix. Tests cross-config rather than just scaling.

Run the pilot for 30–45 days before deciding to expand. Define pilot success criteria upfront: missed-call rate, new-patient capture rate, front-desk satisfaction, and a clean security/compliance review. Don't expand on a vendor's promises — expand on pilot data.

Per-location vs. centralized configuration

The biggest operational challenge with multi-location AI receptionist deployment is configuration governance. Some things should be centralized; others should be local.

The dashboard architecture matters here. You want a system where the regional manager at Location 7 can change Location 7's hours without ability to change Location 1's BAA or AES key. Aria's admin role model supports this; some competitors require everything to flow through the central dashboard, which becomes a bottleneck at scale.

Metrics that matter at the group level

For a DSO, the operational KPIs are different from a single practice. You're not just measuring "did Aria answer the call" — you're measuring whether the AI receptionist materially moved your group-level economics:

• Missed-call rate by location — should drop to under 5% within 60 days of go-live.
• New-patient capture rate — % of new-patient inbound calls that result in booked appointments.
• Cost per booked new patient — total Aria cost per location ÷ new patients booked. Should be under your group's blended new-patient acquisition cost.
• Insurance-verification accuracy — % of bookings where insurance was verified before the patient arrived.
• Front-desk time recovered — measured by front-desk hours surveys before and after rollout.
• Net retention of front-desk staff — counterintuitive, but a good AI receptionist usually reduces front-desk burnout, which should show up in lower turnover.

Contract structure for groups

The deal structure matters more than the per-month price. Things to negotiate:

• Per-location pricing tier — most vendors discount as locations stack. Get specific volume tiers in the contract, not "subject to good-faith negotiation later."
• New-location addendum — when you open or acquire a new location, what's the standard add-on price? Get this in writing.
• SLA with credits — 99.9% uptime with credit policy if missed. Most vendors offer this on enterprise tier; push for it.
• Exit terms — what happens if you need to exit at year 1? Year 2? What's the data export process?
• BAA flow-down — your BAA with the vendor, plus their BAAs with their subprocessors. Confirm the chain.

Scaling across the rest of the group

Once your pilot succeeds, the rollout to remaining locations should run on a documented playbook. The locations you've already deployed become reference templates — the regional manager at Location 8 can shadow the deployment at Location 1's office for a day before going live.

Typical multi-location rollout cadence: pilot months 1–2, second wave (2–4 locations) months 3–4, remaining locations months 5–7. Faster is possible but rarely worth the operational risk. Slower happens when the vendor's onboarding bandwidth is the constraint — ask in the RFP about parallel onboarding capacity.

Related reading