Updated 2026-08-01 · 3 min read
It's one of the most reasonable questions we get, and it usually comes from a practice that has things in order: I've had my program for years, my team knows it, my clinical notes are in there. Can't I just put the AI on top of it?
The honest answer: sometimes yes, it's rarely that simple, and there's a third way that almost everybody ends up taking.
Why «putting AI on top» sounds easier than it is
For an assistant to close an appointment — not take a message: close it — it needs four things against your current program: read treatments, durations and dentists; check what's free right now; write the appointment; and find out if somebody moves or cancels it from inside the program.
All four require your software to have an API open to third parties. And there's the problem: a good share of dental management programs don't offer one, or keep it for commercial agreements with specific partners. It isn't bad faith: it's their business model.
When there's no API, what you'll be offered is an assistant that converses beautifully and ends with «I'll pass this to the practice». That automates nothing: it moves the work, because reception still has to type the appointment in.
If a supplier promises to integrate with your program, ask them one thing: does the appointment get written into my calendar on its own, or does somebody have to transfer it? Everything else is secondary.
The three real options
Each has its place: the first fits when your program has an API and the volume justifies the development and its upkeep.
| A custom connector | An assistant that takes a message | An integrated system | |
|---|---|---|---|
| Requirement | Your program must have an API | None | None |
| Does it close the appointment itself? | Yes, if the API allows it | No: somebody transfers it by hand | Yes |
| Up-front cost | Development (thousands) | Low | None |
| Ongoing cost | Maintaining it every time the API changes | Subscription + your team's time | Fixed subscription |
| Who fixes it if it fails | Whoever developed it | — | The supplier |
| Change program? | No | No | Yes |
The third way: coexist, don't migrate in one go
What almost everybody does is neither of the previous two. The Google Calendar sync works both ways: what the assistant books appears in the calendar within seconds, and what your team blocks there is respected and never offered to anybody. If your practice already lives in the calendar on their phones, the day doesn't change.
That allows a real period of coexistence: for the first weeks the assistant only handles WhatsApp and Instagram while your program stays your program; then the phone is switched on, and only for the calls you can't take. And the first month is free, with no lock-in.
The patient base is imported by CSV: it only adds new records, never overwrites an existing one. The clinical record stays in your clinical program, which ClaudIA works alongside.
What you gain by having it all in one place
One calendar for every channel: WhatsApp, Instagram and the phone book against the same times, so two patients never get the same slot. And one party responsible: if something goes wrong, nobody has to work out whether it was the connector, the program or the assistant.
Your data, always yours: patients, appointments and history are exported from the dashboard whenever you like, with no lock-in.
How to decide it in five minutes
Ask your current supplier, in writing, two things: do you have a public API for checking availability and creating appointments from another tool? And is it documented, and can I give it to whoever I choose?
If the answer is yes to both, you have an option many practices don't: keep your program and build the AI layer on top. If it's no — and it usually is — the real choice isn't integrate or change, it's carry on answering yourselves or change.