The Appointments section allows users to review scheduled sessions, maintain weekly availability, and manage Appointments created during AI telephone conversations.
The system connects:
An Appointment can store:
The supported Appointment statuses are:
Appointments created by an AI Agent normally receive a default duration of 30 minutes and begin with scheduled status.
Availability defines when the business is generally willing to accept Appointments.
Example:
An Appointment is an actual booking assigned to a specific date and time.
Example:
Availability repeats weekly. Appointments occur on specific calendar dates.
A Campaign initiates outbound calls.
An Appointment records a future scheduled session that may result from one of those calls.
Example:
The Appointment remains available in the Appointments section after the Campaign call ends.
The Call Log records the telephone conversation.
The Appointment records the scheduled session created during or after that conversation.
One Call Log can result in:
The Appointment does not contain the entire call Transcript or Recording.
The AI Agent determines whether booking tools are available during a call.
An Agent must have:
The Agent does not automatically receive booking capability merely because the account has Availability configured.
After signing in:
The page describes its purpose as:
The Appointments page contains two tabs:
Displays existing scheduled, completed, and canceled records.
Defines the weekly times that the Agent can present as available.
The Appointments tab supports:
Use Card view for a visual overview.
Use List view for a compact table.
The current view begins as Card view whenever the page component is newly loaded. The reviewed page does not store the Appointment view preference in browser storage.
While the page retrieves Appointment records, skeleton Cards appear.
During loading:
When the Appointment request fails, the page displays:
Possible causes include:
When no records exist, the page displays:
The current Appointments page does not provide an Add Appointment button.
Within the normal user interface, Appointments are primarily created by AI Agents whose Appointment Booking capability is enabled.
A normal user receives Appointments where:
The account cannot ordinarily review another user’s Appointments through the standard user route.
A Super Administrator can retrieve a broader Appointment list.
Normal-user instructions should not assume global Appointment access.
The backend sorts Appointments by:
This means later dates generally appear before earlier dates.
The list is not separated into dedicated sections such as:
All statuses appear together.
Each Appointment Card displays:
The Card displays a formatted date such as:
The Appointment time is displayed prominently.
Example:
The important time-zone behavior is covered later in this chapter.
The Card displays one of:
Canceled Cards appear visually faded.
The page chooses the displayed client identity in this order:
Appointments booked by an Agent can store the caller’s spoken name in clientName.
When no usable client name is stored, the telephone number may appear as the client identity.
The Card displays:
This is also used by the Agent when listing or canceling the caller’s scheduled Appointments.
The Card displays:
When the referenced Agent has been deleted, it displays:
Deleting an Agent does not automatically delete its existing Appointment records.
List view contains:
Action controls appear only for scheduled Appointments.
The available actions are:
Completed and canceled records do not display further status actions in the current interface.
A newly booked Appointment normally has:
A scheduled record represents an Appointment that has not been marked completed or canceled.
Completed indicates that the user manually marked the Appointment as completed.
It does not automatically confirm:
The current system does not provide separate attended and no-show statuses.
Canceled indicates that the Appointment is no longer scheduled.
Cancellation can occur through:
An Appointment does not automatically become completed merely because its scheduled date and time passed.
A past Appointment can remain:
until a user marks it completed or canceled.
The current Appointment model does not include:
Use an approved external process when those distinctions are needed.
To mark an Appointment completed:
The success message is:
In List view:
The button tooltip is:
The current interface does not ask for a second confirmation before marking an Appointment completed.
Verify the record carefully before selecting the action.
The reviewed Appointment update route triggers Appointment notifications specifically when status changes to:
It does not show an appointmentCompleted webhook or email event.
Marking an Appointment completed therefore does not trigger the same booked or canceled notification events.
To cancel:
The success message is:
In List view, select the red Cancel Appointment icon.
The current user interface does not present a second confirmation dialog.
Changing an Appointment to canceled can trigger:
when the corresponding integrations and event selections are enabled.
Cancellation changes the Appointment status.
It does not remove the record from the Appointments page.
This preserves historical evidence that the booking existed and was canceled.
The current Appointments page does not include:
A backend creation route exists, but normal users are not given a visible manual creation form on this page.
The current page does not provide a form to edit:
The user interface does not provide:
For caller-managed rescheduling, the current Agent toolset supports cancellation and new booking rather than a single reschedule command.
Recommended process:
Although the backend contains an Appointment deletion route, the current user Appointments page does not display a Delete action.
Normal users manage Appointment history through statuses rather than removing records from this interface.
The current page does not provide:
Card and List views display the returned records together.
The current page does not include a separate Appointment Details screen showing:
The Card and table contain the visible operational information.
Appointment records store duration, but the current Appointments page does not display it.
Agent-created Appointments use the model’s default duration of:
unless another authorized process supplies a different value.
The Appointment model supports Notes, but the current Appointments page does not display or edit them.
The inspected current system does not expose a user-facing Appointment-reminder schedule such as:
Appointment Booked and Canceled notifications are event notifications, not confirmed future reminder scheduling.
The current Appointment interface does not show a direct integration with:
The Google integration elsewhere in the application is for Google Sheets, not Appointment calendar synchronization.
To configure weekly hours:
The section is titled:
with the description:
The schedule displays:
Each day can contain zero, one, or several slots.
When a day has no slots, it displays:
An Agent cannot return a slot for that day through the normal Availability lookup.
Select:
under the intended day.
A new slot begins with:
These are default values and should be revised to match the actual booking structure.
The controls use browser time inputs.
The backend accepts 24-hour values in:
format.
Examples:
Start Time identifies the beginning of the availability window.
Example:
End Time identifies the end of the availability window.
Example:
A day can contain several slots.
Example:
A small badge beside the day displays the number of configured slots.
Select the X beside a slot to remove it from the local schedule.
The slot is not permanently removed from the backend until Save Changes is selected.
Remove every slot shown under the day and save the schedule.
The day will then display:
Remove all weekly slots and select Save Changes.
This replaces the stored schedule with an empty schedule.
An Appointment-enabled Agent will then report that no availability slots have been defined.
After reviewing every day, select:
During processing, a rotating icon appears.
On success:
Saving does not update only the slot currently being edited.
The backend:
Therefore, Save Changes replaces the entire weekly schedule.
Before selecting Save Changes, inspect:
An accidental omission can remove previously stored availability.
The Availability model uses a unique combination of:
Two Monday slots with exactly the same Start Time can cause the save operation to fail, even when their End Times differ.
Avoid:
The current interface does not visibly prevent overlapping windows.
Example:
Such a schedule can create confusing availability responses.
Use nonoverlapping slots.
The backend validates the time format but does not show a validation rule requiring:
Review the order manually.
Avoid:
When saving fails, the page displays:
Because the backend replaces the entire schedule by deleting and reinserting records, reopen or refresh Availability after an error to verify what remains stored.
A configured slot is treated as one availability window.
Example:
The current Availability lookup does not automatically divide that window into:
Instead, the Agent receives the whole window as one available range.
The Agent may receive information similar to:
This is why discrete Appointment-sized slots are generally safer than one all-day window.
For 30-minute Appointments, use:
rather than:
This provides clearer choices and more reliable occupied-slot handling.
When determining availability, the service checks whether any scheduled Appointment begins inside a configured window.
If one exists, that entire window is omitted.
Example:
This is a critical reason to use granular windows.
The Appointment’s default 30-minute duration is not used to automatically generate 30-minute intervals from a large Availability window.
Slot design must be completed manually.
The Availability tool excludes a slot when its Start Time is not later than the current time.
Example:
That slot is not returned because its start has already passed.
The Agent’s Availability tool reviews:
for a total of seven calendar days in the account’s configured time zone.
It does not search indefinitely into future weeks.
Time zone affects:
To configure it:
The field description states:
When no valid account time zone exists, Appointment tools fall back to:
The Settings model also defaults to UTC.
Examples include:
Use the geographic region rather than manually entering a fixed offset when daylight-saving adjustments matter.
For operations based in Detroit, a typical selection is:
This allows the time-zone library to account for Eastern Standard Time and Eastern Daylight Time.
Availability fields do not store a separate time zone with each slot.
The booking service interprets those weekly times using the account’s current Settings time zone.
Example:
The slot means 9:00 AM to 9:30 AM in America/New_York.
Changing the account Time Zone changes how Availability windows are interpreted for future Agent lookups.
Review every slot and Appointment after changing Time Zone.
Appointments are stored as absolute Date values.
Changing the account Time Zone does not rewrite the stored Appointment timestamp.
It changes how the Agent formats and interprets that timestamp.
AI Agent booking tools use the account’s configured Time Zone.
The current Appointments page formats dateTime using the browser’s local Date environment.
Therefore:
This can cause the same Appointment to appear at different clock times when the browser and account use different zones.
Assume:
The browser can display the equivalent:
The Appointment has not moved. It is being displayed in another local zone.
For everyday administration:
When remote staff work in different zones, document which display is the authoritative business time.
Settings provides:
The Agent’s custom-voice instructions use this preference when speaking times.
Examples:
The current Appointments page uses the browser’s date-formatting behavior and does not directly consume the account Time Format setting.
The visual time shown on the page can therefore follow the browser locale even when the Agent has been instructed to speak in a different format.
To enable booking:
The Agent control states:
Enabling this setting adds internal booking tools to the live Agent conversation.
The Agent form provides an Appointment Description.
Example:
The record stores this description, but the reviewed live booking tool does not clearly use it as the Appointment’s Notes or as an enforced duration.
Include the important booking purpose in the Agent’s System Prompt as well.
Example:
When Appointment Booking is enabled, the system gives the Agent internal commands for:
The command tags are removed before speech so the caller should not hear the technical command text.
When a caller asks:
the Agent can run the internal List command.
The List tool searches for:
Only scheduled Appointments matching that exact client telephone number are returned.
The Agent’s List tool does not return:
Appointments.
Those records remain visible to authorized users in the Appointments interface.
The Agent receives information similar to:
The time is formatted in the account Time Zone.
A caller using a different telephone number may not be matched to an existing Appointment.
Example:
The List and Cancel tools search the current caller’s telephone number, so the original Appointment may not be found.
When a caller asks:
the Agent can check the next seven days.
When the account contains no slots, the Agent receives:
The Agent cannot offer a reliable time until the Work Schedule is configured.
The tool checks scheduled Appointments and omits an Availability window containing a scheduled Appointment.
Completed and canceled Appointments do not block the window.
Availability belongs to the account, not to an individual Agent.
The current Availability model does not include:
All Appointment-enabled Agents under the same account use the same weekly Availability collection.
The booking service checks for an existing scheduled Appointment using:
It does not limit the conflict check to one Agent.
Two Agents under the same account cannot normally book separate scheduled Appointments at the exact same timestamp through this tool.
The Agent booking operation uses:
The booking Date and Time are interpreted in the account’s configured Time Zone.
The resulting Appointment is stored as an absolute timestamp.
The Agent’s internal command uses:
Example:
The caller does not need to speak this technical format. The Agent converts natural requests such as:
into the required command.
The Agent receives the current:
to interpret phrases such as:
When the caller provides a name, the Agent can include it in the booking command.
The Appointment then stores:
When no name is available, the booking confirmation can use the caller’s telephone number.
Agent-created Appointments do not provide a custom duration in the current command.
The Appointment model applies its default:
A successful booking returns a confirmation similar to:
The time is formatted in the account Time Zone.
A successful Agent booking can trigger:
when enabled.
The new Appointment then appears on the Appointments page.
Before saving, the Agent tool checks for a scheduled Appointment with:
When found, it returns:
The conflict check does not evaluate overlapping Appointment duration.
Example:
Because the Start Times differ, the current exact-time check may not identify the overlap.
Use discrete, nonoverlapping Availability slots and have the Agent book only the listed start times.
The Booking tool verifies exact-time duplication, but it does not clearly enforce that the requested time:
Operationally, Availability guides the Agent, but the booking service is not a complete hard boundary.
The Agent Prompt should require the Agent to check slots before every booking.
Availability:
Caller requests:
If the Agent produces a valid booking command without checking Availability, the backend can potentially create that exact-time Appointment.
Use explicit Prompt rules and test this scenario.
Add:
When a caller asks to cancel, the Agent uses:
The cancellation must match the stored Appointment timestamp after interpreting the requested date and time in the account Time Zone.
When no exact matching scheduled Appointment exists, the Agent receives:
The Agent Prompt should require:
A successful result resembles:
It can trigger Appointment Canceled webhook and email events.
The internal Agent tools include:
There is no separate Reschedule command.
The Agent should:
Cancellation and booking are separate operations.
A failure can occur after the original Appointment is canceled but before the replacement is booked.
The Agent should clearly explain the final result and the user should verify both records afterward.
When the Agent executes an Appointment tool, the result is added to the call Transcript as a System message similar to:
The tool result is also converted into caller-friendly speech.
For slot and Appointment-list responses, the Agent adds a question similar to:
Command tags such as:
are removed from the generated speech.
They can still appear in the stored Assistant Transcript because the full AI reply is recorded before or alongside command processing.
When configured, a newly booked Appointment can send an:
event to the account’s Webhook URL.
Cancellation can send:
The same event categories are available through the account’s email-notification configuration:
Selecting the Appointment event is not enough by itself.
The corresponding integration also requires its overall:
setting and valid configuration.
The reviewed event list does not include:
Marking a record completed should not be expected to send a completion webhook or email.
When the Agent knows the caller’s name, require it to confirm the spelling before booking.
Example:
Appointment listing and cancellation depend heavily on the stored clientPhone.
Caller-ID changes can prevent matching.
Each Appointment stores one Agent.
If the Agent is deleted, the Appointment remains but displays:
Preserve Agents required for historical reporting.
Each Appointment stores one Lead ID.
Deleting the Lead can reduce the amount of client information that populates with the Appointment.
Avoid deleting Leads associated with upcoming Appointments.
Client Name is not used as the primary Appointment matching method.
The Agent’s listing and cancellation operations use the caller’s telephone number.
Two callers with the same name do not automatically conflict.
For default 30-minute Agent bookings, create 30-minute Availability windows.
Example:
To leave a break between Appointments:
The missing 9:30–10:00 period acts as a buffer.
Do not configure a slot across lunch when the Agent should not offer that period.
Example:
Availability repeats by weekday.
The current Work Schedule does not provide:
For a holiday:
Then restore the schedule afterward.
Be careful because removing Monday Availability affects every Monday until restored.
The current Availability record stores:
It does not store a specific calendar date.
The weekly schedule is account-wide.
Create separate accounts or implement a customized scheduling layer when different Agents need fully independent calendars.
Check:
Sign out and back in when the session has expired.
Check:
An Agent saying:
does not prove the booking tool executed.
Possible causes include:
Review the Call Transcript for a System command result.
Open:
Add slots and select Save Changes.
Possible causes include:
Reload the Availability tab and rebuild the schedule where necessary.
Check:
Avoid two slots with the same weekday and Start Time.
This normally means the Work Schedule contains a large window such as:
Replace it with Appointment-sized slots.
This occurs when one large Availability window contains a scheduled Appointment.
The current lookup treats that entire window as booked.
Divide the day into granular slots.
The booking backend does not fully enforce Availability boundaries.
Correct the Agent Prompt so it checks available slots before booking, then test unavailable-time requests.
The current conflict check prevents the same exact Start Time but does not fully detect overlapping durations.
Review the Work Schedule and create nonoverlapping discrete slots.
Cancel the incorrect Appointment and book a corrected time.
Compare:
The Appointments page can display browser-local time while the Agent uses account time.
Check the account Time Zone.
When it is UTC but the business operates in another region, the Agent’s calendar day can change earlier or later than expected.
Check:
The List tool ignores completed and canceled Appointments.
Cancellation requires:
Ask the Agent to list the caller’s Appointments first, then cancel the returned date and time.
This is expected until a user manually selects:
or:
There is no automatic overdue-status process in the reviewed system.
The page displays:
Check:
Refresh before repeating the action.
The Appointment has no usable clientName, and populated Lead name fields were unavailable.
The clientPhone becomes the fallback display.
The current page does not provide a direct Edit Client Name form.
The Agent associated with the Appointment was removed.
The Appointment remains as historical data.
Create and assign replacement Agents for future calls, but the current Appointment page does not provide an Agent reassignment control.
Cancellation is a status change, not deletion.
The faded record remains for history.
The system does not expose a confirmed scheduled Appointment-reminder function.
Check whether Appointment Booked email notifications were configured; those are immediate event notifications rather than later reminders.
Before production:
During a second call from the same telephone number, ask:
Confirm the Agent lists the correct date, time, and Agent.
Attempt to book the same exact time again.
Expected result:
Attempt to book a different Start Time that overlaps the first Appointment.
Document the result and adjust Availability so overlapping options are not offered.
Request a time outside the configured schedule.
The Agent should refuse and offer an available option according to its Prompt.
Because the backend does not fully enforce this boundary, this Agent behavior must be tested.
Ask the Agent to:
Use the full process:
Verify that the original is canceled and the replacement is scheduled.
Test from a browser whose Time Zone matches the account first.
Then compare from another device or zone to understand how the Appointment page renders the stored time.
Select:
when the session occurred.
Select:
when the Appointment was canceled.
The current system has no dedicated no-show status, so follow the organization’s approved process for missed sessions.
Once each week:
Appointment records can expose:
Only authorized users should access this information.
Do not share Appointment screenshots containing full telephone numbers unless the recipient is authorized.
An Appointment’s date, time, and Agent can reveal a client’s relationship with the organization.
Treat Appointment data according to the applicable privacy and retention policy.
Webhook and email destinations receive Appointment event information.
Use only trusted:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
Confirm:
At the end of this chapter, the user should understand how the Appointments page displays scheduled, completed, and canceled sessions; how Card and List views work; how client identity, telephone number, Agent, date, time, and status are displayed; how to mark scheduled Appointments completed or canceled; and which manual creation, editing, rescheduling, deletion, search, filtering, reminder, and calendar-synchronization controls are not currently available in the normal user interface.
The user should understand how to build a weekly Work Schedule, add and remove Availability slots, save the complete schedule, avoid duplicate Start Times and overlapping windows, and recognize that Save Changes replaces the account’s entire existing Availability schedule.
The user should especially understand that a configured Availability entry is treated as a complete window rather than being automatically divided by the default 30-minute Appointment duration. A large window such as 9:00 AM–5:00 PM can be hidden entirely after one Appointment begins inside it. Appointment-sized windows provide more reliable booking choices.
The user should also understand the distinction between the account Time Zone and the browser Time Zone:
Finally, the user should understand how an Appointment-enabled Agent lists the caller’s scheduled Appointments, checks the next seven days, books an exact date and time, and cancels an exact scheduled Appointment; why listing and cancellation depend on the caller’s telephone number; how booking and cancellation events can trigger Webhook and email notifications; and why the current exact-time collision check does not fully prevent overlapping bookings or enforce that every booking falls inside Availability.