Schedule the site visit as one linked booking: check the technician, vehicle, travel time and customer access together, hold the feasible slot, then confirm only after every reservation succeeds. A calendar gap alone is not enough. If access is uncertain or a resource cannot be reserved, leave the visit unconfirmed and give a dispatcher a clear exception to resolve.
The procedure below is a proposed design for a South African field-service team. Its timings, records and operating rules are hypothetical, not tested results or native features of a scheduling product.
1. Define what makes the visit bookable
A visit is bookable only when the full resource combination can complete the work within the customer's access window.
Start with the job requirements, rather than asking which technician is free. Record the work type, estimated duration, site address, required skills, vehicle type and any equipment that must travel with the team. Name the person responsible for confirming access.
Separate hard constraints from preferences. Under this proposed approach, a required technical authorisation is a hard constraint; a preference for the customer's usual technician is not. A vehicle that cannot carry the equipment is unsuitable even if its calendar is empty.
Give a dispatcher ownership of unresolved constraints. Safety, site security and employment arrangements need appropriate human judgement, not a model's interpretation of an email.
This is a suitable brief for workflow automation: coordinate an operational decision across systems. Do not treat it as a request to let an assistant write calendar invitations without checking the underlying commitments.
2. Capture a complete request before searching
Collect enough verified information to calculate a feasible slot, and keep missing information visible.
Use a booking record containing the customer and site identifiers, exact address, requested date range, access-window start and end, job duration, skill requirements, vehicle requirements and access contact. Store dates with an explicit timezone and show customers the local appointment time.
Also record where each important detail came from. An address confirmed by the customer should not silently become an address inferred from an old job. Keep access status separate from the contact's name: knowing who manages the gate does not prove that the gate will be open.
AI can help turn messages into fields. Source: OpenAI's Structured Outputs documentation describes schema-constrained responses. A correctly shaped record still needs business validation; a populated address or date is not evidence that it is correct. Check model and schema compatibility when choosing an implementation.
For customer-record handovers, the AI CRM integration guide provides related context. Here, the important boundary is between customer information and confirmed operational availability.
3. Check linked calendars and physical readiness
Check all required resources over the same proposed interval, then verify that they are operationally suitable.
Map each technician and vehicle to an authoritative resource identifier. Document where leave, maintenance, training and manual allocations are recorded. If a vehicle calendar omits workshop bookings, it cannot be the sole source of availability.
Source: Microsoft Graph's calendar documentation lists calendar-view, free/busy and event-creation operations. It also distinguishes calendar permissions and user-calendar behaviour from group-calendar behaviour. These capabilities support integration, but do not establish the proposed linked-booking process as a built-in feature.
Before selecting a calendar connection, have the implementer verify permissions and how each resource is represented. Check recurring-event exceptions as well as ordinary appointments. An unreadable calendar means availability is unknown, not free.
Combine calendar results with readiness checks: technician suitability, vehicle service status, equipment allocation and site restrictions. Keep private appointment details out of the dispatcher view unless genuinely needed and authorised. Security and data-access decisions belong with the responsible people.
4. Calculate the whole occupied interval
Reserve the time needed to reach, complete and leave the visit, not just the customer-facing appointment.
For each candidate, calculate travel from the technician's preceding location and onward travel to the next commitment. Include vehicle collection, loading, site induction and return tasks where applicable. Technician and vehicle occupancy may differ, so calculate both explicitly.
In a hypothetical plan, a 10:00 to 11:30 site visit might require technician occupancy from 09:15 to 12:00 and vehicle occupancy from 09:00 to 12:15. These are illustrative values, not recommended universal buffers.
Use an approved source for travel estimates or a dispatcher-approved fallback. Store the estimate's source and the additional buffer separately. If either neighbouring location is unknown, ask for review rather than assuming travel from the depot.
Check whether induction must occur inside the access window and whether the technician must leave before it closes. Do not squeeze preparation or breaks out of the plan to make a slot fit. A dispatcher should assess working-time and safety implications before accepting an exception.
5. Hold the slot without promising it
A hold should temporarily protect a feasible combination while keeping the customer informed that the visit is not confirmed.
Use explicit proposed states: needs_information, candidate, held, reserving, confirmed, exception and cancelled. Each transition should have a recorded reason and owner. Define what a hold blocks in each connected system; a label in the booking database alone may not block calendar time.
Choose a hold-expiry rule with operations staff. A hypothetical rule might release an unanswered hold after 15 minutes, but the actual period must fit the customer's response channel and dispatch process. Release every linked hold together, and record failures to release.
Before holding, recheck the latest resource availability. Customer access should already be verified under this proposed workflow. If access is still pending, keep the record in needs_information and offer provisional options without reserving resources indefinitely.
A message should say: “This time is being checked and is not yet confirmed.” Avoid a normal confirmation template for a hold, because customers may reasonably treat that wording as a commitment.
6. Reserve, verify and recover partial failures
Confirm only after the application has evidence that every required reservation succeeded.
Use one booking reference across the technician reservation, vehicle reservation and access record. Recheck constraints immediately before writing. Where the systems allow it, use conditional writes or application-level coordination to manage simultaneous requests. Availability checks alone do not guarantee exclusive ownership of a slot, especially when people can book outside the workflow.
Source: OpenAI's function-calling guide explains that the model requests tools and application code executes them. Put permission checks, reservation rules and confirmation gates in that code. A model saying “booked” is not a booking receipt.
Store returned reservation identifiers and verify resource, interval and status. If the technician reservation succeeds but the vehicle fails, attempt to release the technician reservation and leave the visit unconfirmed. If release fails, assign an exception with the remaining reservation details.
For a timeout, inspect the destination before retrying. Reuse a stable operation key so a repeated request can return the existing result rather than create a duplicate. Queue confirmation only after verification, and track message delivery separately from booking status.
7. Handle changes and evaluate the workflow
Treat rescheduling as a new feasibility check, and evaluate exceptions before expanding automation.
A customer moving the access window can invalidate travel, vehicle allocation and the next appointment. Recalculate the whole combination rather than editing only the invitation. Where feasible, secure the replacement before releasing the original; if that would create a conflict, let a dispatcher manage the transition and customer communication.
For cancellations, release every linked reservation and verify the result. Record any resource still blocked. After confirmation, assign responsibility for checking material changes such as vehicle breakdowns or withdrawn site access.
Evaluate a limited pilot using proposed measures: confirmations without complete reservation evidence, duplicate bookings, incomplete releases, access-related failures and dispatcher handling time. Compare like-for-like work with the previous process. Record exceptions rather than assuming automation will reduce them.
Broader AI automation may support intake and communication. The sales and marketing workflow guide covers adjacent handovers, but a sales promise must not override resource checks. For terminology, see the AI CRM integration glossary.
Reusable linked-booking release checklist
Use this proposed checklist as the release gate for each visit. Adapt it with the dispatcher and implementer before use.
Booking reference: ______ Dispatcher: ______ Requested window: ______
- Site identity, address, timezone, job duration and requirements are verified.
- A suitable technician and vehicle have authoritative resource identifiers.
- Access contact, permitted window, induction and entry requirements are confirmed.
- Technician and vehicle intervals include approved travel and preparation allowances.
- Current calendars, maintenance and other operational blocks have been checked.
- Linked holds have recorded identifiers, expiry and release responsibility.
- Final availability checks passed before reservation writes.
- Every reservation has a receipt matching the resource, interval and booking reference.
- No unresolved partial write, timeout, duplicate or release failure remains.
- Confirmation states the visit window, access arrangements and change contact.
| Finding | Proposed action | Owner |
|---|---|---|
| Access missing or ambiguous | Request clarification; do not hold or confirm | Dispatcher |
| Resource conflict | Recalculate alternatives | Scheduler |
| Write outcome unknown | Inspect destination before retrying | Implementer |
| Partial reservation | Release successful writes; escalate failed releases | Dispatcher and implementer |
| Matching request already exists | Return existing status; review conflicting details | Dispatcher |
Release decision: Confirm only when every check passes. Otherwise record the exception, owner and next action.
Hypothetical walkthrough: success, missing access and a duplicate
The normal case confirms only after matching evidence exists for the whole visit.
Consider a hypothetical equipment inspection in Midrand. The customer has verified access from 10:00 to 12:00, including the required induction. The proposed job lasts 90 minutes. Technician Thandi is suitable; vehicle V-04 can carry the equipment. The dispatcher approves the illustrative occupancy intervals of 09:15 to 12:00 for Thandi and 09:00 to 12:15 for V-04.
Both resource checks pass. The application creates linked holds, rechecks availability, writes reservations and reads them back. The identifiers, intervals and booking reference match. Only then does it send the 10:00 to 11:30 visit confirmation.
Now change the request to “someone should be at the gate”. That is ambiguous access, not confirmation. The dispatcher asks who will authorise entry, when they will be available and whether induction is required. No confirmation is issued while that remains unresolved.
Finally, suppose the same request arrives by email and web form. A matching site, job reference and requested window should trigger duplicate review under the proposed rule. The dispatcher checks whether these are one visit or two separate jobs. If they are the same, retain one booking and return its status. Do not merge records solely because the customer names match.
FAQs
Resolve these questions through the booking record and dispatcher, rather than improvising around calendar gaps.
Can we confirm when the technician is free but the vehicle is only provisionally allocated?
No. Under the proposed gate, provisional vehicle allocation is a hold, not a completed reservation. Explain that the time remains unconfirmed. A dispatcher may choose another suitable vehicle or slot, but must check equipment capacity, preparation time and the full occupied interval again. Any substitution must appear in the booking record before confirmation.
What if the customer wants a visit before access is verified?
Offer possible windows without promising arrival. Ask the customer to confirm the access contact, permitted time and entry requirements. If the situation is urgent, a responsible dispatcher should assess it directly, including site-security and safety implications. Urgency does not turn an unknown access arrangement into a verified one, and the workflow should not bypass that distinction.
What if a reservation call times out after we press confirm?
Keep the outcome marked unknown and do not send a success message. Inspect the destination for the booking reference or operation key. If the reservation exists, verify it and continue checking the remaining resources. If it does not, retry according to the application's recovery procedure. If the evidence remains unclear, an implementer and dispatcher should reconcile it before further writes.
If your business needs help coordinating these checks, get in touch with Symaxx to discuss a scheduling specification. Start with the release checklist, resource ownership and exception rules, then decide which parts are suitable for automation.