First sync the real schedule
I would not store the schedule in the prompt. The bot can politely suggest a slot, but the only source of free time must be the calendar, checked right before creating the meeting.
The mistake I would remove first: The message “you’re booked for 3:00 p.m.” does not mean the event was created. Double-click, time zone, and parallel booking easily turn one meeting into two.
What to prepare and what result to expect
- Outcome: The customer picks an available slot, gets confirmation and a reminder, and reschedule does not create a second meeting.
- Create a services table: service_id, duration, buffer, calendar, business hours, time zone, who approves exceptions.
- Keep source data and access rights separate from the result so you can audit what AI service booking actually did.
- Test booking, a busy slot, reschedule, cancel, daylight saving, and a request from another time zone.
Set up booking, reminders, and reschedules
- Configure the calendar first
Connect a work calendar and set hours, breaks, buffer before and after the meeting, and minimum lead time. Do not store free slots in the prompt.
Проверьте: A free slot is pulled from the calendar right before showing it to the customer.
Если не сработало: Sync one test calendar and disable writes to the shared calendar.
- Treat service as a separate object
For each service set service_id, duration, and required staff. AI can understand the service name, but take duration and price from the table.
Проверьте: The same service yields the same slot regardless of customer wording.
Если не сработало: Replace free text with buttons or an allowed value list.
- Confirm the slot before creating the meeting
After time selection, request availability again, then create the event with name, contact, service, and time zone. Save event_id.
Проверьте: Double-click or a repeated webhook does not create two meetings.
Если не сработало: Check event_id and block duplicate booking.
- Separate reschedule from new booking
Reschedule must find the existing event_id, check the new slot, and update the event. If id is missing, route the request to a human.
Проверьте: History keeps both old and new times.
Если не сработало: Do not delete the old event until the new one is confirmed.
The setup that prevents double bookings
In the services table set service_id, duration_minutes, buffer_before, buffer_after, calendar_id, and timezone. AI can understand that the person wants a “consultation,” but take duration and calendar from the table.
After slot selection, call availability again, then create the event and save event_id. On a repeated webhook first look up event_id or client_request_id. For reschedule, create the new slot first and delete the old event only after confirmation.
- Test daylight saving and a request from another time zone.
- Do not promise a slot until the calendar returns a confirmed event_id.
What to leave to a human
Hand staff a few cases: VIP customer, failed payment, no suitable specialist, reschedule outside the rules, and calendar conflicts. In other cases AI can collect data, but the final action must still go through the calendar API.
I check the slot twice—I don’t promise from memory
In the calendar store `event_id`, `client_request_id`, `service_id`, `duration_minutes`, `buffer_before`, `buffer_after`, and `timezone`. After time selection call availability again and only then create event. If a repeated webhook arrives with the same `client_request_id`, return the existing `event_id` instead of creating a new meeting.
For reschedule first book the new slot, get confirmation, then change the old event. If the new slot was not created, do not delete the old meeting. That simple rule prevents “bot canceled the old one but never placed the new one.”
What AI can handle vs what must come from the calendar
| Criterion | Question | Good sign |
|---|---|---|
| Input | What exactly enters AI service booking? | Create a services table: service_id, duration, buffer, calendar, business hours, time zone, who approves exceptions. |
| Action | What is the system allowed to do on its own? | Only pre-listed actions, without access to the whole account |
| Verification | How do you know the result is acceptable? | Test booking, a busy slot, reschedule, cancel, daylight saving, and a request from another time zone. |
| Failure | Where does an unclear case go? | Do not promise a slot in the message: set the request to needs_confirmation and pass the manager the exact time and original request. |
What should change after setup
The customer picks an available slot, gets confirmation and a reminder, and reschedule does not create a second meeting.
Why the bot books people into nonexistent slots
Storing the schedule in the prompt instead of the calendar.
Ignoring the customer’s time zone.
Treating a sent confirmation as proof the event was created.
Allowing reschedule without checking which meeting is being changed.
When booking becomes a full reservation system
You need a specialist if there are multiple staff, different durations, payments, or medical/legal constraints.
What to test before opening booking
Who is this AI service booking approach for?
Automatic booking must see real free slots, account for duration and time zone, and reschedule or cancel only after identity and business-rule checks.
Where to start if everything is still manual?
Create a services table: service_id, duration, buffer, calendar, business hours, time zone, who approves exceptions.
How do you check the setup will not hurt you?
Test booking, a busy slot, reschedule, cancel, daylight saving, and a request from another time zone.
What if the result is unclear?
Do not promise a slot in the message: set the request to needs_confirmation and pass the manager the exact time and original request.
