How an AI books an appointment into your practice diary
An appointment taken by telephone only reaches your diary if eight things happen in order: the call is answered, the patient is matched to a file, real availability is read, a slot is held, the patient confirms, the appointment is written, a confirmation goes out, and a record is left behind. An agent that skips the write step is a message service with a better voice, because a note asking you to ring Mrs Janssens back is still your work. In Belgium the hard part is not the conversation, it is the write: no Belgian dental practice management package publishes an open, documented REST API, so an integration runs through the online agenda in front of the software or through a conversation with the vendor. Tilcao writes into the practice’s own diary where such a route exists, and says so plainly where there is none.
Martin Michaux · Last updated
What has to happen before an appointment is really booked?
Eight separate things, each of which can fail on its own. The word “booked” hides all of them. A caller hears one smooth minute and a half; underneath it, the agent has identified a person, read a live diary, reserved a specific block of chair time, written a row into the practice system and waited for that system to answer. Only the last of those makes the appointment real.
Here is one ordinary call, the kind that arrives at 19:40 on a Tuesday. A patient rings for a cleaning next week. The table below is what happens between the first ring and the moment the front desk can forget about it, with what the caller actually experiences alongside.
Two details in that sequence are easy to skip and expensive to skip. The first is the hold. Reading availability and writing a booking are separate moments, and the gap between them is the conversation itself, which lasts thirty seconds or two minutes depending on how decisive the patient is. Without a hold, those seconds are open season: a second caller, or a colleague at the desk, can be offered the same minutes. The second is the confirmation message. From 1 October 2026 a dentist applying electronic third party payment must verify the patient’s identity at every contact, by eID, electronic foreigner card, Kids-ID or ISI+. So the confirmation should say, in one short line, to bring the card. That is a small thing that saves an awkward conversation at the desk.
| Step | What has to happen | What the caller experiences |
|---|---|---|
| The call is answered | The line is picked up, and the caller is told before anything else that they are speaking to an AI agent, with a way to reach a person. | A greeting, the practice name, and a plain sentence about what they are talking to. |
| The patient is identified | Two matching identifiers, usually full name and date of birth, are checked against the practice file. Nothing from the file is read back before both match. | Two short questions. No practitioner name, no reason for the last visit, no balance, until they have answered. |
| Availability is read | The diary is queried live for the right appointment type, its duration, the right practitioner or chair, and the practice’s own rules about when that type may be placed. | A short pause, then two or three real times. |
| A slot is held | The chosen block is reserved for the length of the call, with its own short expiry, so nobody else is offered the same minutes. | Nothing. A hold is invisible to the patient and visible to the team. |
| The patient confirms | The date, the time, the practitioner, the treatment and the duration are read back and accepted out loud. | The whole appointment, once, in plain words, before anything is written. |
| The appointment is written | The booking is written to the practice system, and the system answers with a confirmed appointment of its own. | A second short pause, then a confirmation in words. |
| A confirmation goes out | A message with the date, the time, the address, what to bring and how to cancel, plus a reminder scheduled before the day. | Their telephone buzzing before they have hung up. |
| A record is left behind | A structured summary and an audit line: who called, what was verified, what was read, what was written, and by which agent. | Nothing. This one is for the practice. |
What happens when a step goes wrong?
Something has to be said out loud, and it has to be true. Most of the work in a booking agent is not the happy path, which is short and dull. It is the nine or ten ways a call leaves the happy path, and what the caller is told in each of them. A supplier who will only demonstrate the smooth call has not shown you the product.
The rule underneath every row below is the same. The agent may say what it did. It may not say what it hoped it did.
| What goes wrong | What should happen |
|---|---|
| The patient is not on file | Collect what a new patient record needs and say that is what is happening. Where the practice allows it, create the file and book a first visit type. Where it does not, leave a task at the desk with everything already gathered, so the callback is one minute and not ten. |
| Two files match the same name | Do not guess. Ask one more identifier, the date of birth or the postcode. If it is still ambiguous, stop and hand over. An appointment written on the wrong file is worse than no appointment. |
| Nothing is free in the window the patient wants | Say so, offer the nearest real times in both directions, and offer the waiting list. Never place an appointment outside the practice rules to end the call pleasantly. |
| The diary cannot be reached | Say that the diary cannot be reached at this moment, promise no time at all, take the request and a number, and leave an urgent task. The thing that must never happen is a confident “that is booked” against a system that never answered. |
| The write fails after the hold succeeded | Release the hold, tell the patient the appointment did not go through, and offer one retry or a callback. A blind retry is how one patient ends up with two appointments, which is why a retry needs a key the system recognises as the same request. |
| The system replies “success” but did not book | Treat it as a refusal. Some booking interfaces report failure in a field inside an otherwise successful response, so the outcome has to be read from the body and not from the status code. |
| The patient changes their mind halfway | Drop the hold at once and go back to availability. A hold that outlives the patient’s interest is a slot nobody can book and nobody can see a reason for. |
| The line drops between the hold and the confirmation | Let the hold expire on its own clock and leave a note with the number and what was being booked. Nothing half finished stays in the diary. |
| The patient mentions pain | Stop booking and apply the practice’s own rule. No condition is named, no urgency is judged, no medicine is suggested. Out of hours that matters more in Belgium than elsewhere, because the wachtdienst, the dental on-call duty, covers weekends, public holidays and bridge days and not ordinary weekday evenings. |
Why should an agent confirm only what the system confirmed?
Because the sentence the agent says and the row in the diary are two different facts, and only one of them is a booking. Tilcao derives the booking outcome from what the practice system wrote back, not from the transcript. If the system did not return a confirmed appointment, nothing in the summary, the dashboard or the confirmation message says booked. The agent says what actually happened instead, which is usually that the slot is held, or that the request is with the front desk.
This sounds like a technicality until the day it is not. A language model is good at sounding finished. Left to itself it will round “I have sent the booking” up to “you are booked for Thursday at 10:30”, and the patient will arrive on Thursday at 10:30 to a chair that belongs to somebody else. Deriving the outcome from the write, rather than from the words, is the single design decision that keeps the record and the diary from drifting apart.
It is also what makes the audit trail worth having. Accountability under the GDPR is only demonstrable if it is recorded, so every call should leave a line showing who rang, whether verification passed, which fields were disclosed and what was written. A summary that reports what the agent said is a transcript with ambitions. A summary that reports what the system confirmed is a record.
Why is writing into Belgian dental software hard?
Because no Belgian dental practice management package publishes an open, documented REST API. That is the structural fact behind this whole subject, and it holds across vendor websites, developer portals and the public code registries. The packages Belgian practices actually run appear on the NIC/CIN register of software approved for MyCareNet, the national rail that carries insurability checks and electronic invoicing between practices and the mutualiteiten, the sickness funds. DentAdmin, CareConnect Dentist, Titanium, e-Dent, Octopus, Dent Open and Crossuite are all on that list. None of them publishes a booking interface a third party can read and build against. Crossuite is cloud native, which makes it the most plausible of the group to have one, but we have not found it published either.
In practice that leaves two routes, and it is worth knowing which one any supplier is describing. The first is the booking layer: the online agenda that sits in front of the practice software, that the practice already uses, and that the practice software already synchronises with. The second is a conversation with the vendor, which can end in a partner programme, a private interface or a direct arrangement with the database. Both are real. Neither is universal, and neither is one click.
Nor is a standard on the way. The national rails run by RIZIV/INAMI cover eAttest, eFact, eTarif, Recip-e, MyCareNet insurability and the GMD/DMG. They handle billing and insurability and they do not touch agendas. VDDS, the one de facto standard the vendors cite, connects the practice software to imaging, not to booking. The European Health Data Space regulation applies from 26 March 2027 with its first priority data categories from March 2029, and appointments are not among them. Anyone waiting for interoperability to solve this is waiting for something that is not scheduled to arrive.
- CLICKDOC, the online agenda built by DentAdmin and sold by CGM, publishes its API documentation openly. On this list it is the exception rather than the rule.
- Doctena runs no public developer portal, so a route through it begins with a conversation.
- Rosa appears on the MyCareNet register and offers practitioners a free calendar; its partner interface is not published.
- Helena Pro Calendar, formerly Progenda, advertises a full integration with CareConnect Dentist. That is the vendor’s own claim on the vendor’s own site, and it is worth checking against your own installation.
- Baltes practices are on a migration path into CareConnect Dentist, so the question for them is really a CareConnect question.
NIC/CIN list of MyCareNet-approved Belgian dental software, version of 10 March 2026
What should you ask a supplier who promises a one-click integration?
Ask exactly how. There is no universal one-click integration with Belgian dental software, because there is no universal interface to click into. A supplier who claims one is describing one particular booking layer, or a mirror calendar, or something that has not been built yet. All three answers are survivable. Not knowing which one you bought is not.
These are the questions worth asking before a pilot rather than after. They are short, they have factual answers, and a supplier who has done the work will enjoy answering them.
- Which exact system does this run through: my practice package, or the online agenda in front of it?
- Is that interface published, or is it a private arrangement with the vendor? May I see the documentation?
- Do you write into my diary, or into a copy of it that synchronises?
- What does the agent say to a patient when the write fails, and may I hear a recording of that happening?
- Which rights does your integration user hold? Read the diary, create and move appointments of the types I configure, cancel, and nothing beyond that, is the right answer.
- Who is your contact at my software vendor, and has the vendor agreed to this?
- What happens to a booking attempted during a maintenance window?
- How long is a slot held, and what releases the hold if the call ends badly?
Your own diary, or a second calendar beside it?
Writing into your own diary means the appointment exists once, in the place your team already looks. A second calendar means it exists twice, in two systems that agree with each other on a timer. The difference sounds administrative. It is the difference between an appointment and an argument in the waiting room.
Here is how the mirror produces a double booking, concretely. The copy learns what is free by synchronising every few minutes. Between one synchronisation and the next, both sides believe the same chair is free at 14:30. A caller takes 14:30 through the agent while the hygienist at the desk gives 14:30 to the patient standing in front of her. Neither of them did anything wrong. The next synchronisation finds two appointments on one chair and either refuses one, keeps both, or leaves the conflict for whoever opens the diary first in the morning.
The window is small, and that is exactly what makes it dangerous. It only opens when two bookings land close together, which is when the practice is busy, which is when nobody has time to check. The same lag works in the other direction: a cancellation taken at the desk does not reach the copy until the next round, so the agent keeps a slot hidden that has been free for an hour, or offers one that was taken an hour ago. And the failure is quiet. A missed call leaves evidence in the voicemail box. A double booking announces itself to two patients in a waiting room, one of whom takes it personally.
One honest qualification. A booking layer the practice already runs is not a second calendar. If the front desk works in that agenda every day, and the practice software already synchronises with it as a supported product feature, then writing there is writing where the team already looks, and the synchronisation is the vendor’s responsibility rather than a homemade bridge. The test is not whether two systems are involved. The test is whether anybody at the practice has to reconcile them by hand.
Questions practices ask
Does the appointment land in my agenda, or do I have to type it in afterwards?
It lands in the diary, during the call, wherever a route into that diary exists. Where no route exists yet, Tilcao says so rather than pretending, and leaves a structured task with the patient, the request and the times they preferred already collected. That is still work for the desk, and it should be described as work rather than as a booking.
How does the agent know which slots are actually free?
It reads the diary at the moment of the call, for the specific appointment type, its duration and the practitioner or chair that may perform it. It does not carry a picture of your week in its head. If the diary cannot be reached, it offers no times at all rather than offering times it cannot verify.
Can two callers be offered the same slot?
Not if the slot is held. The block is reserved as soon as the patient shows interest and released automatically if the call ends without a booking. Without a hold, two callers in the same minute can genuinely be offered the same chair time, which is one of the first things worth testing on a demonstration.
What happens if our practice software is down?
The agent still answers the telephone, and it says plainly that it cannot see the diary right now. It takes the request and a callback number and leaves an urgent task, and it promises no specific time. An agent that keeps booking confidently against a system it cannot reach is producing appointments that do not exist.
Which Belgian dental software can you book into?
There is no honest one-word answer, because no Belgian dental practice management package publishes an open, documented REST API. What exists is the online agenda layer in front of the practice software, and vendor-by-vendor conversations. What is possible for your practice depends on which agenda you actually run, so we look at your setup and say what is feasible before a pilot rather than after.
Is a mirror calendar ever acceptable?
Yes, when the practice team already works in it every day and the practice software synchronises with it as a supported feature. That is a booking layer, not a mirror. The version to avoid is a calendar that only the supplier uses, kept in step by a bridge nobody at the practice can inspect, because that is where double bookings are made.
Does the patient know they are speaking to an AI?
Yes, and they are told at the start of the call before anything else happens. Article 50 of the EU AI Act has applied since 2 August 2026 and requires a person to be informed that they are interacting with an AI system. An appointment booking agent is not a high-risk system under that regulation, and Tilcao claims no conformity assessment it has not done. Anyone who asks for a person is handed to one.
What does the practice see after the call?
A structured summary and an audit line. The summary records who rang, what they wanted, what the agent did and whether anything was handed over. The audit line records the verification outcome and which fields were disclosed. The booking outcome in both is derived from what the practice system wrote back, so the record cannot claim an appointment the diary does not have.
Does any of this touch RIZIV/INAMI billing or MyCareNet?
No. Tilcao never attests, never invoices and never writes in the clinical record. It is not a practice management system, it is not on the MyCareNet approved-software list, it holds no eHealth certificate and it needs none to book an appointment. Electronic invoicing has been mandatory for Belgian dentists since 1 September 2025 and stays entirely inside the practice software.
Can it move and cancel appointments, or only book them?
The same steps run in both directions. To move or cancel, the agent verifies two identifiers, finds the existing appointment, reads it back before touching it, writes the change and cancels the old reminder along with the new confirmation. A move that leaves the original appointment standing is the same double booking problem from a different angle.