AI for dental practice operations: use cases, limits and evaluation

Disclosure. This site is published by the company behind Dental Mastery, which sells marketing and patient enquiry services to dental practices, including AI-assisted enquiry handling. The criteria here apply to any supplier, including Dental Mastery.

Most of the AI pitched to dental practices is not about dentistry at all. It is about the front desk: answering the same questions, offering appointment slots, sending reminders and getting messages to the right person. Used well, that frees reception for the conversations that need a person. Used badly, it gives patients wrong answers with total confidence. This guide is about telling the two apart.

What this guide covers

Operational AI only: enquiries, booking, admin and messaging. Anything that touches diagnosis, treatment recommendations or whether a treatment suits someone is clinical, and it is outside the scope of this site and outside the scope of any tool I would put in front of patients.

Realistic operational use cases

• Answering routine questions on the website, by text or on the phone: opening hours, parking, access, how to register, whether you take new NHS or private patients, and your published fees.
• Capturing new-patient enquiries out of hours: name, contact details, the reason for contact in the patient's own words, and the best time to call back.
• Offering and confirming appointments of types you have explicitly allowed, such as a new-patient examination or a hygiene visit, within rules you set.
• Reminders and rescheduling: confirming attendance and moving routine appointments.
• Routing messages: sorting incoming messages so the right person sees each one, with urgent ones flagged at once.
• Drafting for staff: a first draft of a reply or a call summary that a team member checks before it goes anywhere.

The pattern is the same in each: repetitive, rule-based work where a wrong answer is easy to spot and put right. The prioritisation worksheet scores your own candidates against that pattern.

The limits

No clinical judgement

Under the General Dental Council's standards, a dental professional must obtain valid consent before starting treatment, explaining the relevant options and possible costs ^[6], and before treatment must explain the options with the risks and benefits of each ^[5]. Those conversations belong to a clinician. An enquiry tool can say that a consultation is the way to find out; it should never suggest what someone needs, whether they are suitable, or what their treatment will cost them.

Errors

These tools produce fluent answers whether or not the answer is right. Assume errors will happen, design so they are cheap (narrow scope, approved answers, a person on hand), and review conversations to find them.

Data protection and confidentiality

Under UK GDPR, personal data must be adequate, relevant and limited to what is necessary, and processed securely, and the controller must be able to demonstrate compliance ^[1]. When a supplier processes personal data for the practice, there must be a binding contract that sets out, among other things, that it acts only on your documented instructions and deletes or returns the data when the service ends ^[4]. The GDC is explicit that confidentiality covers personal details, medical history, what treatment patients are having and how much it costs ^[7]. An enquiry transcript can contain all of those.

Patients' right to a person

UK GDPR now defines a decision as based solely on automated processing where there is no meaningful human involvement, and as significant where it has a legal or similarly significant effect ^[2]. Where such a decision is made, the safeguards must let the person obtain human intervention and contest the decision ^[3]. Whether any step in your enquiry process is caught is a question for your own data protection advice. My design rule makes it largely moot: the tool does not make decisions about patients, and anyone can reach a person at any point.

Evaluating a tool before launch

1. Write down the scope: the questions it may answer, the appointment types it may book, and everything else.
2. Test it with real scenarios from your own enquiry log, not the supplier's demo script.
3. Include the hard ones: urgent pain, a complaint, a price question for treatment, a request for a person.
4. Check that it says it is an AI, in the first message, every time.
5. Get the processor contract, a list of sub-processors and the retention period in writing.
6. Check you can read every conversation and export the logs.

The full set of tests is in the AI receptionist evaluation checklist, and the rules for when to hand over are in human handover and booking-rule design.

Evaluating it after launch

Start narrow, for example out-of-hours enquiries only, and widen scope one step at a time. For the first weeks, read a sample of conversations every week, every handover and every complaint that mentions the tool. Keep a short error log: what it said, what it should have said, and what changed as a result. If the same error appears twice, narrow the scope until it is fixed.

What to measure

Measure the same things before and after, over comparable periods:

• new-patient enquiries captured, especially out of hours;
• how many of those booked, attended and started treatment;
• handovers raised, and how quickly a person picked each one up;
• errors found in the weekly review, by type;
• complaints and compliments that mention the tool;
• reception time spent on routine questions.

I would not judge a tool on how many conversations it held. Volume says nothing about whether patients were helped. For comparison, Dental Mastery keeps its own rules for AI narrow: its UK solutions page says that where AI is part of the agreed solution, it must disclose that it is an AI assistant, may support administrative enquiries within an agreed scope, and must not diagnose, decide clinical suitability or imply that it belongs to the clinical team.