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, and the first is perfectly legitimate if you love your program and it has an API.
| 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. If after a month it isn't adding anything, you switch it off and nothing has happened.
The patient base is imported by CSV: it only adds new records, never overwrites an existing one. The treatment history from your previous program can't be brought across automatically — everybody exports it their own way — and we'd rather say so before than after.
What you lose by putting everything in one place
It's one more supplier to depend on: if we don't convince you tomorrow, you take your exportable data but you change tools again, and that's a real cost.
And our way of organising a calendar is ours. It adapts to a fair amount, but if your practice lives on a very particular rule that no catalogue software respects, a custom build will give you more freedom: more expensive, slower to start and more yours.
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.