GlytosGlytosdocs

Booking appointments

An agent can offer real times and book one while the caller is still on the line. It reads availability from Cal.com, which syncs both ways with the calendar your team already uses - Google Calendar, Outlook, or CalDAV - so a booking lands where you already look, and a busy block you added by hand is respected.

Why Cal.com and not your calendar directly

A calendar API gives you busy blocks and event creation. Everything between them is the part that matters: working hours, time zones and daylight saving, slot length, buffers between appointments, minimum notice, how far ahead you accept bookings, two callers offered the same slot at once, reschedules and cancellations, and the confirmation email. Cal.com is that layer, and you keep your own calendar underneath it.

Setup

  1. In Cal.com, create the event type you want callers to book, and set its availability, duration and buffers there.
  2. Copy an API key from Cal.com's settings, and the event type id (it is in the event type's URL).
  3. In Glytos, go to Settings - Integrations, add a Cal.com connection and give it a name that says what it books, for example "30 min consultation". Enter the API key, the event type id, and your business time zone.
  4. Under Tools, create a tool of kind Integration for each action, pick the connection, and choose check_availability or book_appointment. The parameter schema is filled in for you.
  5. Add both tools to your agent.

One connection books one event type. If you offer two different appointments, make two connections and two pairs of tools; an agent can carry both.

What the agent does

check_availability takes a date and returns open slots, each with a label in your time zone and the exact start value to book with. book_appointment takes that start back, plus the caller's name and email.

The agent is told to read a couple of the labels aloud rather than list everything, and to hand start back unchanged. That split is deliberate: the model should never do time-zone arithmetic, because it is the one thing it is confidently wrong about.

A useful prompt sounds like this:

When the caller wants an appointment, call check_availability for the day they
mention, then offer two or three of the times. Once they choose one, ask for their
full name and email, and call book_appointment with the exact start value of the
slot they picked. Confirm the day and time back to them afterwards.

Limits and behaviour

  • At most 12 slots are returned per check, so the model has something to offer rather than a list to read out.
  • No availability is a normal answer, not an error. The agent should offer another day.
  • These actions are only available during a conversation. They cannot be used as an automation: booking on every finished call would create a real appointment from templated fields, every time.
  • A booking made this way is a real Cal.com booking, so your usual confirmation emails, reminders and reschedule links all apply.
Booking appointments · Glytos Docs