Dentrix and an AI receptionist: how the handoff works

The gap your practice management system leaves open

A dental practice management system is good at everything that happens once a patient and an appointment exist — scheduling, recall, charting, claims, reporting, production analysis. What it does not do is answer the phone.

That means the whole platform sits idle for every call nobody picks up. Your production reporting, your recall lists, your new-patient counts — all of them are downstream of an event that happens on a phone line, outside the software entirely. A practice can run a very tidy schedule and still be leaking a meaningful share of its inbound demand, because the leak is upstream of the tool that measures everything.

An AI intake system sits in that gap. The question this page answers is what happens at the seam between the two: how much of what the system captured actually lands inside your practice management software, and how much of it a human still has to type.

Four levels of integration depth

The phrase "integrates with Dentrix" gets applied to all four of the following, which is why it is close to meaningless on its own. In ascending order of usefulness — and of difficulty:

What that means in practice

Three things are worth understanding before you assume level 4 is the goal.

• Levels 3 and 4 depend on access that is not ours to grant. Whether an integration path exists for your installation — and on what terms, at what cost, and with whose approval — is a question for your software provider. It is a commercial and licensing gate as much as a technical one, and no vendor can promise it on your behalf. Anyone who tells you they can is telling you something they do not know.
• Level 4 is the most fragile of the four. A system writing directly into a live schedule can create duplicate patients, book the wrong appointment type, assign the wrong provider, or occupy a slot that should have stayed open. Unwinding that in a busy week is worse than having a front-desk member confirm each booking. Fragility is a real cost and it is rarely mentioned in a demo.
• Most practices get the majority of the available value at level 1 or 2. This is the important one. The expensive problem was almost never data entry — it was the call going unanswered and the enquiry never being captured at all. A complete, structured record delivered within seconds of a 9pm call, that a front-desk member types in on Monday morning in ninety seconds, recovers nearly all of the value. Level 4 saves the ninety seconds.

Server-based software asks different questions than cloud

Dental practice management software has historically been installed on a server inside the practice, and a great many practices still run it that way, sometimes alongside or migrating toward a cloud-hosted arrangement. Which one you are on changes the integration conversation substantially, so establish it first.

If the software runs on a server in your building:

• Something has to bridge the gap between the internet and your practice network. A cloud-hosted agent cannot reach an on-premise database directly. Some form of local connector, agent, or gateway sits in between, and that component is a piece of software running inside your practice that somebody has to install, secure, update, and monitor.
• Your IT arrangement becomes part of the project. Whoever supports your server — an internal person, a dental IT provider, or your software reseller — needs to be in the conversation from the start. Integrations of this type fail far more often on IT approval and network configuration than on anything to do with the AI.
• Versions matter more than they do in the cloud. On-premise installations drift. Two practices running nominally the same product can be on different versions with different capabilities. A vendor who says "we support it" without asking which version you run has not checked.
• Uptime is now your responsibility as well. If the server is off, the connector is down, or the machine hosting it has been rebooted, writes fail. What the system does when a write fails — queue it, alert someone, fall back to a structured email — must be a defined behaviour, not an accident.
• Data leaving the practice network is a decision, not a detail. Patient information crossing that boundary has real governance implications, and they belong to your practice. Establish what is transmitted, where it is stored, and for how long, before anything is connected.

If the software is cloud-hosted, the network problem largely disappears and the question becomes purely one of permitted access: does an integration route exist for your plan, what is it allowed to read and write, who authorises it, and what are the rate and volume constraints. Simpler, but no less gated — and the answer still comes from the software provider rather than from us.

Duplicate patients and matching rules

This is where automated record creation most commonly goes wrong, and it is the failure that annoys a front desk most, because someone has to clean it up by hand later.

Any system permitted to create patient records needs an explicit matching rule and an explicit behaviour when the match is uncertain. The general shape that works:

• Phone number first. The strongest single identifier available on an inbound call, and the one the system already has without asking. It is not perfect — households share numbers, numbers get reassigned, and callers ring from a work phone — so it identifies a candidate, it does not confirm one.
• Then name and date of birth together. This is the confirming pair. Name alone is far too weak in a patient population that contains families, shared surnames, and common names. Date of birth is what separates a parent from a child at the same address and the same number.
• Treat a partial match as uncertain, not as a match. Phone matches but the name does not, or the name matches but the date of birth does not — those are ambiguous, and the correct behaviour is to flag for human review rather than to pick one.
• Never silently create on ambiguity. "It creates a new record" is the wrong answer to the ambiguous case, because that is exactly how a duplicate is born. The right answer is to hold the intake, attach it to the candidate as a suggestion, and let a person commit it.
• Decide what happens with families explicitly. A parent calling about a child is extremely common in dental and breaks phone-first matching immediately. The system should be capturing who the appointment is for as distinct from who is calling, and your rule should say what to do with that.
• Decide who wins on conflicting data. If the caller gives a different address or a different mobile than the one on file, does the system update the record, note the discrepancy, or ignore it? Silent overwriting of existing patient data is worse than a duplicate.

What a usable patient record actually needs

Integration depth is irrelevant if the intake is thin. A record your front desk has to call the patient back about has saved nobody anything, no matter how automatically it arrived. For a cosmetic dental enquiry, useful means:

• Urgency status, resolved first. Whether this call was urgent and how it was handled. If it was, it left the booking flow entirely and went to your escalation path — and the record should say so plainly.
• Identity fields that support matching. Full name, date of birth, best contact number, and email — captured well enough for the matching rule above to work rather than just well enough to call back.
• New or existing patient, and which clinician if existing. This changes routing, appointment length, and whether a record needs creating at all.
• Treatment interest, mapped to your actual menu. Not a generic category. It has to map to the appointment types and consultation lengths your schedule genuinely uses, or the booking is wrong even when the data is right.
• What the patient said, verbatim. A transcript and recording attached to the record, so the coordinator hears the original description rather than someone's compression of it.
• Timeline and payment intent. Why now, and whether they expect to use insurance or pay directly, including any plan details volunteered. The system notes what it was told; it does not verify coverage, check benefits, or quote out-of-pocket costs.
• Source of the enquiry. Which campaign, listing, or referral produced the call, captured at intake rather than guessed at in a marketing review three months later.
• Anything volunteered that a clinician should see. Logged and flagged for a person to review, never interpreted or acted on by the system.

The full intake design — including which treatments get a slot on the call and which are captured for review — is set out in cosmetic dental consultation booking, and the decisions there determine what any integration is actually writing.

What it cannot do

Being specific about limits is more useful than a feature list:

• It cannot assess a patient. It does not diagnose, evaluate symptoms, judge treatment suitability, or give dental advice. It applies triage rules your practice wrote and escalates everything else to a person. A clinician signs off on that escalation path before it takes a live call.
• It cannot verify insurance. It captures intent and notes plan details a caller volunteers. It does not check eligibility, confirm benefits, or quote out-of-pocket costs, and no reasonable vendor should claim their intake system does.
• It cannot invent access you do not have. If an integration route is not available for your installation, plan, or version, levels 3 and 4 are simply not on the table — regardless of what any demo appeared to show.
• It cannot resolve genuine ambiguity. A caller who is distressed, unclear, or describing something that maps to no known path should be escalated, not guessed at.
• It cannot fix a capacity problem. If your clinicians are already booked out, automating intake books consultations you then cannot honour, which is worse for patients than not answering.
• It cannot clean up an existing duplicate problem. If your patient database already has duplicates, matching rules will inherit that mess. Deduplication is separate work and it is not ours.

Questions to ask any vendor

Ask these before signing anything, of us as readily as anyone else. They separate a real integration from a screenshot:

1. Which of the four levels above are you actually proposing for my practice — not what is possible in general, what am I getting?
2. Have you built this for my exact software, version, and hosting arrangement before, or would mine be the first?
3. What access does this require, who has to authorise it, and whose job is it to obtain it?
4. If my system runs on a server here, what software would be installed inside my practice, who maintains it, and who is called when it stops?
5. Exactly what fields do you write, and what do you leave for my front desk to complete?
6. What is your matching rule, and what happens on an ambiguous match? If the answer is "it creates a new record", that is the wrong answer.
7. What happens to a call if the integration is down — does it fail silently, or fall back to a structured notification?
8. Show me a record created by your system in a real practice, with the practice's permission, rather than in a demo environment.
9. Play me a recording of your agent handling a caller it did not understand.
10. What does the patient hear if they call in pain? Describe the mechanism, not the intention.

The last two are the most revealing in the list, and the ones most vendors will not answer with something real.

A sane rollout order

The rollout that fails is the one that goes live on every call and writes to the schedule from day one. The one that works is narrow, reversible, and boring:

1. After hours, notification level only. The agent covers evenings and weekends and sends structured alerts. Nothing touches your practice management system. If it goes wrong you have lost nothing you were not already losing, and you reverse it by changing your call forwarding back.
2. Move to a structured handoff. Once the transcripts read well for a couple of weeks, formalise the output so your front desk keys in a consistent record each morning rather than reading alerts. For a large share of practices this is the end of the road, and that is a legitimate place to stop.
3. Add overflow coverage. Catch the second and third simultaneous daytime call — in dental, disproportionately the elective enquiry arriving while the desk is dealing with an emergency.
4. Consider middleware. Only if there is a queue your team genuinely works from and the manual keying has become the actual bottleneck.
5. Consider direct record creation. Only if the access exists, only after the previous steps are stable, and only with a person confirming every created record for the first few weeks. Most practices never need this step, and we would rather tell you that than sell it.

Common questions

Go deeper