What a dental AI receptionist actually does: the work, the hand-offs and who operates it

A dental AI receptionist is software that handles the routine patient communication of a dental practice: answering questions, booking, reminders and confirmations, filling cancelled slots, bringing lapsed patients back and asking for reviews.

The useful ones don't just reply. They finish the job inside the practice system, and they hand the rest to a person. The name undersells that, and it hides the question that decides whether one works: who operates it once it is installed.

I lead the commercial side of Keishal. We operate this work for dental clinics in Spain, on top of the practice management systems they already use. This article breaks the front-desk workload into tasks, says which ones a written-channel agent can run end to end and where it must hand off, and explains why we think "AI receptionist" is the wrong mental model. Where a figure appears, the arithmetic is on the page so you can redo it with your own numbers.

What a dental AI receptionist is, in one paragraph

Strip away the marketing and a dental AI receptionist is three things: a channel the patient writes in (in southern Europe, usually WhatsApp), a language model that can hold a conversation, and a connection to the practice management system (PMS) that lets it read the agenda and write outcomes back. Remove the third piece and you have a chatbot. It can answer "what time do you open?", but it can't confirm, move or book anything, so a person still does the real work afterwards.

The front-desk workload, task by task

A dental front desk does far more than answer the phone. When we map a clinic's non-clinical work, it falls into six recurring tasks. Here is each one, with what an agent in a written channel can do on its own.

Read the right-hand column carefully, because every "yes" carries a condition. The agent runs the task end to end only when it can see real availability and write the result back. Without that connection, each "yes" becomes "it drafts a message and a person finishes the job".

Booking is the task most often described wrongly, so it is worth being precise about how it works in our case.

The patient asks their questions in WhatsApp and gets answers in the clinic's voice. When they want to book, they receive a calendar link with the available slots and pick the one that suits them, the way they would book a flight. The confirmed appointment is written into the clinic's agenda.

The agent never guesses a time from the chat. That design is deliberate: a patient choosing their own slot trusts it, and "what if it books me at the wrong time?" stops being a question.

Where a dental AI receptionist must hand off to a person

An agent that never hands off is a liability. The hand-offs are part of the design, and a buyer should ask to see them before anything else. In a dental practice, these go to a human:

• Anything clinical. Pain, swelling, bleeding after an extraction, a question about medication. The agent doesn't triage or advise. It passes the conversation to the team, and diagnosis stays with the dentist.
• Anything the clinic hasn't written down. If the answer isn't in the information the clinic has approved, the right move is to say a person will reply, not to improvise.
• Complaints and disputes. An unhappy patient, a billing disagreement, a problem with a past treatment. These need someone with authority to resolve them.
• A patient who asks for a person. That request is honoured, not argued with.
• Decisions only the clinic can make. An exception to a booking rule, a discount, fitting someone in outside the schedule.

There is a second kind of hand-off that gets less attention: the agent telling the patient what it is. In the EU, the AI Act's transparency rules point the same way, and in our case patients are told they are talking to an AI assistant. We treat that as a product fact rather than a risk to manage. A patient who knows what they are talking to, and can reach a person when they need one, trusts the channel more.

The arithmetic of the routine load

To see why this matters, size the routine load for one practice. The figures below are an illustrative example, not Keishal results. Swap in your own.

Take a clinic that sees 25 patients a day, 20 working days a month: 25 × 20 = 500 appointments a month.

• Confirmations that need handling. If 1 in 5 reminders gets a reply that needs action (a change, a question, a cancellation), that's 500 ÷ 5 = 100 conversations. At 3 minutes each: 100 × 3 = 300 minutes, or 5 hours.
• Inbound questions. At 15 written questions a day and 2 minutes each: 15 × 2 × 20 = 600 minutes, or 10 hours.
• Gap-filling. If 5% of appointments are cancelled late: 500 × 5% = 25 gaps. Offering each one to 3 patients at 2 minutes a contact: 25 × 3 × 2 = 150 minutes, or 2.5 hours.

That's 5 + 10 + 2.5 = 17.5 hours a month, about 52 minutes for every working day, before anyone has touched reactivation or review requests. None of it is hard. All of it is interrupted work, done between patients arriving at the desk and the phone ringing.

What the number doesn't mean matters too. Not every one of those minutes disappears with an agent, because the hand-offs above still need a person. What changes is that the person handles the exceptions instead of the routine.

The unworked part tends to be the outbound work, which nobody chases when the desk is busy. We wrote separately about why dental recall fails, even with recall software, and the arithmetic there is the same shape.

Why "AI receptionist" is a misleading name

"Dental AI receptionist" is what the category is called in English search, so we use it here. We don't use it to describe Keishal, for three reasons.

It suggests replacing a person. The human front desk stays. It is the part of the clinic patients remember, and it handles exactly the cases an agent shouldn't. What goes away is the repetitive layer underneath, so the person at the desk can deal with the patient in front of them.

It suggests the value is answering. Answering is the easy part, and models have done it acceptably for a while. The value is executing an outcome: an appointment confirmed and marked in the agenda, a cancelled slot filled, a patient who hadn't been back in two years booked for a check-up. An agent that answers well but writes nothing back has moved the work, not removed it.

It hides the outbound half. A receptionist mostly reacts. Four of the six tasks in the table start with the clinic, not the patient: reminders, gap-filling, reactivation and reviews. Outbound work is where clinics fall behind, because nobody is prompted to do it.

That is why we describe Keishal as a digital coworker for dental clinics: one system that operates the non-clinical side of the practice, not a person-shaped feature that waits for messages. We used to say "AI front desk" ourselves, and retired it for the same reasons.

Phone answering is a different, harder problem

In English, "AI receptionist" often means a voice product that answers the practice phone. It is worth being clear that this is a different problem from a written channel, and a harder one.

A phone call happens in real time, so there is no time to check the agenda slowly.

People interrupt, mumble, change their minds mid-sentence and call from noisy places. A patient who misunderstood a voice agent has no message to scroll back to.

And a call ends with no written record unless one is built. A written channel removes most of that: the patient can reread, the clinic keeps a transcript, and booking can move into a calendar the patient controls.

Keishal works in WhatsApp today. It doesn't answer the clinic's phone. If you evaluate a voice product, ask to hear real calls, not a scripted demo, and ask what happens when the caller goes off-script.

Who operates it: the question that decides whether it works

Every product in this category needs someone to run it after installation.

Someone writes and updates the information it answers from. Someone sets the booking rules: which treatments need which dentist, how long each slot is, what can't be double-booked. Someone reads the conversations it handed off, fixes the ones that went wrong, cleans the patient list and checks whether bookings actually turned into visits.

There are two ways to organise that work:

1. Software the practice operates. The clinic buys the tool and its team configures it, watches it and feeds it. This works when someone has the hours and enjoys the job.
2. A system someone operates for the practice. The provider runs it: the setup, the rules, the monitoring and the results. The clinic sees appointments and reports, not a dashboard to manage.

The first model fails quietly.

In a sales call in May 2026, the owner of a two-surgery family clinic in Spain told us, in our translation: "I'd rather call patients one by one myself than learn to use something new." That isn't a complaint about technology. It is a clinic owner telling you where their hours go.

For investors and partners, this is the structural point of the category. The model is service-as-a-software: the outcome is sold, and the provider operates the tool. Whether a dental AI receptionist is valuable depends less on the model behind it than on who is accountable for the work it leaves behind.

Questions to ask any dental AI receptionist vendor

1. Does it write to the practice system, or only read from it? Which systems does it connect to today, not on the roadmap?
2. How does a booking happen? Does the patient choose from live availability, or does the AI infer a time from the chat?
3. What does it hand off, and to whom? Ask to see the rules for clinical questions, complaints and requests for a person.
4. Who keeps the information and rules up to date? If the answer is "your team", count those hours too.
5. Does it do outbound work, or only respond? Reminders, gap-filling, reactivation and reviews are where the time goes.
6. How are patients told they are talking to an AI, and where is the data kept? The data protection details are best reviewed with your own specialist advice.

Where Keishal fits

Keishal is an autonomous system that operates the six tasks above in WhatsApp for dental clinics, on top of the PMS they already use. It reads the agenda for context and writes appointments and statuses back, with no migration. It runs suppression rules before any outreach, discloses that it's an AI, keeps patient data in the EU, and acts as a data processor under a data processing agreement with each clinic. The practice systems it connects to today are on our integrations page.

We serve clinics in Spain, and we are researching Portugal. If you want the market context, our map of the dental software market in Spain shows where this layer sits, and you can see how it works in a demo.

Workload figures are illustrative arithmetic, not Keishal results. Product description as of November 2026. The clinic owner's quote is from a Keishal sales call in Spain, May 2026, translated from Spanish.