Can an AI receptionist actually book appointments?

Yes. But "books appointments" covers two very different products, and the gap between them is where practices get disappointed.

The two things that both get called booking

Collecting a request. The AI has a conversation, gathers a name, a service and a preferred time, and hands your team a note: "Wants a cleaning, prefers Tuesday mornings." Someone then opens the calendar, finds a slot, and calls back.

That is lead capture with extra steps. Useful, but the customer does not have an appointment and does not think they do, which is its own problem when they turn up.

Writing to the calendar. The AI computes what is genuinely available, offers real slots, takes one, and the appointment exists. The customer gets a confirmation because there is something to confirm.

Only the second removes work from your front desk.

Why the second one is hard

Computing real availability is not "find a gap in the calendar". For one appointment you have to know:

• Which staff can perform this service, because not everyone can.
• That staff member's working hours at this location, which are not the location's opening hours.
• Their existing appointments, including the ones booked thirty seconds ago.
• Time off and holidays.
• Buffers before and after: a room to turn over, notes to write.
• The duration of this specific service, not a default slot length.
• All of it in the location's timezone, so a daylight-saving change does not move things.

Miss any one and the system offers a slot that is not really free. You find out when two people arrive for the same appointment.

The question that separates the two products

Ask a vendor: "What happens if two people accept the same slot at the same moment?"

The answers you will hear:

• "That won't happen." It will. Two people clicking the last Tuesday 2pm within the same second is ordinary on a public booking page, and it is exactly when it happens.
• "We check availability before booking." This is the common answer and it is not sufficient. Between the check and the write, the other request does the same check. Both see a free slot. Both write.
• "The database rejects the second one." Correct. The guarantee has to live where the write happens, not in the code that decides to write.

The distinction is not pedantry. Application-level checking is usually fine, which is worse than never working, because it fails under exactly the load that means business is good.

What the AI needs to know beyond the calendar

Booking is not only availability. A customer asking for "a cleaning next week" needs:

• Which service that maps to in your list, including the ones with confusing names.
• Whether they are new, since new-patient appointments are often longer and need different paperwork.
• How long it takes and what it costs, if they ask.
• What to do when nothing fits: offering a waitlist or the next available beats "nothing is free, call us".

An AI that can only read a calendar answers half of these.

What to test in a demo

1. Book something. Then open the staff calendar and confirm the slot is actually blocked.
2. Ask for a time that is not available. It should say so and offer alternatives, not invent one.
3. Ask for a service only one staff member does, on a day that person is off. It should not offer it.
4. Book two things back to back and check the buffer was respected.
5. Cancel, and rebook. Watch whether the freed slot becomes available again immediately.
6. Ask it to book something it has never heard of. It should say it does not know rather than mapping it to the nearest-sounding service.

The part most systems skip: what happens after

The booking is the start. What the appointment needs next:

• A confirmation the customer can act on.
• Reminders at useful times, sent only to people who agreed to be texted.
• A reschedule path that is as easy as confirming, because the customer who cannot make Tuesday is not coming on Tuesday either way.
• A record of what changed: who moved it, when, and what it was before.

What Frontiva does

Availability is computed across staff rotas, existing appointments, time off, holidays and per-service buffers, resolved in each location's own timezone.

Double-booking is prevented by a Postgres exclusion constraint. The second overlapping write is refused by the database itself, not by application code that checked first and hoped. It is tested with 50 simultaneous requests for the identical slot; exactly one succeeds.

Customers can book themselves from a public page per location without an account, through the same engine and the same constraint as your staff calendar. There is deliberately no second implementation for the public page, because two implementations are how they start giving different answers and the one customers see is the unverified one.

What is not built: two-way Google Calendar and Microsoft 365 sync, and charging a deposit. You can state a deposit policy on the booking page, and the customer sees it before booking, because finding out afterwards is what produces a chargeback.