Consider a dispatch desk with one load and two appointment times. The transportation management system says Tuesday at 9 a.m. A warehouse email says Wednesday at 11. The carrier portal still shows Tuesday. Before anyone can tell the driver where to be, someone has to work out which commitment survived the last phone call.
This is an illustrative workflow, not a customer case study. It is also a useful place to be specific about AI automation. An agent can read appointment emails and operate a booking portal. The harder requirement is keeping an accurate record of what was requested, what the facility accepted, and what still needs a dispatcher’s decision.
Give each stop a booking record
Start with the load and its stop, not the email thread. A load can visit several facilities, and a single thread can discuss several loads. Purchase order numbers can repeat across partial shipments. Matching on a subject line is not enough.
The booking ledger is a durable record for each appointment, with a history of changes. It can live inside the TMS if that system supports the necessary fields and events. Otherwise, use a small integration database linked to the TMS. Dispatch should still work in its existing queue; the ledger does not need to become another screen to check.
- Identity: load ID, stop ID, facility ID, and external booking reference.
- Requested window: the earliest and latest acceptable arrival, with the facility’s time zone.
- Confirmed commitment: accepted time, confirmation source, and the time that evidence was received.
- Control fields: current status, record version, pending action, and the person responsible for an exception.
Keep the original message or portal receipt linked to the record. Store timestamps in UTC for comparisons and retain the facility’s named time zone for display and business rules. “9 a.m. Central” is not a fixed UTC offset throughout the year. If a message leaves the date or zone ambiguous, ask for clarification before committing a slot.
A request is not a confirmation
Suppose the agent sends a request for Wednesday at 11. That creates a pending request. It does not replace Tuesday’s confirmed appointment. An acknowledgment that says “received” is not evidence that the facility accepted Wednesday.
Define explicit states such as requested, confirmed, change pending, cancellation pending, and cancelled. Track completion separately from booking confirmation: a confirmed appointment does not prove that the truck arrived or was unloaded. A change pending record should retain the old commitment and the proposed replacement until the facility resolves the change.
“The agent sent the request” and “the warehouse confirmed the slot” are different operational facts. Dispatch needs to see the difference.
Agree on confirmation authority for each facility. One may treat its portal as authoritative; another may accept bookings through a designated scheduling mailbox. A newer email does not automatically override a portal confirmation. If the sources disagree and the agreed rule cannot resolve the conflict, keep both pieces of evidence and route the appointment to dispatch.
Check the rules before touching the portal
Facility hours belong in structured configuration. Include receiving days, holiday closures, appointment duration, booking lead time, and cancellation cutoffs. Record equipment restrictions where they affect slot eligibility. Assign an owner to maintain those rules and an effective date so an old PDF does not silently govern next month’s bookings.
The proposed slot also needs to fit the load. Check the preceding stop, the current ETA, and available driver-hours information from the approved dispatch systems. If the required information is missing or stale, the agent can propose a time, but it should not claim the route is feasible. Dispatch owns that decision.
Separate language interpretation from permission to act. The model can extract “after lunch, before three” as a candidate window for review. Code checks a validated window against facility rules. The action layer decides whether this load and facility are eligible for automatic booking, or whether a person must approve the request.
Handle the timeout before it creates a second booking
A portal submission can succeed even when the agent never receives the response. Retrying immediately may create a second appointment. Save an action record before submitting, including the intended window and the version of the booking record that authorized the action.
Use an idempotency key when the booking API supports one. For a browser-only portal, a local action key prevents duplicate work inside your system but cannot guarantee that the facility processed the request only once. After a timeout, look up the booking and reconcile its state. If the result remains uncertain, stop automatic retries and give dispatch the unresolved action with its evidence.
Guard against two workers acting on the same stop, too. A version check and an exclusive action claim can prevent an email-triggered job and a scheduled retry from submitting competing changes. A dispatcher’s manual edit must invalidate work based on the earlier version. Human changes count as state changes, not background noise.
Rescheduling needs a facility-specific sequence
Some systems can move an existing appointment in one operation. Others require a cancellation and a new booking. Those are different workflows with different risks. Cancelling first can leave the load without a slot. Booking first can violate a facility’s duplicate-booking policy.
Prefer an in-place reschedule where supported. Where it is not, follow a documented facility procedure. If no permitted sequence protects the load, let dispatch coordinate the change. An agent should not invent a temporary hold or assume the old slot will still be available if the replacement fails.
Once the change is verified, update the TMS and send the approved notification to the appropriate dispatch or driver channel. Track these downstream steps independently. If the facility has confirmed Wednesday but the TMS update fails, retry the update, not the booking. Show the synchronization failure until it is resolved.
Put decisions in the dispatch queue
“Appointment error” is not enough context for an exception. A useful queue item shows the load and stop, the current confirmed slot, the proposed change, and the conflicting evidence. It also names the deadline for a decision and offers the next permitted actions.
For example: “Tuesday 9 a.m. remains confirmed. Wednesday 11 a.m. was requested but not accepted. Cancellation cutoff is today at 3 p.m., facility local time. Contact the facility or retain Tuesday.” Include source links so the dispatcher can inspect the messages without searching an inbox.
Assign an owner and an escalation deadline. An exception sitting unread is still an unresolved appointment. Do not treat delivery to a Slack channel as proof that a person accepted responsibility.
Pilot one facility and measure the whole job
Begin with one facility whose booking procedure is documented. In shadow mode, have the agent reconcile records and propose actions while dispatch continues to book. Compare its interpretation with confirmed outcomes. Include late confirmations, duplicate messages, portal timeouts, and a manual change made while a request is pending.
Move to supervised execution after those cases work reliably. Limit initial automatic actions to the agreed routine bookings. Keep ambiguous confirmations and risky reschedules in the review queue until the workflow has evidence that it handles them.
- Measure dispatcher touch time per appointment, including review and correction.
- Track elapsed time from request to verified confirmation, separately from human effort.
- Count duplicate bookings and unresolved differences between the ledger, facility, and TMS.
- Track missed appointments and reason codes; distinguish booking errors from delays in transit.
Compare similar facilities and loads before claiming a saving. Faster request emails do not help if dispatch spends the afternoon repairing incorrect slots. The pilot should end with confirmed booking records and a measured account of the work needed to keep them correct.
Foundation AI builds agent workflows around the systems your team already operates. If delivery scheduling is a candidate, talk with us about a bounded pilot: one facility, its booking rules, and the exceptions your dispatchers handle today.