Feasible appointments
AI Agent for Scheduling
Coordinate appointments around skills, travel, resources and explicit confirmation, with separate proposals, holds and commitments.
An empty calendar slot is not necessarily an appointment the business can deliver. The right person may lack the required skill, travel may make the timing impossible, equipment may be unavailable or the customer may not have accepted the proposed time. A scheduling agent needs a model of commitments, not merely access to calendars.
This guide is for field-service managers, appointment operations teams and organisations coordinating people, sites and resources. It explains how an agent can collect constraints, find feasible options and manage confirmation. For simple personal meetings the scope can be lighter, but the distinction between suggested, reserved and confirmed still matters.
Describe the service before looking for time
Capture the appointment type, location, expected duration, required skills, equipment, participants and acceptable windows. Identify which constraints are mandatory and which are preferences. “Morning if possible” should not receive the same treatment as a site that only admits visitors during a defined window.
Use a reliable source for service duration and preparation rules. A customer’s estimate that a repair will take 15 minutes is a useful statement, not an approved duration. The agent can ask clarifying questions and retrieve a service template. If the request does not match a supported type, a planner should assess it before the system offers a firm slot.
Separate scheduling from service eligibility. A customer may need a valid contract or an accepted work order before a visit can be booked. The support workflow can establish the request and entitlement; the scheduling workflow then finds a feasible commitment within that approved scope.
A field-service appointment, worked through
Illustrative example: Technician A has a job from 09:00 to 10:00 at one site. The next customer requires a 60-minute visit between 11:00 and 12:00. The assumed travel time is 40 minutes and the required preparation buffer is 20 minutes. An 11:00 start is just feasible under those assumptions because 10:00 + 40 minutes + 20 minutes = 11:00.
A calendar-only agent might offer 10:00 because the diary is empty then. A constraint-aware workflow excludes that slot. It also checks that Technician A has the required skill and equipment, the customer’s site is accessible and the preceding job’s expected finish is still current. A small delay could remove the feasible option, so the planner may prefer a less fragile alternative.
Suppose Technician B is available at 11:00 but lacks a required product qualification recorded in the service system. The agent should not select B to improve the booking rate. It can explain to the planner that availability exists but the skill constraint is not met. Any change to that requirement needs the designated service owner’s approval.
The customer selects 11:00. Before confirmation, the system checks whether the resource is still available and creates the booking through the authoritative scheduling system. A proposal shown several minutes earlier may be stale. The agent should say “confirmed” only after the relevant system accepts the commitment and the required acceptance conditions are met.
Use a constraint sheet that a planner can challenge
| Constraint | Type | Source and treatment |
|---|---|---|
| Visit duration | Mandatory planning input | Approved service template; unknown cases go to a planner |
| Site access window | Mandatory | Customer-confirmed window with date and timezone |
| Technician skill | Mandatory | Current authorised skill record |
| Travel and preparation | Mandatory buffer | Approved estimate and policy; uncertainty disclosed |
| Preferred technician | Preference unless agreed otherwise | Customer request; show trade-off if it delays service |
| Earliest appointment | Optimisation preference | Choose only among feasible slots |
Do not ask the language model to solve a large routing or resource-allocation problem by intuition. Use deterministic constraints or an appropriate scheduling engine, with the agent gathering inputs and explaining options. If no feasible slot exists, return the conflicting constraints and the owner who can resolve them. A proposed compromise should remain visibly unconfirmed.
Keep proposals, holds and confirmations separate
A proposed slot is an option. A temporary hold, if the scheduling system supports it, reserves resources for a stated period. A confirmed booking is the accepted commitment. Define how each state expires or changes. Do not describe a hold as a booking or assume a hold exists because the agent stores a note in conversation memory.
Use an explicit confirmation protocol: restate service, date, start and end time, location, participants, any relevant charge or cancellation term supplied by the approved policy, and the action the user is accepting. Then recheck availability and execute the authorised booking. If approval is required from a coordinator or customer, record it against that exact proposal.
Prevent double booking under concurrent requests. The scheduling system should enforce resource constraints at the point of commitment. The agent’s earlier availability check is insufficient because another process can act between checking and writing. After a timeout, look up the operation or booking identifier before retrying.
If only part of a multi-resource booking succeeds, do not announce a completed appointment. Resolve or release the partial reservation according to the approved process. A room booked without the required technician is an operational exception, not a usable service slot.
Minimise calendar exposure
Google’s Calendar sharing documentation distinguishes free/busy access from access to event details. That supports a useful design choice: use availability information when event descriptions are unnecessary. A scheduling agent does not automatically need to read every private meeting title.
Apply permissions separately to reading availability, creating events, changing attendees and cancelling bookings. A person may be able to propose time with a colleague without authority to move that colleague’s existing commitments. Keep service calendars and personal calendars distinct where the organisation requires it.
Show participants only the information needed for their appointment. Internal notes, unrelated customer addresses and another employee’s personal commitments should not appear in a generated invitation. Use the security architecture to enforce resource and data boundaries outside the conversational model.
Handle timezones and Arabic date expressions explicitly
Store the appointment’s timezone using an unambiguous identifier, alongside the actual instant and local display. When coordinating across regions, confirm which location’s time the customer means. A date such as 03/04 is ambiguous without a convention; ask or restate the month by name rather than guessing.
If a user supplies a Hijri date while the scheduling system uses Gregorian dates, use an approved conversion source and confirm the resulting date with the user. Do not infer a calendar convention from the language alone. For recurring appointments, define whether the local wall-clock time or another reference must remain fixed when timezone rules change.
Test Arabic expressions for morning, evening, the following week and “after the current appointment”. Preserve numbers and location names accurately. A natural Arabic confirmation should still state the exact date, time and place. The Arabic agent guide covers the wider language tests; scheduling adds temporal ambiguity and commitment verification.
Rescheduling is a controlled change to an existing promise
When a customer asks to move a visit, identify the correct booking and verify authority to change it. Present the impact before execution: new time, resource changes, related bookings and any applicable policy conditions. The agent should not cancel the original appointment until the agreed rescheduling process can protect the customer from losing both options.
Define what happens when a technician is delayed, a site becomes inaccessible or a customer does not attend. The agent can collect the new facts and prepare alternatives, while the service owner decides priority changes outside the approved rules. Keep customer notification status visible; changing a calendar silently is not a completed reschedule.
For new employees’ induction sessions, the onboarding agent should supply the prerequisites and start-date state. Scheduling should not confirm an induction that depends on an unapproved start date or unavailable equipment.
Measure feasible commitments, not invitations sent
Track appointments completed as planned, double bookings, reschedules caused by missed constraints, time to confirmation and customer effort. Distinguish a customer declining an offered slot from the system proposing an impossible slot. Those outcomes require different improvements.
Evaluate boundary cases: a booking made concurrently, a repeated confirmation message, a hold expiring during approval, a changed address, an ambiguous date and a resource removed from service. Require the system to preserve the original booking when a change fails, or clearly surface the partial state if the platform cannot do so automatically.
Use monitoring to detect stale calendars, repeated integration errors and rising manual overrides. A high booking count can conceal a growing coordination burden if staff repeatedly repair appointments after confirmation.
For custom scheduling-agent development, agree the service catalogue, constraint engine, calendar permissions and confirmation authority. Request information about a scheduling agent with a redacted appointment, its resource requirements and a reschedule that went wrong. These reveal the commitments the agent must preserve, not just the slots it can display.