Dental practices

Peak-hour calls go to voicemail and the patient books down the street.

Dental demand arrives in bursts, at the exact hours the front desk is already on another line. We build the intake, recall and quality layer that catches it, inside the practice management system you already run.

Where a dental practice loses revenue

Four gaps, all measurable, all invisible from inside the software because none of them create a record.

The burst you cannot staff for

Dental calls do not arrive evenly. Monday morning and the hour after work carry a disproportionate share, and that is exactly when reception is checking someone in, taking payment and answering line two. The caller in pain does not leave a message. They call the next practice.

The recall nobody chased

Hygiene intervals are the most predictable revenue in dentistry and the most casually managed. A patient due at six months slips to nine, then to fourteen, then stops being a patient at all. Nothing in the software raises a hand, because raising a hand was somebody's memory rather than a process.

The treatment plan that was accepted and never started

The patient said yes. The plan is in the system. It was never scheduled, and there is no owner and no follow-up date. In most practices this is the single largest pool of already-won revenue sitting untouched, and it is worked only when someone has a slow afternoon.

The chair that sat empty

A late cancellation at 11:00 leaves an hour that could have been filled from a waiting list nobody has time to phone through. Utilization is discussed monthly and lost daily.

What gets built

Four systems on one shared integration. Most practices start with intake or recall and add the others once the first is measured.

1

Intake and booking

Answers calls and messages during peaks and outside staffed hours. Distinguishes new patients from existing ones, captures the reason for contact, triages urgency against rules the practice defines, and books against the real calendar where the system allows it. Every contact leaves a structured record, so the calls you used to lose become countable for the first time.

2

Recall and reactivation

Holds the expected return interval per patient and per treatment rather than one blanket rule, and reaches out before the interval is badly overdue. Lapsed patients are separated from patients who simply moved away, so outreach goes where it can still work.

3

Treatment plan follow-up

Pulls accepted but unscheduled treatment out of the software, ranks it by value and clinical urgency, and works it as a queue with real contact attempts and recorded outcomes. This is usually the fastest measurable return of the four.

4

Conversation quality and planning

Reviews recorded calls to find the recurring point where bookings die, and puts appointment history, call volume and cancellation behaviour side by side to report chair utilization by hour and by clinician.

These share one integration and one data layer, which is why adding the second system costs far less than the first.

How it connects to your practice management system

We do not ask a practice to change software. The interface it exposes decides the depth of the work.

Open booking API

Availability is read and appointments are written back. The agent books, reschedules and cancels directly. First production workflow usually in two to six weeks.

Partial API

Availability can be read but bookings cannot be created, or only some record types are exposed. The agent does everything permitted and hands the last step to a person with the full context already captured.

Closed system

No usable interface. The agent answers, triages and prepares the record; booking stays manual. We tell you before quoting when the gain does not justify the build.

Clinical rules stay yours

Triage thresholds, what counts as an emergency, what the agent may never answer. These are set by the practice and written down before launch, not learned by the model from transcripts.

How the result is measured

Against your own numbers, never an industry average.

A baseline first

Answer rate, booking rate from inbound calls, recall compliance, treatment plan start rate and chair utilization are recorded before anything answers a call.

A holdout where volume allows

A share of contacts the system never touches, so seasonality is not reported as impact. Where volume is too low for that to mean anything, another comparison design is agreed before launch.

Reported in your terms

Recovered calls, recalls returned, treatment plans started, hours filled. In a document you can hand to a partner without translation.

What we will not report

Movement we cannot attribute. If a marketing campaign ran in the same window, that goes in the report instead of a percentage we cannot defend.

What we need from you

Access to the practice management systemThe live system or its documentation, so integration depth comes from reality rather than assumption.
How calls and recalls run todayWho answers, when, what happens out of hours, and how recalls are currently chased.
Clinical triage rulesWhat counts as urgent, what routes straight to a person, and what the agent must never answer.
Current numbers, if they existCall volume, booking rate, recall compliance. If they do not exist, establishing them is the first piece of work.
An agreed metricThe single number this project is judged by, decided before launch rather than argued about after.

Questions we get asked

Will this work with our practice management software?What decides the answer is the interface, not the brand. If the system exposes an open booking API, the agent reads availability and writes appointments directly. If it exposes a partial API, the agent does everything the interface allows and hands the final booking to a named person with the patient, the reason and the preferred time already captured. If it is fully closed, the agent still answers, qualifies and prepares the record, and booking stays manual. Which case applies is established during scoping by looking at the live system rather than at its documentation.
A patient calls about pain. Can a system really handle that?It handles the part that is currently going to voicemail. Urgency is triaged against rules the practice sets, not invented by the model: a defined set of symptoms routes straight to the emergency path and to a person, everything else is booked or captured. The comparison is not between the agent and your best nurse. It is between the agent and nobody answering at 20:15 on a Friday.
Does it help with recalls, or only new patients?Both, and recalls are usually where the money actually is. Hygiene intervals, treatment plans that stopped halfway, patients who cancelled and never rebooked: each has an expected return date and each is currently tracked by whoever remembers. The system holds the interval per patient and per treatment and reaches out before the relationship is gone rather than after.
What about a treatment plan the patient accepted and never started?That is the highest-value gap in most practices and the least systematically worked. Accepted but unscheduled treatment sits in the software with no owner and no follow-up date. It is pulled out, ranked by value and by clinical urgency, and worked as a queue with real outreach rather than as a report nobody opens.
Can it take insurance questions?It can answer what the practice has documented and it will not improvise the rest. Coverage questions that depend on a specific plan are captured with the detail needed and routed to a person. An agent that guesses at coverage creates a complaint, so it is built not to.
How is this measured?Against the practice's own numbers. Before launch the current state is recorded: answer rate, booking rate from inbound calls, recall compliance, treatment plan acceptance and start rate, chair utilization by hour. Where call volume allows, a holdout share is kept untouched so a busy season is not reported as system impact. Where it does not, another comparison design is agreed before launch.
How long does it take?A first production workflow typically launches in two to six weeks. The variable is almost never the AI. It is what the practice management system permits and how quickly clinical rules for triage can be agreed.
What do you need from us?Access to the practice management system or its documentation, a description of how calls and recalls are handled today, current numbers if they exist, one person who can answer how the practice actually runs, and agreement on the single metric this project is judged by.
Let's scope it

Start with the calls you are already losing.

Answer five questions and the brief writes itself, or write to us directly. Either way you get an initial solution brief. A proposed architecture and a fixed quote follow a scoping call, once we have seen your systems.

Build a brief → Contact form