An AI receptionist for a clinic, bounded by consent

A clinic answering system is the only one in this library where getting it slightly wrong has consequences beyond a lost enquiry. The call volume is mostly administrative, the callers are patients, and the information they give is health information from the first sentence. All three change the specification.

Most of the volume is the diary

Before anything else, it is worth being accurate about what clinic calls actually are. The large majority are not new patients and not clinical questions. They are people moving, confirming or cancelling appointments.

That is the strongest case for answering coverage in this setting, and it is an unglamorous one. A patient who needs to move a Thursday appointment and calls at eight in the evening either reaches something that can help or gives up and does not turn up. The second outcome is a gap in the diary that was never filled and a patient who has drifted.

A system that does nothing but handle rescheduling reliably has already justified itself in most small clinics.

The advice boundary, drawn conservatively

The rule is simple to state and requires discipline to hold: the system does not answer anything about symptoms, medication, preparation for a procedure, or what a patient should do next.

Not a general reassurance. Not a description of what a procedure usually involves. Not an opinion about whether something sounds concerning. The boundary sits well short of anything a clinician would recognise as advice, because the failure mode is not a bad answer — it is a patient making a decision based on one.

What it does instead is redirect, quickly and without friction: take the name, note that the caller has a question about their care, get a callback number, and flag it for a person. That is the whole behaviour, and it should be the same behaviour for a mild question and an alarming one.

Testing this is not optional. Somebody should deliberately call in and try several phrasings of a symptom question, because a system configured from a general template will try to be helpful, and helpfulness here is the failure.

Everything it records is health information

A call record that says a named person rang about a named appointment is health information. So is a transcript. So is a recording.

That has practical consequences. Those records need to live somewhere the clinic controls rather than in a vendor’s account that cannot be exported. A retention period should be decided deliberately rather than by default. And anything captured on a call cannot be quietly repurposed into a messaging list, because consent for one is not consent for the other.

This is the same principle the clinic hub describes about consent generally: the discipline is not an afterthought to the build, it determines what the build is allowed to be.

The escape hatch matters more than the script

Patients tolerate an automated first thirty seconds. What they do not tolerate is being unable to reach a person when they need one.

The route to a human should be obvious, offered early, and genuinely functional during opening hours. A system that buries it, or that offers it and then takes a message anyway, will generate complaints out of proportion to the number of calls affected — and in a clinic those complaints reach a review page.

New patient enquiries are worth handling properly

The minority of calls that are new enquiries deserve more care than the diary calls. Those callers are choosing, often between two or three clinics, and the first interaction is part of the decision.

The useful configuration collects what the clinic would want to know anyway — what they are enquiring about, how they heard of the clinic, whether they have been before — and does it unhurriedly. It should not attempt to qualify anyone clinically.

Where it sits in the order

After consent is fixed. The clinic hub is direct about this: a clinic with an unclear consent position should resolve that before adding anything that captures more patient information. Phone coverage comes next, then automated reminders (the HVAC shops page covers the mechanics) against a properly consented list.

Who reads the escalations, and when

A clinic answering system produces two streams: routine diary changes that can be handled in a batch, and flagged calls that need a person.

The second stream needs an owner and a checking interval, agreed in advance. A flag that sits unread until the following morning is not an escalation. In a clinic this matters more than in a trade, because the caller may be waiting on something that affects their care, and because the complaint that follows is public.

The rule worth setting is simple: anyone flagged for a person is contacted the same working day, and the system tells the caller that.

Language, and who the callers are

A substantial share of patients in San Diego are more comfortable in Spanish, and a clinic answering system that handles only English is turning away the callers it least wants to lose.

The requirement is the same as for the website described on the painting page: written rather than machine-translated, because clinical and administrative vocabulary is exactly where automatic translation fails. A caller who reaches a system that switches languages competently is receiving a signal about the clinic that no amount of marketing conveys.

What it should never become

One final boundary, worth stating separately because it is the one that drifts.

The system is administrative. It is not a first point of clinical contact, it is not triage, and it should never be described to patients as though it were. A clinic that markets an automated line as a way to get advice has created an expectation the system is not permitted to meet, and the gap between the expectation and the behaviour is where the harm sits. The clinic hub covers the consent discipline that sits underneath all of this.

The demos include a receptionist you can push at, and starting a project begins with the boundary rather than the features.