AI appointment booking: what has to be true before you turn it on

Letting software book appointments on your behalf sounds like an AI problem. It is almost entirely a data problem. The language part - understanding that "any chance you can fit me in Thursday afternoon?" means Thursday between noon and five - has been solved well enough for years. What goes wrong is that the software offers a slot that does not exist, and a real person turns up to a room that is already full.

This guide is the five things that have to be true before an AI can book for you, in the order they break.

1. Someone has to be able to do the work

The most common cause of a bad booking is not the AI. It is that the service being booked has nobody attached to it who can perform it.

If a new hygienist joins and nobody links them to "cleaning", the system has one hygienist for a service two people can do, and it will offer half the real availability. If the only person linked to "implant consult" leaves, the service quietly has no availability at all, and every enquiry about it gets told there is nothing free for the next month.

Before anything else, check that every service you let people book has at least one person attached, and that the attachment survives staff changes. This is the check that ages worst: it is correct on the day you set it up and wrong three months later.

2. Working hours have to mean something

Most systems store opening hours. Fewer use them for the thing that matters, which is whether a specific person is available at a specific moment.

A practice open 9:00-17:00 does not have a dentist available 9:00-17:00. The dentist has a lunch break, two days at another location, a holiday in October, and an hour blocked on Tuesdays for admin. If the booking engine reads the practice's hours rather than the person's, it will offer a Tuesday 14:00 that the person has never been free for.

The question to ask a vendor is not "do you support opening hours". It is: when I block an hour for one member of staff, does that hour disappear from what the AI offers?

3. The AI must read the same availability the booking page does

This is the one that produces the worst failures, and it is invisible until it happens.

Some systems have two paths to a slot: the public booking page reads the calendar, and the AI answers from a simplified copy or a cached summary. Those two drift. The page is right and the AI is wrong, or the reverse, and which one a customer gets depends on how they contacted you.

There is only one safe arrangement: one availability engine, and everything reads it. The AI, the booking page, and the person on the front desk should all be asking the same question of the same data and getting the same answer. If a vendor cannot tell you plainly that this is how theirs works, assume it is not.

In Frontiva the booking dialog inside a conversation reads the same availability endpoint the public booking page uses, so a slot the AI offers is a slot that exists. That is not a feature so much as a refusal to build the second path.

4. Two people must not be able to take the last slot

Two enquiries arrive within a few seconds of each other. Both are offered 14:30. Both accept.

This is a classic race, and it is not solved by being fast. It is solved by the database refusing the second booking, at the moment it is written, with a constraint rather than a check. Software that checks availability and then writes the appointment as two separate steps will double-book eventually, and it will do it on your busiest morning.

Ask a vendor: what stops two simultaneous bookings taking the same slot? A good answer mentions the database. A vague answer about "real-time sync" means a check-then-write, which is the thing that fails.

5. An empty calendar has to say why it is empty

When the AI offers nothing, the customer hears "we have no availability" and goes elsewhere. Often that is not what happened.

The real reasons are usually mundane: nobody is linked to the service, the staff member is not marked as bookable, no working hours have been set for the location, or the search window genuinely is full. Those need five different actions from you and they all look identical from the outside.

A booking system that says "no slots available" for all five is telling you nothing. One that distinguishes them turns a lost enquiry into a two-minute fix. This is worth checking in a demo: ask the vendor to show you what an operator sees when the calendar comes back empty.

What this looks like when it is working

A customer texts at 19:40, after you have closed. They ask for something Thursday afternoon. The AI reads real availability for the staff who can actually do that service, offers two genuine times, and holds nothing back. They pick one. The appointment is written once, with a constraint that would have refused a duplicate. The confirmation goes out immediately. Nobody on your team touched it, and nobody turns up on Thursday to find the chair occupied.

That sequence needs the AI to be good at one thing and your data to be right about four. Vendors demo the first. The four are what decide whether it works in month three.

A note on calendar sync

Two-way sync with Google Calendar and Outlook is what most practices ask about first, and it is worth being precise about what it buys you. Sync keeps an external calendar in step with your booking system. It does not create availability, and it does not fix any of the five problems above. A practice whose services have no staff attached will have exactly the same failures with sync as without.

Get the five right first. Sync is a convenience on top of a correct system and a liability on top of a broken one, because it copies the wrong answer into the place your team actually looks.

The short version

Before you let anything book on your behalf, confirm that every bookable service has somebody who can do it, that individual staff hours drive availability rather than practice opening hours, that the AI and the booking page read one engine, that the database refuses double bookings, and that an empty result explains itself. The AI is the easy part. These five are the product.