Should AI phone intake request an appointment or confirm one?
Format: Article.
Start by taking appointment requests. Confirm bookings only when the business allows it and tests show the full process works. A caller's preferred time may not be open. An open slot is not a saved appointment. Even a saved event may still need staff approval before a service visit can go ahead.
Your team may need to line up staff, rooms, travel, tools, or site access. An open calendar cannot prove all of those are ready. The model below is a proposed custom scheduling design, not a working Core Agentic voice booking service.
Define what confirmation means
List what must be true before your team can book a visit. You may need a current calendar, the right branch, and a trained staff member. Check the job type, how long it takes, and the caller's time zone too. Your team must set the full list.
Google Calendar has a free/busy query that reports busy time ranges. It may report an error for a calendar it cannot check. A separate operation, event insert, creates an event and returns its record when it succeeds.[7][8] Checking free/busy does not reserve a slot. Neither guide proves your staff or equipment can serve that booking.
If the intake can only read the calendar, it should only take requests. If it can write to the calendar, set limits on what it may book. Tool access alone is not permission to book every kind of job.
A scheduling authority model
| State | Proof needed | What the intake may say | Who decides the next step |
|---|---|---|---|
| Preference captured | Caller states the date, time, and place | I have your preferred time for review. | Staff check whether the time fits the job. |
| Availability checked | Current results from all needed calendars; errors checked | That time appears available, but it is not booked. | The approved booking process checks the rest of the rules. |
| Booking proposed | All needed details and prior approvals are in place | The team is reviewing this proposed appointment. | A person with the right authority approves the booking. |
| Booking saved | Save succeeded and the saved event was read back | Confirm only if all business rules also pass. | Named scheduler checks the saved record. |
| Outcome uncertain | Reply lost, facts conflict, or saved record cannot be read | I cannot confirm an appointment yet. | Staff check what happened before trying again or offering a new slot. |
In a first build, staff can decide when to confirm a booking. The intake can still help them gather the details. It does not need to act as if it can check every booking rule on its own.
Check freshness and conflicts together
Record which calendar you checked, which time range you checked, and when. If the caller changes the date, service, or place, check again. The new request may need a different staff member or a longer slot. The old result does not settle the new request.
Someone else may take the slot after the check but before the save. Ask the builder how the design handles that race. It may need to hold the slot or check again before booking. Do not assume that saving one event will hold a crew, room, and tools together. Ask the builder to show how it avoids a booking with only some of those in place.
Read back the date, local time, and time zone for the visit. “Tomorrow afternoon” is not enough to create the right event. Google's event insert guide defines start and end fields and time-zone rules.[7] Your script still needs to check which date and time the caller meant.
Rehearse a slot that disappears
In this hypothetical proposed design, a caller asks for a morning visit. The calendar looks open. Before the scheduler approves the visit, another worker books the same crew.
Keep the request open. The intake must not say “you are booked” based on the earlier check. Staff can look for a new time. The caller must agree to it through the approved process. Keep the first choice in the note so staff can see why it changed.
Now test a different failure. The calendar saves the event, but the intake never gets the reply. Trying again without a check could create two events. Use the approved request reference to look for the saved event first. Until the result is checked, leave the state uncertain.
Confirm the record, not the tone
After staff approve a booking, read back what the calendar saved. Check that it is the right calendar. Check the date, time zone, length, and crew or tools needed. The message to the caller must match those facts. An event in the calendar does not prove that the caller accepted its invite.
Creating an event can also send messages, depending on provider settings.[7] Agree on who may send booking notices. Test the chosen settings before use. This article does not give permission to change a calendar or send a message.
Bring your booking rules and one case of a slot clash to Core Agentic. Book a Demo to plan what a custom phone intake should do. It can take requests, or you can scope a separate process to check and confirm them.
Sources
- Google: Events: insert | Google Calendar | Google for Developers.
- Google: Freebusy: query | Google Calendar | Google for Developers.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.