AI Receptionist for Dentrix Dental Practices

Every dental practice has a list it knows it should work and rarely does: the recall list. Patients due for a hygiene visit, patients a month past due, patients who accepted a treatment plan and never booked it. Each is money the practice has already earned the right to and is quietly letting go, because working the list means someone on the phone all afternoon instead of at the front desk. On a Dentrix practice, the recall list is the clearest example of revenue lost not to competition but to a phone nobody has time to pick up.

We build the Dentrix connection, and this is about that list, and the inbound calls alongside it, worked every day rather than when someone finds a spare hour.

The recall list is not a marketing exercise; it is booking patients the practice already has a clinical reason to see. 2care works it from the practice's own rules in Dentrix, so recall is a daily background task rather than a quarterly scramble.

A recall state	What the agent does	Result in Dentrix
Due this month	Calls to book the hygiene visit	Appointment written, recall cleared
A month past due	Calls to reactivate	Rebooked, or flagged if unreachable
Booked but unconfirmed	Confirms the day before	Confirmed, no-show risk cut
A cancelled hygiene slot	Offers it down the waitlist	The slot filled the same day
Accepted treatment, unbooked	Calls to schedule it	The treatment on the schedule

The work writes straight back into Dentrix, so a booked recall clears from the list and a filled slot updates the schedule, with nothing sitting on a separate spreadsheet for someone to reconcile against the day sheet. A recall list that is worked every day rather than every quarter is the single biggest change most practices see, because the patients on it are the easiest bookings in dentistry, already owed and already known.

The treatment that was accepted but never booked

The quietest leak in a dental practice is the treatment a patient agreed to and then never scheduled. The plan is in Dentrix, accepted, sometimes with the finance arranged, and then the patient leaves without a date and the crown or the root canal simply does not happen. It is fully earned revenue sitting one phone call away.

2care works that unscheduled-treatment list the same way it works recall, calling the patients with accepted-but-unbooked treatment and offering them a slot of the right length with the right provider, writing the appointment into Dentrix when they take it. Because the outreach is drawn from what Dentrix already holds about each patient, the call is specific, this treatment, this quote, rather than a generic prompt, which is the difference between a booking and an annoyance.

There is a clinical case for it as well as a commercial one. Accepted treatment that never happens is a diagnosis left untreated: the cracked tooth that becomes an extraction, the small filling that becomes a root canal. Chasing the unbooked plan is not only revenue recovery; it is the practice following through on care it has already recommended, which is the version of the argument a dentist actually cares about.

How a Dentrix booking is made, and how fast

Underneath both the outbound and the inbound is one connection. 2care reaches Dentrix through its API and secure connector, set up during onboarding, with nothing new for the practice to run. Operatory and hygiene availability is read live, so an offered slot genuinely exists, and the appointment is written against the resolved patient and validated by Dentrix against its own schedule rules, so a slot taken during a call fails cleanly rather than being assumed open.

The timing is what lets a caller feel looked after rather than processed. A reply comes back in about 480 milliseconds, ninety-fifth percentile under 700, on a voice pipeline we run ourselves rather than one bolted together from outside services, so reading Dentrix live is not a pause the caller hears. The line holds 99.9 per cent uptime across a thousand or more simultaneous calls, and every booking write is idempotent, so a network stutter never puts the same appointment on the schedule twice. Turn-taking waits for a finished sentence, so a nervous patient describing a broken tooth is not cut off mid-explanation.

The emergency call, and the boundary

Dentistry has genuine emergencies, and the phone is where they arrive. A patient with a knocked-out tooth, uncontrolled bleeding after an extraction, or swelling spreading toward the eye is not a booking to be slotted; it is a call that needs a person now.

2care resolves urgency on every call and holds a firm boundary: a described dental emergency leaves the booking flow and reaches a person in seconds, with what the caller said attached, while a routine toothache is triaged to an appropriate urgent slot rather than the next routine one. The agent does not diagnose or advise; it recognises that a description needs a human and routes it, which is the recognition-not-assessment line the whole platform holds. Getting that boundary right is what makes the confident, fast booking on every other call safe to rely on. The routing is configured in triage and routing.

The middle ground is where the judgement shows. Most pain calls are not emergencies but are not routine either: a patient in real discomfort who needs to be seen today, not next Tuesday. The agent does not decide how bad the pain is, but it recognises the difference between "my check-up is due" and "I've been up all night with this," and books the second into an urgent slot the practice keeps aside rather than the next open hygiene appointment three weeks out. That is an operations decision about slot type, not a clinical one, and it is exactly what a good dental receptionist does without thinking.

The record on Dentrix, resolved before the write

Before anything is written, the caller is matched to their existing Dentrix chart and confirmed on a date of birth, so a returning patient keeps one record; a genuinely ambiguous match goes to a person rather than a guess, using patient matching. A duplicate dental chart is a particular problem, because a patient's treatment and radiographic history splits in two, so the matching is built to refuse rather than resolve. Intake is captured in the same breath and written to Dentrix as structured fields, and the same capture feeds patient intake across every channel a patient uses. It matters more in dentistry than most settings, because a duplicate chart can hide a course of treatment or a radiograph from the clinician mid-appointment, and the cost of that surfaces in the chair rather than on a report.

What 2care changes for a Dentrix practice

A Dentrix practice is not short of a practice management system; it is short of the hours to work the lists that system holds. 2care answers every inbound call and works the recall and unscheduled- treatment lists outbound, booking against Dentrix's own availability and rules and writing each result back, in one native pipeline rather than a chain of tools passing a patient along.

What a practice feels is not a faster booking on the calls the desk already took. It is the recall list worked to the end for the first time, the accepted treatment that used to evaporate now booked, and the emergency call that used to hit voicemail at 8pm now reaching the on-call dentist in seconds. 2care turns the lists a practice knew it should work into revenue it actually collects.

The compounding effect is what practices notice a quarter in. A recall worked on time surfaces treatment; the treatment booked keeps the patient in the chair and in the practice; the patient retained refers another. None of that shows up in the first week's numbers, and all of it flows from the simple change of the lists being worked every day rather than whenever the desk finds an hour that it almost never does.

Where the data goes on Dentrix, and under what agreement

A booking here creates something and keeps it: a transcript, a matched patient, and an appointment written into Dentrix. That is handling protected health information, not passing a call along.

The law is specific about it. HHS guidance makes a vendor doing this a business associate, not a conduit, so the arrangement runs under a signed agreement from the first call. Data is encrypted in transit and at rest, the models behind the conversation are never trained on it, and every write leaves a trail that can be reversed. The compliance page covers the frameworks that apply on each side of the border.

Where this is right for Dentrix, and getting live

This is right for a practice whose recurring revenue runs through recall and treatment plans, that keeps its schedule, providers and recall rules current in Dentrix, and that has an on-call dentist for the emergencies. Given those, the benefit lands from the first day the line goes live, and the recall list starts shrinking in the first week.

Getting there is three moves over weeks. The connection is authorised to read availability and write appointments through the Dentrix API and connector. The practice's setup is mapped: operatories, providers, appointment types and lengths, recall rules, and the emergency route. Then the line is tested against a sandbox with the front desk listening before it is switched across, and the recall and routing behaviour is tuned over the first days against real calls, each change backed by the trigger every escalation records.

Frequently asked questions

Does it actually work the recall list, or just answer the phone?

Both. Inbound, it answers every call and books it; outbound, it works the recall and unscheduled-treatment lists from the practice's rules in Dentrix, calling patients due or past due and booking them, with each result written back so the list clears itself.

How does it handle a dental emergency?

A described emergency, a knocked-out tooth, spreading swelling, heavy bleeding, leaves the booking flow and reaches a person in seconds, with the caller's words attached. The agent never assesses or advises; it recognises the description needs a human and routes it.

Will it create duplicate charts in Dentrix?

No. The agent finds a returning patient's existing chart first and checks it against a date of birth, and if two charts could both be the caller it hands the call to a person instead of choosing one. A split dental record, with treatment and radiographs on two charts, is exactly what that refusal prevents.

Can it confirm appointments to cut no-shows?

Yes. It confirms booked appointments a day and a couple of hours ahead on the channel the patient answers, and offers a cancelled slot down the waitlist within minutes, so a gap that opens in the morning is filled by the afternoon rather than lost, and a high-value operatory hour is rarely left empty on the day.

Is patient data ever used to train models?

No. A patient's information is never turned into training data for a model in the pipeline. It stays encrypted throughout, is retained only for as long as the record needs it, and sits under the agreement covering every Dentrix call. The conversation is good because of how it is built, not because it mined anyone's chart.

Hear it work a recall call and an emergency

The two calls worth judging on a Dentrix line are the recall the practice never had time to make, booked cleanly, and the 8pm emergency, routed to a person in seconds rather than left on a machine until morning.

See how the same connection runs on other systems across integrations, or hear a recall call and an emergency handled on a live line when you book a demo.