Before this existed, I was the system
For four years I coordinated appointments for this group by hand — forty to seventy WhatsApp conversations a day. Quote a price from a catalogue of over a thousand services. Check the practice-management system for a slot. Type the booking in. Repeat.
It worked, and it didn't scale. An enquiry arriving at 11pm waited until morning. An enquiry arriving during a busy clinic hour waited too. Every one of those was a booking the group had already spent marketing money to generate.
What the assistant does
It runs on the clinic's own WhatsApp number and on their website. It answers from the live catalogue — real services, current prices — checks genuine availability, and takes a patient right up to the booking — pre-filled, so the patient's own submission is what creates it.
The interesting part isn't the happy path. It's the edges.
A pricing question, answered from live data
Illustrative example, not a real patient conversation. Written to show the shape of an exchange and the catalogue logic behind it — package contents, add-on pricing, and the slot duration a scan requires.
A clinical question, declined on purpose
Illustrative example. This boundary is deliberate, and it's where a great deal of the design effort went.
The line it doesn't cross
The assistant doesn't diagnose, doesn't recommend treatment, and doesn't judge whether a screening is clinically appropriate for a particular person. That isn't a limitation I worked around — it's the specification. Crossing it would make the system a regulated medical device under Singapore's Health Products Act, and more immediately, it would be the wrong thing to put in front of a patient.
So it's built to notice when a question stops being about logistics and starts being about medicine, and to hand over cleanly when that happens. Those handoffs push a notification straight to the clinic team.
The integration layer underneath
This is the part nobody demos, and it's where most of the work is. The assistant doesn't touch the clinic's systems directly. A separate service sits in between and does the operational work against Plato, the group's practice-management system:
- Reading genuine availability across four locations, rather than guessing at a schedule
- Creating and rescheduling appointments under the constraints each clinic and each service actually imposes
- Reconciling bookings against issued invoices, so what was booked can be matched to what was billed
- Holding the credentials — they're never exposed to the language model
- Writing every action to an audit trail the clinic owns
Running against a live practice-management system teaches you things a demo never will. Requests that succeed on the far side while reporting failure back. Retries tripping your own rate limiting. A webhook subscription that quietly removes itself after enough failed deliveries. Fields that look optional and aren't, where omitting one lands a booking in the wrong clinic's calendar.
None of that is exotic. It's what integration looks like once real patients depend on it — and it's the difference between a system that demos well and one that's been running for five months.
Coordinating a party nobody controls
Home screening was the hardest scheduling problem, because the binding constraint sits outside the clinic entirely: an external phlebotomy partner with their own calendar and their own working pattern.
The bridge syncs confirmed home-screening visits out to a shared calendar the partner already uses, so their schedule stays current without anyone re-typing anything. Patient identifiers are masked to the last four digits — enough to identify the visit, and nothing beyond that.
It went live in July, and it's the piece I'd point to for anyone wondering whether this approach survives contact with a third party's systems. Most clinic workflows don't stop at the clinic's own walls.
How it's kept honest
- It improved every month. 80% of conversations answered without a staff member typing in them in March; 92% in July. That didn't happen on its own — it took a couple of hundred refinements to the service knowledge and booking logic across May and June.
- Nothing ships untested. Automated tests across both services gate every deployment, and prompt changes run against a regression suite before they reach a patient.
- Everything is logged. Every action is written to an audit trail, with patient identifiers masked wherever they aren't needed.
- It can be switched off. A live corrections panel and a pause control mean a bad answer can be caught and the assistant stopped in minutes, not at the next deploy.
What it changed for the business
Enquiries now get answered at 11pm and during the clinic's busiest hour — which is when a good share of them arrive. The figures above show the revenue shift; what they don't show is that the manual channel, the one where enquiries came to me and I typed them into Plato one at a time, keeps shrinking as the system absorbs it.