Connect a telephone assistant to an appointment system
Plan bookings, occupied slots, lost responses and appointment changes with a worked integration example.
A telephone assistant should confirm an appointment only after the authoritative booking system confirms the correct record. It needs narrowly defined integration functions and responses that expose the actual state. A list of available times is not a booking.
Keep booking rules in the authoritative system
In this fictional example, a software business offers existing customers 30-minute project discussions for resource consultation-a. The caller chooses 19 November 2026, from 14:00 to 14:30 in Europe/Berlin. The assistant reads back the date, time and duration and waits for the caller’s explicit choice.
The booking service checks permitted appointment types, permissions and overlaps when writing. The website and staff must use the same allocation rule. Later calendar synchronisation does not prevent two booking channels from allocating the same time concurrently.
Define four limited functions
Example function | Purpose | Required response |
|---|---|---|
| Find suitable available times | Intervals with dates and time zones |
| Book the explicitly selected interval | Confirmed booking or specific rejection reason |
| Resolve a request’s outcome using its identifier | Existing booking, failed request or still-unknown state |
| Move an existing booking to a chosen time | Confirmed change or unchanged existing appointment |
ElevenLabs describes external functions like these as webhook tools. The names and rules here are our own design. The server validates parameters and permissions itself; a model call grants no access rights. Access keys do not belong in conversation text. Stating a booking identifier alone does not establish permission to change it.
Fill in the request and response
The server assigns stable request identifier R-94 to this booking intention. Once the caller’s account association is established, the booking function receives these business data:
{"requestId":"R-94","resourceId":"consultation-a","start":"2026-11-19T14:00:00+01:00","timeZone":"Europe/Berlin","durationMinutes":30}This is not a direct Google Calendar call. Google’s Freebusy query returns busy intervals; the chosen booking path must separately ensure exclusive allocation. In this example, checking and reserving are protected against concurrent bookings. Only this business confirmation permits a booking promise:
{"requestId":"R-94","status":"confirmed","bookingId":"B-94"}The assistant can now confirm the agreed time. Creating a calendar entry alone does not prove that an invitation has been read.
Check four cases through to the stored result
Case | Expected system behaviour | Statement during the call |
|---|---|---|
Selected time is free when writing | One booking | Confirm the agreed appointment |
The time has since been allocated | No further booking for the same resource and time | Offer new available times |
Booking response is lost | First resolve the existing outcome using | Confirmation is still pending |
Requested move to |
| Change rejected; state the original appointment |
Repeating the same request identifier and data within the same permission scope must return the existing outcome. A changed request receives a new identifier. If the outcome remains unknown, do not force another booking with a new identifier; use the established resolution path.
Rescheduling must not remove the old appointment prematurely. If the integration cannot provide a protected switch, it needs a separate workflow instead of an automatic promise. Use these four cases before launch to check that the conversation matches the stored booking state.
Sources
Read more
All articles
AI & Automation with ASES
AI assistants and automated workflows