A WhatsApp assistant for a clinic should do four things well: book and reschedule appointments, send reminders, answer the practical questions that fill a receptionist's day, and hand everything else to a person with the conversation attached. Everything clinical is "everything else". The checklist below is what we build against, from the channel and the consent line to the hand-off trigger and the numbers you sign before launch.
What patients actually ask
Read a week of a clinic's WhatsApp inbox and the messages fall into two piles. The first is administrative: is the doctor available on Thursday, how much is a consultation, where do I park, do I fast before the test, do you accept my insurance, can I move my appointment. The second is anything that touches the patient's health: a symptom, a result, a medication question, a complaint about a visit, a request for a certificate. The first pile is repetitive and safe to automate. The second pile is never automated, and the assistant's job there is to notice it fast and get a person into the conversation with the context.
Two facts shape the language design. Patients write in dialect and switch between Arabic and English inside one message; an assistant that replies in formal written Arabic reads as an auto-reply and gets ignored. And not everyone wants a bot: in one 2025 consumer study only 42% of shoppers said they were comfortable with chatbots. The hand-off is not a fallback feature. It is the reason the assistant is acceptable at all.
The checklist
Channel and disclosure
- WhatsApp Business API through a business solution provider, on the clinic's verified number. Never a consumer number, never a personal phone.
- The first message discloses that the patient is talking to an assistant and names the word that reaches a person ("doctor", "human", or the local equivalent).
- A consent line for processing the conversation for booking purposes, with a link to the privacy notice, before any personal data is requested.
- A working-hours notice: what the assistant does out of hours and when a person replies.
Booking and data 5. Integration with the booking system or calendar, not with the medical record. The assistant reads availability and writes appointments; it never reads or writes clinical data. 6. Data minimisation: the assistant asks for the name, the phone it already has, the service and the time. Nothing else. 7. Confirmation, reminder and reschedule messages using the platform's templates, in the language the patient wrote in. 8. A retention rule: conversation logs kept only as long as the booking purpose needs, then deleted, with the period written down.
Language 9. Replies in the patient's language and register: dialect for dialect, mixed for mixed, English for English. 10. A test suite built from real anonymised messages, including misspellings, voice notes and a photo of an insurance card. 11. Clinic terms, service names, doctor names and prices from a single source the clinic edits, never from the model's memory.
Boundaries 12. A rule-based classifier for the clinical pile: symptoms, results, medication, complaints, certificates, anything with an attachment. These never get an AI answer. 13. Hand-off pauses AI replies in that conversation until a person has responded, and the person sees the whole thread. 14. The assistant never quotes clinical advice, never confirms a diagnosis from a message, and never says "the doctor says" unless the doctor wrote it. 15. Payment disputes and refunds go to a person.
PDPL and hosting 16. Hosting in the jurisdiction the clinic's data-protection law expects; the model call documented as a transfer with a written risk assessment. 17. De-identification before any text reaches a language model: names, phone numbers and identifiers stripped, the conversation reconstructed only inside the clinic's system. 18. A written record of processing: what is collected, why, where it lives, who can see it, for how long. 19. Regulators' AI guidance expects disclosure and a human path; both are in items 2 and 13 and are tested, not assumed.
Measurement 20. A Day-0 baseline signed before launch: messages per week, median time to first reply, share answered out of hours, bookings completed by message, no-show rate, share of messages handed to a person. 21. One event per outcome: booked, rescheduled, cancelled, handed off, dropped. The clinic reads them monthly. 22. A 120-day report against the baseline. No vendor number before that, ours included.
Maintenance 23. A named owner for the price list, the schedule and the templates on the clinic side, and a maintenance plan on ours for the platform's rule changes, the model updates and the next feature.
The hand-off, specifically
The hand-off is where most clinic assistants fail, so it gets its own section. A good hand-off has three parts. First, the trigger: a classifier for the clinical pile, plus the patient's own request in any wording, plus any message the assistant cannot answer from the clinic's own content with confidence. Second, the pause: the assistant stops replying in that conversation and says a person will answer, with the expected time. Third, the context: the person opens the thread and sees everything, including what the assistant already said, so the patient never repeats themselves.
Measure the hand-off rate. If it is near zero, the assistant is answering things it should not. If it is very high, the clinic's content is too thin for the assistant to be useful. Both numbers are in the monthly report.
Integrations, in order
- The booking system. This is the one integration in the base package. If the clinic books in a spreadsheet, the first job is a calendar, and when to replace spreadsheets with a custom tool describes the decision.
- The clinic's own content. Services, prices, doctors, preparation instructions, insurance list, in both languages, in one editable place. The assistant answers only from this.
- Reminders. Template messages before the appointment, with a one-tap reschedule. Whether they reduce no-shows for your clinic is a number the baseline will answer.
- The medical record. Not connected. If a patient sends a result, the assistant hands off.
The five checks, in a clinic
Every assistant we build runs inside the same five checks as our clinical documentation work: the model never decides, data is stripped before it leaves, output is validated against a schema, every step leaves a trail, and both languages including mixed are handled and tested. The long form, written for the handover use case, is in Voice to SBAR: what a safe AI handover tool must do, and the product that proves we can build to it is Critical Care Copilot.
Cost and the first step
A website assistant over your own content starts at about USD 2,400. A WhatsApp assistant with one integration starts at about USD 4,800. Both ship with a maintenance plan of USD 250 to 900 a month. The first step is free: export a week of your WhatsApp inbox with names removed, send it through the contact page, and you get a written map of what the assistant would answer, what it would hand off, and a fixed price.
Sources
- Choosing a WhatsApp chatbot that handles Arabic customer support well, J. Servo, on dialect versus formal Arabic in chat. Vendor source.
- Arabic AI customer support: the complete guide, Thamra Group, on routing categories to AI or to people. Vendor source.
- WhatsApp chatbot for medical clinics: complete setup guide 2026, Ainisa, on hand-off triggers. Vendor source.
- Consumer and retail marketing insights, Google, 2025, for the share of shoppers comfortable with chatbots.
- AI chatbot development: WhatsApp API, Arabic NLP and PDPL, Logio Legion, on the compliance components of a production deployment. Vendor source.
