Clinic chatbots in Singapore: appointments, reminders and the triage line you must not crossClinic chatbots in Singapore: appointments, reminders and the triage line you must not cross

A GP, dental, aesthetic or TCM front desk handles two very different kinds of work through the same channels. The first is administrative: can I come at 4.15 instead, do you take my company's panel, how much is a consultation, are you open on the public holiday. The second is clinical: whether a symptom is serious, whether a medicine is safe to combine, whether a child needs to be seen tonight. A good receptionist switches between the two all day — and passes the second kind to a clinician without ever answering it personally.

A clinic chatbot is worth considering only if it copies that discipline exactly. The administrative layer is repetitive, rule-bound and constantly interrupted, which makes it automatable. The clinical layer is none of those things. Every design decision that follows comes from keeping the two apart.

The safe territory is scheduling and verified fact: offering and confirming slots within rules the clinic sets, rescheduling within the same rules, sending reminders, answering questions from a maintained register of approved facts, and collecting the details a receptionist needs before a person takes over. In Singapore most of this traffic arrives over WhatsApp; business-initiated messages such as reminders run under Meta's current template and messaging rules, which the implementation must follow rather than assume away.^[1]

The fact register matters more than the model. Opening hours, holiday closures, address and parking, published consultation fees, accepted panels and schemes, what to bring for a first visit — each fact needs an owner and a review date. Outside the register, the correct answer is a handover, not a plausible guess; a chatbot that improvises a price or a panel arrangement creates front-desk work instead of removing it.

• Book, confirm and reschedule routine appointments within clinic-defined calendar rules.
• Send appointment reminders with a confirm-or-reschedule path.
• Answer opening-hours, location, published-price and panel questions from approved facts only.
• Collect name, contact, preferred slot and whether the patient has visited before, then hand over.

The hard boundary is absolute. The assistant must not interpret symptoms, comment on medication, estimate urgency, reassure, or discourage a visit. "Is this mole anything to worry about", "can I give both medicines together" and "do I need to come in tonight" all look like enquiries; every one is a clinical judgment. Even repeating a public health FAQ becomes advice the moment it is offered to a specific patient about a specific complaint.

The safe behaviour is a fast, visible route out: any message containing symptom, medication or treatment content goes to staff immediately, with the conversation attached, and the patient is told a person will respond. This is the bounded-autonomy, human-accountability shape Singapore's agentic AI governance framework recommends — permissions end well before the consequential judgment, and a named person owns what happens next.^[5]

Emergencies get a deflection, not a dialogue. The assistant should recognise emergency language and respond with a single clear instruction to call 995 or go to the nearest A&E — then stop. No follow-up questions, no data collection, no attempt to be helpful in a lane where seconds matter.

Put the split on paper before any vendor demonstration, and make it part of the scope the supplier signs. The table below is a starting point for a typical front desk; your clinicians should edit it, because the boundary is a clinical governance decision, not a technical one.

A booking flow is a state machine with a clinical escape hatch at every step. The assistant's job is to keep the administrative rail moving and to leave it instantly when the message stops being administrative.

1. Step 01

   Classify first

   Decide whether the message is administrative, clinical or emergency before generating a single word. Clinical and emergency content exits the flow immediately.

2. Step 02

   Offer supported slots

   Present options only from the live calendar and its rules — never invent availability or promise a specific clinician the rules do not support.

3. Step 03

   Collect the minimum

   Name, contact number, preferred slot, and whether the patient has visited before — no identity numbers, no symptom descriptions, nothing collected "in case it is useful".

4. Step 04

   Confirm and record

   Write the booking to the system the clinic already trusts, and tell the patient exactly what was booked, where and when.

5. Step 05

   Remind with an exit

   Send the reminder at an agreed time with one-tap confirm and reschedule paths, so a change of plan becomes a filled slot instead of a no-show.

6. Step 06

   Hand over cleanly

   When anything falls outside the rules, pass the conversation to staff with context — and stop automated replies while a person is handling it.

If a clinic automates only one thing, it should be reminders. Missed appointments waste clinical time, and a reminder that carries a genuine reschedule path converts some silent no-shows into moved appointments — capacity the clinic gets back. Vendors like to quote dramatic no-show reductions; treat those as marketing. Measure your own no-show rate for a few weeks before launch, change nothing else, and read the difference — your own baseline is the only statistic worth acting on.

Timing and tone are operational decisions the scope should record: how far ahead the reminder goes, whether a second is sent, what happens when a patient taps reschedule, and quiet hours during which nothing is sent. Reminders are business-initiated messages, so they must follow the platform's template approval rules — a mechanical detail that decides whether the reminder arrives at all.^[1]

Even a purely administrative chatbot will receive clinical information, because patients volunteer it — a symptom in a booking request, a medication list in a reschedule message. Health information sits among the most sensitive categories of personal data, and the PDPA's obligations — purpose, notification, consent where required, protection, retention limits, access and correction — apply to every message the assistant touches, including when a service provider processes it on your behalf.^[2]

The design response is minimisation and explicit paths: collect only what the next step needs, keep chat transcripts out of analytics and marketing tools, set a retention period after which conversations are actually deleted, and restrict who at the clinic and the supplier can read message content. PDPC's advisory on common data-protection lapses is a practical checklist for the mundane operational failures that chat systems accumulate.^[3]

Two conditions belong in the written scope in plain language. First, supplier terms must exclude patient conversations from training shared models, and the configuration that enforces it should be named — PDPC's guidance on personal data in AI systems makes accountability for these choices the organisation's, not the vendor's.^[4] Second, healthcare licensing and professional-conduct obligations sit above anything a chatbot supplier can advise on; confirm those with your own professional advisors before launch, not after.

Finally, treat every patient message — text, links, forwarded content — as data, never as instruction. A message telling the assistant to ignore its rules or reveal another patient's booking must have no effect; that is a property of the permission layer, not the prompt, and OWASP's prompt-injection guidance describes the working defences.^[6] Practically: a narrow connection to the calendar and fact register — never a general login to the clinic-management system, and no path into clinical records.

Plenty of clinics should not buy this. If one receptionist comfortably handles the phone and knows the regulars by name, an assistant adds a layer without removing work. If your patients book by phone and prefer it, a WhatsApp flow serves the clinic's curiosity rather than its patients. And if your clinic-management software already sends appointment reminders, switch that on and measure it first — the largest single benefit may already be included in software you pay for.

The honest trigger points are volume and dropped work: messages going unanswered during consult hours, no-shows with no reminder system, or the same twenty questions consuming hours every week. If you are unsure which side you are on, our Assistant Finder is a deterministic questionnaire that will happily conclude you do not need us yet.

A credible clinic engagement is scoped in writing before anything is built: the fact register and its owners, calendar rules, the clinical-boundary list your clinicians have signed off, escalation destinations, emergency deflection wording, data fields collected, processors and storage locations, retention and deletion, the shared-model training exclusion, and platform messaging fees as a separate line.

This shape is our Customer Enquiry Assistant package with clinic-specific boundaries. Indicatively, setup runs S$3,500–7,500 depending on systems and scope, with monthly care at S$349–899 covering source maintenance, monitoring and boundary reviews; the written scope carries the fixed quote and names messaging and usage fees. The boundary work — deciding what the assistant must never say — is the part that takes judgment, and it is the part that makes the rest safe to run.