B2Shift · Published 27 August 2026 · Updated 27 August 2026
Scheduling looks simple until the exceptions arrive: double-bookings, timezone mismatches, cancellations, and requests that need a human regardless of calendar availability.
The core loop: request, constraints, availability, confirmation
A request arrives (chat, WhatsApp, form or call), the system captures constraints (service type, preferred window, resource needed), checks real availability against the calendar, proposes valid slots, and confirms — writing the booking back to the calendar and notifying the relevant person. Each step needs a defined behaviour when it fails, not just when it succeeds.
Calendar integration is where most bugs actually live
Free/busy access needs to reflect resource-level availability (a specific room, vehicle or staff member), not just one shared calendar — the Google Calendar API's resource and free/busy patterns are the reference worth reading before building this. Timezone handling deserves explicit testing: a scheduling assistant that silently assumes the business's timezone will misbook clients calling from elsewhere.
Cancellations and changes need an explicit policy, not an assumption
Decide upfront: can a customer self-cancel, up to what notice period, and what happens to a no-show. An assistant that can create bookings but not gracefully handle a change request just moves the admin burden instead of removing it.
Escalation still needs a real trigger
Sensitive or ambiguous requests — a medical concern folded into a booking message, a request outside normal service scope — should route to a person immediately rather than be forced into the standard flow. See AI Chatbots & Voice Assistants for how this is scoped as a complete workflow, including reminders and no-show handling.