Set Up Phone Booking for a Personal Cal.com Event Type

Cal.com AI phone booking works best when the appointment type is already well defined. Before writing the assistant's greeting, decide which meeting it may book, how long it lasts and which caller details are required. A voice conversation cannot repair an event type whose requirements do not match the integration.

Burki's native Cal.com workflow focuses on supported personal event types. The connected account and selected event type belong to the workspace configuration; they should not be chosen freely by the caller during a booking action.

Prepare the appointment in Cal.com first

Check the event's name, duration, availability and timezone in the calendar account. Use a name a caller can understand. “Initial consultation” is clearer than an internal code that means something only to the business owner.

Review required booking fields. The current Burki connection supports ordinary event types using the attendee's name, email and timezone. Requirements such as payment, extra questions or verification codes can prevent the supported action from completing. Resolve those requirements in the calendar configuration instead of instructing the assistant to skip them.

Cal.com's booking API reference describes the provider booking operation. Its wider capabilities should not be read as a list of every feature exposed by Burki.

Connect the workspace and assign the actions

An authorized administrator connects the intended account, chooses the supported personal event type and enables calendar actions on the relevant assistant. Follow the current Cal.com setup guide rather than putting API credentials into the conversation prompt.

Remember that the selected event type is shared by assistants using that workspace connection. Changing it can affect more than the assistant currently open in the editor. Review the affected workflows before saving a different selection.

The assistant's instructions should explain what the appointment is for, which information to collect and when to ask for explicit confirmation. They should not promise team scheduling, cancellations or rescheduling merely because the calendar product offers those features elsewhere.

A hypothetical booking conversation

Suppose a consultant offers a personal introductory appointment. A caller asks for Wednesday afternoon, gives a name and email, then chooses one of the returned available times.

The assistant's readback should identify the appointment, full date, local time and timezone, along with the necessary attendee details. It then asks whether the caller wants that specific appointment booked. Only the confirmed choice should reach the booking action.

After the result returns, the wording follows the actual status. A confirmed booking can be described as confirmed. A request awaiting host approval should be described that way. If the response is uncertain, the assistant must not convert uncertainty into an appointment promise.

This example is hypothetical. It illustrates the intended sequence and does not imply that a practice call creates an appointment.

Keep practice separate from real scheduling

Ordinary browser practice in the published setup guide uses simulated calendar actions. It is useful for testing the explanation, details and corrections without creating a real appointment. A successful simulated result does not establish calendar access or a live write.

For a straightforward live acceptance, use an authorized telephone workflow and a suitable test slot. Ordinary browser practice stays simulated; a separately approved funded browser booking is a distinct test path. Check the actual provider appointment afterwards: attendee, event type, date, time and timezone should all match the caller's confirmation. Manage unwanted test appointments in Cal.com using the account's own controls.

Do not repeat a booking request simply because the first response was slow. Check the existing outcome before attempting another operation. A missing reply and a missing appointment are different situations.

Give staff a short readiness checklist

Before launch, staff should be able to answer these questions without opening the prompt: Which account is connected? Which personal event type can be booked? What details are required? Who reviews uncertain outcomes? What should the assistant say if no suitable time exists?

The broader appointment-request use case helps set expectations about the caller experience. Begin with one appointment type, one clearly stated purpose and a verified outcome path. Expand only after the existing flow works for the actual business scenario.