Skip to content

Judge an AI receptionist by tasks finished, not calls answered

Count tasks finished, not calls answered. One dental practice read 15 months of its AI receptionist's calls: 41% of requests done, 65 asks for a person, zero live transfers. Patients were lost at dead ends, not to dislike of AI. Buy the schedule write and the handoff rule.

clinics · integration

Count the tasks it finished, not the calls it answered. Over 15 months, one dental practice's AI receptionist finished 41% of the calls where a patient needed something done. Callers asked for a person 65 times, and it transferred none of them live. The practice didn't lose patients because the receptionist was AI. It lost them at dead ends. So when a clinic buys an AI receptionist, it is buying two things: a write into its own schedule and a rule for handing off to a human. In our view the voice comes a distant third.

The numbers

On 25 September 2026, a staff member at a dental practice in Los Angeles posted in r/Dentists. They had read and sorted every call the practice's AI receptionist had handled over 15 months, 1,432 calls in all. The post doesn't name the vendor, and neither do we.

calls handled, 15 months                    1,432
silent or hung up at the greeting             709   (49.5%)
calls where the caller wanted a task done     637
  task finished                               263   (41%)
caller asked for a person                      65
  transferred live                              0
failed calls that complained it was AI          1 of 378
subscription cost per new-patient booking    ~$168

The source carries two caveats, and they matter. The author later built a replacement product and says so. And the 15-month figures come from the incumbent service's own call summaries. This is one practice, sorted by one person who has a stake in the result. We read it as a well-documented case, not a benchmark.

The strongest case for the AI receptionist

Start with the best version of the argument for it. An AI receptionist picks up at 2 a.m. and on a busy Monday morning. Voicemail does neither. The log even supports a point vendors like to make: callers didn't reject the machine. Of 378 failed calls, one complained that it was talking to an AI. If your worry is that patients hate talking to a bot, this practice's data says that isn't where it lost them.

So answering the phone has real value. The question is what happens after the greeting.

Where the patients went

The source names three dead ends. Each one turns a call into a message. In our reading, that makes it voicemail with a subscription attached.

  1. No live transfer. Callers asked for a person 65 times. Not one was transferred live.
  2. Confirming without writing. The receptionist told callers it was rescheduling them. Then the call ended as a message, and the appointment never moved.
  3. Sending callers to the website. Instead of handling the request on the call, the receptionist pointed callers to online booking.

The second dead end is the expensive one, and the cost isn't limited to patient experience. On 12 May 2026, a German court held a company directly responsible for its chatbot's false statements. The court said the bot is not a third party. Practitioners have converged on a rule that follows from this. Anything that turns into a promise (a date, a callback, a refund) either goes to a person, or the bot is allowed to say it only once the action is already reserved.

What you are actually buying

This part is our position. The voice is what vendors demo, and we think it matters least. Whether 41% turns into something better depends on two pieces of plumbing a demo doesn't show.

The first is the write. A reschedule is done when the practice system says so, not when the receptionist does. The order is simple, and it's easy to get backwards:

# backwards: speak, then try
say("Your appointment is moved to Thursday 10:00")
pms.reschedule(appt, new_slot)          # may fail; the caller has already hung up

# forwards: write, read back, then speak
pms.reschedule(appt, new_slot)
if pms.get(appt).slot == new_slot:
    say("Done. You're booked for Thursday 10:00")
else:
    handoff(reason="reschedule_not_written", appt=appt)

The second is the handoff rule. You draw it by the kind of commitment involved, not by how confident the model feels. Here is a sketch of the shape we would ask for:

handoff_rules:
  caller_asks_for_person:
    business_hours:   transfer_live
    after_hours:      queue_callback        # queued before the bot says "we'll call you"
  promises:
    covers:           [date, callback, refund, price]
    allowed_only_if:  action_already_written
  clinical_red_flag:
    example:          "face is swollen"     # the clinic owns the list
    action:           transfer_live
  never_counts_as_resolved:
    - sent_to_website
    - left_as_message

The same rule in our own clinic work

We ran into the same problem in a clinic system we built (the client is under NDA). There, the promise to the patient is small: exactly one reminder per appointment. A line in a schedule doesn't guarantee it. A mark written on each appointment record in the database does. The job can run once a day or once an hour, and the patient still gets exactly one reminder.

for appt in appointments_due_for_reminder():
    if not claim_reminder(appt):    # sets the mark on the record only if it is unset
        continue                    # already promised, already kept
    send_reminder(appt)

The check we run is the one this practice needed. We don't ask what the interface said. We ask whether it's written in the system.

The five-call test before you sign

This is the test we would run, and it doubles as a demo script. Run it yourself on the vendor's live line before you sign anything:

1. Ask for a person during business hours.  -> does a human pick up?
2. Ask for a person after hours.            -> is a callback actually queued?
3. Reschedule an existing appointment.      -> open your practice system: did it move?
4. Call in Spanish.                         -> does it handle the call or stall?
5. Say that your face is swollen.           -> does it escalate, or offer a cleaning slot?

Then ask for one number: the completion rate on calls where the caller wanted something done. Not the answer rate. If the vendor can't give you that number, our guess is you'll be working it out yourself a year from now, one call at a time, the way this practice did.

What would change our mind

Two things would. Logs from several practices showing high completion even without a schedule write or a handoff rule, which would mean the voice alone carries the result. Or a practice where missing transfers didn't cost it bookings. We haven't seen either. If you have that data, we'd like to read it.

FAQ

Isn't 41% fine for something that also answers at night? That 41% wasn't free. This practice paid about $168 in subscription for each new-patient booking. And the calls that failed didn't disappear quietly. The source traces them to three dead ends: no transfer, a confirmation that was never written, and a link to the website.

Do patients refuse to talk to an AI? In this log, almost never. One of 378 failed calls complained that it was an AI. What callers did instead was ask for a person, 65 times.

Should a clinic put AI on the phone at all? Our view: yes, if it writes into your practice system and hands off by rule. Without those two pieces, it turns calls into messages, and that's the job voicemail already does.

How far can I trust these numbers? It's one practice and one reviewer, who later built a competing product, working from the vendor's own summaries. Treat it as a well-documented case. Then run the five-call test on your own line.

What should I ask a vendor first? Ask for the completion rate, not the answer rate. Then, for every action the receptionist confirms, ask where that action gets written.

A related case

RE Intelligence, our own analytics product for the Dubai property market, follows the same principle. Every number comes from a deterministic database query, and the model only narrates what the data has already proved. The model doesn't state a number the database hasn't returned. You can see it at reint.ae. The short version of this piece is here: {{anchor_url}}.

If you have something worth building, we'd like to hear about it.

Sources