Every AI receptionist page makes the same promise: it books appointments. Almost none of them tell you what that means in the system you actually use.
The distinction that decides whether the product works for a clinic is not price, voice quality, or how many languages it speaks. It is this:
Does it read your calendar, or write into it?
Reading is easy. Writing is the product.
Reading means the AI can see when you are free and say so on the phone. It is straightforward to build. Most calendar APIs will hand over availability with very little work.
Writing means the appointment exists in your system before the caller hangs up: attached to the right patient record, the right practitioner, the right appointment type, the right duration.
Only the second one removes work. The first converts a phone call into a task for whoever is on the desk tomorrow, which is the job you were trying to stop doing.
When a vendor describes its integration purely in terms of "checking your availability", that is usually the whole story.
What a real write-back has to get right
Four things, and each has a failure mode that looks fine in a demo.
The patient record. A returning patient must be found, not created again. Get this wrong and every booking makes a duplicate, splitting one person's history across two records. This is a real, common defect. We shipped it ourselves in an early version of our Cliniko adapter and had to go back and fix it.
The appointment type. Practice systems attach duration and often price to the appointment type, not to the words the receptionist typed. Book a 60-minute initial assessment as a generic slot and the diary quietly says 30 minutes. The practitioner finds out at the appointment.
The practitioner. In a multi-practitioner clinic, availability is per person. An integration that treats the clinic as one calendar will offer slots that do not exist.
Whether the service is bookable at all. This is the one that catches everyone. In some systems a service that is not flagged as available for online booking simply returns no availability through the API: no error, no warning. The integration reports itself connected and never offers a single slot. We hit exactly this in Cliniko, and it cost us real time before we found it, because nothing anywhere says "this service is hidden".
Where Remi actually stands: the honest list
We publish this the way we would want to read it, because "integrates with 12 systems" is a claim that costs a vendor nothing to make.
Verified against live accounts:
- Google Calendar: the default, and the fallback for everything else.
- Cliniko: verified end to end on a live account. That verification found three real bugs, including the duplicate-patient problem and the hidden-service trap above. Both fixed.
- Acuity: verified, including a real booking taken over the phone. One thing worth knowing if you use it: create one appointment type per service, or the diary misreports both duration and treatment.
Built, not yet proven on a live account:
- Nookal: the adapter is written against the published API but has not been run end to end on a real account. We will say so until it has.
- Pabau: built and explicitly unverified.
Read-only, and this one deserves the detail:
- Fresha: Fresha has no public booking API, so nothing can write into it, us included. What Remi does instead: it reads your Fresha appointments through the calendar Fresha one-way-syncs into, so it will never offer a slot on top of an existing Fresha booking, then leaves your front desk a task to key the new booking in.
That is precisely the reading-not-writing gap this whole page is about, and we have it too. The difference is that we are telling you before you buy rather than after. If Fresha opens partner API access, it becomes a real write integration and nothing else changes.
Not supported today: Semble, Jane.
If you are on Semble or Jane, we would rather tell you now than during onboarding.
What to ask before you switch
- Can you create an appointment in my system, or only read availability?
- Show me a booking going into a test account: the patient record, practitioner, type and duration.
- What happens with a returning patient? Does it match, or create a new record?
- How does it handle multiple practitioners?
- What happens if the API is down mid-call? Does the caller get told, or does the booking vanish?
- Have you run this on a live account of my system, or is it built to the documentation?
- Do I have to move my diary to your calendar? If yes, that is not an integration.
Question six is the one that separates vendors. Building to an API's documentation and running against a live account are very different levels of confidence, and any honest supplier will tell you which one they have.
Why this matters more than the price comparison
A clinic evaluating AI receptionists usually compares monthly cost. But a booking that lands in the wrong place, with the wrong duration, under a duplicate patient, costs more than the difference between two price plans, and it costs it in the currency you have least of, which is front-desk attention.
The integration is the product. Everything else is packaging.
Related reading: AI receptionist for UK physio clinics, AI receptionist for UK dental practices, what a GP surgery needs from its phone system, and what an AI receptionist costs in the UK.