Open Dental write-back means an AI receptionist creates the appointment inside Open Dental itself, through the Open Dental API, with the patient, the appointment type, the length, the operatory, the provider, the date and time, and the procedure codes all attached. Anything short of that is a message your front desk still has to type in.
The word integrates does a lot of work in this category, so it is worth knowing exactly what has to happen between the phone ringing and a correct appointment sitting in your schedule. Here are the six steps, where each one breaks, and what to ask in a demo. If you are evaluating anyone, including us, use this as the script.
Why write-back is the hard part
Answering the phone is the easy part. What happens after the call is where an answering service and an AI receptionist diverge. Any competent voice AI can hold a conversation about a cleaning.
The difficulty is that an appointment in Open Dental is not one field. The appointment record carries a patient, an appointment type, a time pattern that sets its length, an operatory, a provider, a date and time, and the procedures attached to the visit. Those are separate fields on the appointment resource in Open Dental's own API documentation. Get any of them wrong and you have not saved your team work, you have created work, because now someone has to find the mistake and fix it.
So the honest measure of an integration is not "does it connect." It is "does what lands in the schedule look like what my front desk would have entered."
The six steps
1. Caller lookup
The phone rings. Before anything else, the system takes the inbound caller ID and queries Open Dental for a matching patient.
This single step drives most of the downstream logic. It determines whether the caller is a patient of record, which changes what they are eligible to book, what you already know about their financial status, and whether you greet them by name.
Where it breaks. The patient calls from a number that is not on file, which happens constantly with spouses, adult children calling for a parent, and anyone who changed carriers. Or the number matches more than one patient in a family. Or the Open Dental API is unavailable.
That last one is not hypothetical. In one of our own dental deployments a caller lookup failed during testing, and the cause turned out to be a confirmed Open Dental API outage rather than anything in the configuration. No integration that talks to a live server has a zero percent failure rate. What matters is what the caller hears when it fails, and whether you find out.
2. Intent classification
The system has to work out what the caller actually needs, which is rarely what they first say. "I need to come in" could be a hygiene recall, a broken crown, or a consult.
The useful distinctions for a dental practice are narrow: routine hygiene, new patient exam, a problem-focused visit, a reschedule or cancel, a consult for major treatment, or a non-clinical question like billing. Those are the same call types your front desk already sorts by hand, and they map closely to the eight calls a general practice gets most.
Where it breaks. Callers describe symptoms, not appointment types. Someone saying "my crown fell off" is not asking for a limited exam by name, but that is what they need. Mapping symptom language to your appointment types is configuration work, and it is the difference between a system that books usefully and one that books a generic slot you have to sort out later.
3. Screening against your rules
This is the step most often missing, and it has to happen before any slot is offered.
Your rules might include whether you are in network with the caller's plan, whether you accept their plan at all, whether you take Medicaid or state assistance, whether new patients are eligible for same-day emergency slots, and what your financial policy requires at time of service.
A real example from a cash-pay, out-of-network practice we work with: patients pay upfront, the practice bills insurance on the patient's behalf, and reimbursement goes to the patient. Medical Assistance patients are not accepted. Those two rules have to be enforced on every single call, because booking a patient who does not qualify creates a bad conversation at check-in and a hole in the schedule when they do not show.
Where it breaks. Screening that runs after the booking. If the rule is checked once the slot is already taken, that is not screening. It is cleanup.
4. Appointment type and chair time
Once you know who they are and what they need, the appointment type determines the length. This is not cosmetic. Chair time is your actual capacity.
A practical mapping looks like this, and these are the real parameters from a dental practice we work with:
- Established patient cleaning or exam: 60 minutes
- New patient intake and exam: 90 minutes
- Emergency visit: 30 minutes, established patients only, verified by caller lookup
Notice that the third one depends on step one. The emergency slot is gated on established-patient status, and the only way to know that on an inbound call is the phone number lookup. If the lookup fails, the eligibility check fails with it, and the system needs a defined fallback rather than a guess.
Where it breaks. Booking everything into a single default length. It looks fine in a demo and wrecks a real schedule inside a week.
5. Slot selection
Now the system needs a real opening: the right length, in an operatory that can host that appointment type, with the right provider, respecting blockouts and the schedule you actually keep.
Where it breaks. Offering slots that exist in the calendar but not in reality, because the system does not understand your operatory or provider constraints. The patient gets a time, your schedule gets a conflict.
6. Procedure code attachment
The last step is attaching the procedure codes to the appointment so the visit arrives in the schedule pre-coded, the way your team would have entered it.
Practices define their own code sets per appointment type. In one mapping we built, the practice supplied three sets: one for cleanings, one for emergency visits, and one for new patient visits. Each was a small group of CDT codes, the Code on Dental Procedures and Nomenclature maintained by the American Dental Association, covering the evaluation, the imaging, and the procedures typical for that visit. The practice supplies the sets, because they reflect that practice's protocol and fee schedule, not a universal standard.
The mapping is not finished when it is entered. It is finished when a test call has produced a real appointment and the codes have been checked inside Open Dental.
Where it breaks. Assuming a standard mapping. Two practices with identical software will use different code sets for what they both call a cleaning. If a vendor hands you their mapping instead of asking for yours, that is a signal.
What to ask in the demo
Do not accept a slide. Ask them to do this on a call, against a test database:
- Call from a number that is not in the system. What happens?
- Call from a number attached to two family members. What happens?
- Ask for a same-day emergency as a brand new patient, when the practice policy is established only. Does it book you anyway?
- Book a new patient exam and a hygiene recall back to back. Do they get different lengths?
- Open the appointment in Open Dental afterward. Are the codes attached?
- Turn off the integration and call again. What does the patient hear, and what do you see?
If a vendor cannot run number six, they have not thought about failure, which means you will find out how it fails on a real patient.
One question that is not a call test. Open Dental's own API specification states that API developers should have a Business Associate Agreement in place with their clients. Ask any vendor touching your patient data for theirs, in writing, before a live call is ever forwarded. The requirement is stated on Open Dental's API specification page.
The realistic timeline
An Open Dental integration is not a signup form. Expect to spend time on: getting the system access to your server, mapping your appointment types and their lengths, supplying your procedure code sets, encoding your financial and eligibility rules, configuring the transfer destinations for calls that should reach a human, and then testing with real calls before you forward your main line.
The test call is the step practices most want to skip and the one most worth doing. A mapping that has not been verified by a live call and then checked in Open Dental is a mapping nobody has confirmed.
If you are not on Open Dental
Everything above about screening, appointment types, chair time, and escalation applies to your practice too. Those live in the AI layer, not the PMS layer.
What changes is the last mile. Instead of a direct write-back, the appointment is booked into your calendar, Google Calendar or Outlook, the patient record is pushed to your CRM, and your front desk gets a structured record. You still stop losing patients to voicemail and you still get correctly screened, correctly typed appointments. You do not get automatic write-back.
| Your practice management system | What happens when the AI books |
|---|---|
| Open Dental | The appointment is written directly into Open Dental with the appointment type, length, operatory, provider, time, and your CDT code set attached. |
| Any other system | The appointment is booked into your calendar, Google Calendar or Outlook, the patient record is pushed to your CRM, and your front desk gets a structured record. No automatic write-back. |
That is a real difference and worth knowing before you buy, which is why we would rather say it plainly than let you discover it in week three.
Frequently asked questions
Does an AI receptionist actually write into Open Dental, or just send a message?
Both patterns exist under the same word. A real write-back creates the appointment through the Open Dental API with the type, length, operatory, provider, time, and procedure codes attached. The weaker pattern sends your front desk a summary and a person retypes it. Ask which one you are buying, then ask to see the appointment open in Open Dental after a test call.
What has to be configured before the first live call?
Server access, your appointment types and their lengths, your procedure code sets, your financial and eligibility rules, and the transfer destinations for calls that should reach a person. Then a test call, checked inside Open Dental, before you forward your main line.
What happens when the Open Dental API is unavailable?
The lookup fails, and with it any rule that depends on knowing whether the caller is an established patient. The system needs a defined fallback, usually taking the request and handing it to a human, and you need to be told it happened. Ask a vendor to demonstrate the integration switched off.
Can this work if my practice does not run Open Dental?
Yes, with one difference. Screening, appointment types, chair time, and escalation all live in the AI layer and work anywhere. Direct PMS write-back is Open Dental only today. Every other practice gets calendar booking plus a CRM and front desk handoff. For the wider picture of what an AI receptionist does for a practice, see our guide for dental practices.
See it against your own schedule
Telvana built a direct Open Dental integration because dental scheduling is not generic scheduling. If you want to walk these six steps against your own appointment types, chair times, and code sets, book a demo and we will go through them with you.
