AI receptionist for clinics: a practical guide

An AI receptionist is software that reads a patient message, works out what the patient wants, answers it from material the clinic has approved, and hands the conversation to a human when it should not answer. That last clause is the whole product. Everything else — channels, integrations, dashboards — is plumbing around a single question: does this system know the difference between what it may say and what it must not?

This guide covers what the category actually does, the four things it reliably gets wrong, how to evaluate a vendor without relying on a demo, and what a careful rollout looks like. It assumes you run a real clinic with a real front desk, not a thought experiment.

What an AI receptionist does

Strip away the marketing and the job is narrow. A patient sends a message on Instagram, WhatsApp or Messenger. The system has to do four things in order, and each one can fail independently.

1. 01Understand the message

   Including the ones that are not text. Patients reply to a story with “how much?”, send a voice note in a dialect, or forward a photo of a competitor’s price list. A system that only handles well-formed typed questions handles perhaps half of a real inbox.

2. 02Decide whether it may answer

   This is the safety gate. Pricing, opening hours, preparation instructions, parking, treatment descriptions: answerable. Diagnosis, dosage, whether a symptom is normal, whether a medication interacts: not answerable, ever, by software.

3. 03Answer from an approved source

   Not from the model’s general knowledge of dermatology. From your treatment pages, your price list, your aftercare sheets. If no source covers the question, the correct output is “I don’t know, let me get someone”, not a plausible paragraph.

4. 04Act, or hand over

   Hold a slot, confirm an appointment, log the enquiry — or move the thread to a human with the transcript, the patient record and the reason for handoff already attached.

A system that does the first three and skips the fourth is a chatbot with better grammar. The handoff is what makes it usable in a clinic.

What it must never do

There is a line, and it is not subtle. On one side is information your clinic has already published in writing and stands behind. On the other side is clinical judgement about a specific patient. Software belongs entirely on the first side.

Grounding: why “trained on your data” is not the answer

Vendors describe two very different mechanisms with the same phrase. It is worth being pedantic here, because the difference decides whether the system can hallucinate your prices.

• Fine-tuning adjusts the model’s weights on your material. The knowledge becomes diffuse and un-citable. When you change a price, you cannot change the model — you retrain it, and you cannot point at which reply came from which document.
• Retrieval keeps your material as documents. At the moment a patient asks, the system searches your material, pulls the passages that match, and asks the model to answer using only those passages. Change the document, and the next reply changes.

For a clinic, retrieval is the correct architecture, for a reason that has nothing to do with accuracy scores: it is auditable. When a patient says “your assistant told me the package was 8,000”, you need to be able to open that conversation and see the exact card the answer came from. With retrieval you can. With fine-tuning you are reduced to arguing about probability.

This is also why the honest version of the product is unglamorous. The quality of an AI receptionist is mostly the quality of the knowledge base behind it — which is a documentation problem your clinic owns, not a modelling problem the vendor solves. We wrote up the process in building the knowledge base an AI can actually answer from.

The four things these systems reliably get wrong

1. Confident answers to questions no document covers

Ask about a treatment you do not offer and a poorly-built system will describe it enthusiastically. Ask for a price that is not in the catalogue and it will produce a number in the right range. The fix is architectural, not a prompt: retrieval has to return a confidence, and below the threshold the system must abstain rather than improvise.

2. Stale pricing and availability

A price list uploaded as a PDF in March is wrong by June. Anything that changes — prices, promotions, which doctor works which day — should be read from the system of record at answer time, not copied into the knowledge base. Static documents are for things that change yearly: aftercare, preparation, policy.

3. Handling the second language badly

In this region patients write in Arabic, in English, in a mix, and in Arabic typed with Latin characters. Systems that detect a language once at the start of the thread and commit to it will answer the wrong way for the rest of the conversation. Detection has to run per message, and the knowledge base has to be reviewed in every language you reply in — a treatment page translated by the model itself is an unreviewed clinical document. More on this in Arabic, English, and everything in between.

4. Escalating too late

The common design escalates when the model reports low confidence. That is backwards for clinical content, because a fluent wrong answer is exactly the high-confidence case. Escalation should be triggered by topic first — anything clinical routes to staff regardless of confidence — and by confidence second. We set out the full rule set in when an AI should stop and get a human.

How to evaluate one without trusting the demo

Every demo works. The vendor picked the questions. Take control of the evaluation by supplying the inputs yourself — this takes an afternoon and tells you more than a six-week pilot run on the vendor’s terms.

• Bring 40 real messages from your own inbox, unedited — including the vague ones, the voice notes, the one-word replies and the angry one.
• Include five questions your knowledge base does not answer. Correct behaviour is an explicit “I don’t know”, not a graceful improvisation.
• Include three clinical questions of increasing subtlety. “Is this infected?” is easy to catch. “Should I keep using the cream you gave me?” is the one that separates products.
• Ask to see, for any answer, the exact source passage it came from. If the vendor cannot show it in the interface, it does not exist.
• Change a price in the source system mid-demo and ask the question again. Watch how long the old number survives.
• Ask what happens at 3am when the system escalates and nobody is on shift. A queued conversation with an honest holding reply is a valid answer; silence is not.
• Ask who can read patient conversations, and get the role model in writing.
• Ask for the export. Your conversations, your knowledge base, in a format you can read without their software.

What it costs, honestly

Pricing in this category is quoted rather than published, for a defensible reason and an indefensible one. The defensible reason is that cost genuinely tracks message volume, channel count and integration work, which vary by an order of magnitude between a single clinic and a hospital group. The indefensible one is that opacity suits vendors.

What you should insist on seeing before signing: the unit that drives the price (conversations, messages, or seats), what happens when you exceed it, the one-time integration cost stated separately from the subscription, and who pays for the WhatsApp conversation charges that Meta bills through the provider. That last one surprises people.

The comparison that actually matters is not against other software. It is against the cost of the enquiries currently going unanswered — which you can estimate from your own inbox in about ten minutes with the missed-message calculator.

A rollout that does not put patients at risk

The mistake is switching it on across every channel at once and watching the dashboard. Stage it so that the failure modes surface while a human is still reading every message.

1. 01Weeks 1–2: draft mode, one channel

   The agent composes replies but sends nothing. Your front desk reads each draft, sends, edits or discards it. You are measuring how often the draft was usable as written — and every edit is a defect in the knowledge base, not in the model.

2. 02Weeks 3–4: live on informational questions only

   The agent sends its own replies for hours, location, preparation, aftercare and treatment descriptions. Pricing, booking and anything clinical still route to a human. Narrow scope, real traffic.

3. 03Week 5: pricing and booking

   Only once pricing is read live from the catalogue and slots come from the practice management system. This is the step that requires the integration to be genuinely finished, not demonstrated.

4. 04Week 6 onward: widen by evidence

   Review escalations weekly. Topics that escalate repeatedly and are always answered the same way by staff are candidates for a new knowledge card. Topics that escalate because they are clinical stay escalated permanently.

Note what is not in that plan: a target for “percentage of conversations fully automated”. Set that target and you will get it, by automating conversations that should have gone to a person. Measure first response time, escalation accuracy and booking rate instead — see the five numbers worth tracking on a clinic front desk.

When you should not buy one

Three cases, stated plainly, because vendors rarely will.

• Your message volume is genuinely low. Under roughly twenty enquiries a week, a person answering their phone is cheaper, better and simpler. The value comes from volume and from hours you cannot staff.
• Nothing is written down. If your prices live in a WhatsApp group and your aftercare instructions are whatever the nurse says that day, an AI receptionist has nothing to ground on. Write the material first. You will get most of the benefit before any software is installed.
• You need it to give medical advice. If the problem you are solving is triage or clinical guidance, this is the wrong category and anyone who sells it to you as the right one is a liability.