AI for Route Optimisation

AI route optimisation should produce a plan that dispatchers and drivers can actually execute. A short line on a map is not enough. The route must respect delivery windows, vehicle capacity, service time, access restrictions and the commitments already made to customers. When no feasible plan exists, the system should make the conflict visible rather than hide it inside an optimistic arrival estimate.

This guide is for dispatch managers and delivery or field-service operators. It explains how prediction and optimisation work together: a model may estimate travel or service time, while an optimiser selects a feasible sequence under stated constraints. A language model can help organise exceptions, but it should not replace a constraint-solving method with a persuasive itinerary.

Define the dispatch decision and its boundaries

Decide whether the task is daily route construction, assignment of a new job, mid-route replanning or comparison of fleet options. Identify the planning cutoff and which decisions are already committed. A morning planning process can rearrange many jobs; a live system may need to preserve the next stop because the driver is already entering the site.

Specify the objective in operational terms. Distance, driving time, overtime, vehicles used, missed appointments and service priority can conflict. Define hard constraints that cannot be violated and soft preferences that carry an agreed penalty. A cost weight should not quietly turn a mandatory customer or safety constraint into an optional preference.

Build a usable stop record

Each stop needs a verified location, customer or job reference, service duration, arrival window, load and any vehicle or skill requirements. An address string is not necessarily a usable delivery point. Confirm the correct entrance, loading area and access instructions where the business needs them. Preserve uncertainty in geocoding rather than routing confidently to a guessed point.

Time windows should state whether they constrain arrival, service start or completion. Include expected waiting, loading, unloading and administrative work. For field service, the technician may need a skill, part or tool before the visit is meaningful. A mathematically neat route can still fail if the job definition omits those requirements.

Make constraints inspectable

Route acceptance checklist

Constraint	Evidence to verify
Location and access	Confirmed service point, entrance and applicable restrictions
Time	Travel estimate, service duration, customer window and depot return
Load	Weight, volume or other capacity dimensions across the route
Compatibility	Vehicle, equipment, product handling and technician qualifications
People and availability	Driver or technician shift, breaks and applicable operating limits
Commitment	Already communicated stops, permitted changes and dispatcher approval

Google's OR-Tools time-window example demonstrates routing with travel times and permitted visit windows. Its capacity-constrained example illustrates load limits. These are technical building blocks; the business still needs to specify its real constraints and validate the returned plan.

A short route example that fails a window

Consider an illustrative van leaving the depot at 08:00. Customer A allows service to start between 08:30 and 10:00 and needs 20 minutes. Customer B allows service to start between 09:00 and 09:15 and needs 15 minutes. Depot-to-A travel takes 30 minutes, and A-to-B takes 35 minutes under the example assumptions.

Visiting A first means arrival at 08:30, departure at 08:50 and arrival at B at 09:25. B's latest service start is missed by ten minutes. The sequence therefore fails even if its distance looks attractive. The system must report the violated window, not merely display an estimated arrival time and leave the dispatcher to discover the problem.

Suppose depot-to-B travel is 40 minutes and B-to-A is 25. Visiting B first means arrival at 08:40, waiting until 09:00, departure at 09:15 and arrival at A at 09:40. Both customer start windows are met. This does not yet prove the full route is feasible: return time, shift, breaks and other constraints still need checking. The example isolates one sequencing decision.

Check capacity throughout the movement

If A requires 300 kg and B 400 kg, the outbound load is 700 kg. Adding a 400 kg stop would create 1,100 kg, which exceeds a 1,000 kg vehicle limit. A different sequence cannot solve that initial outbound capacity problem. The dispatcher needs another vehicle, a permitted split or another feasible commitment.

Pickup-and-delivery work requires a load profile across the route, not just a total. A collection can increase load after earlier deliveries have reduced it. Weight, volume and handling compatibility can each bind independently. Keep their units explicit and do not convert a volume limit into a weight limit through an unverified average density.

Model travel and service time without false precision

Use relevant time-of-day information and actual service history where available. A single average travel matrix may understate peak congestion, while a fixed service duration may miss difficult access or unloading conditions. Record which inputs are observed, estimated or manually supplied. Assess arrival-time errors by route type and operating period.

Uncertainty should influence planning buffers and customer communication. Do not present a minute-specific promise when the evidence supports only a broader interval. For Saudi operations, confirm the actual depot, site and customer calendars, local access conditions and applicable transport requirements with the operating owner. Avoid assuming a single schedule or restriction applies across every route and activity.

Make infeasibility a useful output

When constraints cannot all be satisfied, identify the conflicting jobs and the reason. Show permitted alternatives: another departure time, additional vehicle, split delivery, different appointment or deferral approved by the responsible team. Do not silently drop low-priority stops just because the optimiser uses a penalty for unserved work.

A solver may stop because its allotted search time expired rather than because no feasible solution exists. Preserve that distinction. Report whether a plan is feasible, whether some jobs remain unassigned and whether optimality was established. The business usually needs a good feasible plan in time for dispatch, but it should understand the limits of the search result.

Replan with stability as a constraint

Live information can improve a route after a cancellation, delay or vehicle issue. It can also create constant churn. Define which stops are frozen, who can approve changes and how drivers and customers receive the revised plan. A new route should carry a version and clear differences from the previous one.

Check whether the driver has acknowledged the update before treating it as executed. Prevent two dispatch systems from sending conflicting instructions. Logistics solutions should coordinate the dispatch workflow, while supply-chain operations handles wider effects on fulfilment commitments. A changed route is not a completed delivery.

Evaluate completed service under comparable conditions

Replay historical days with the information available at the planning cutoff. Include difficult addresses, failed access, unusually long service and vehicle unavailability. Compare against the current dispatcher plan using the same jobs and constraints. A benchmark that removes difficult stops before optimisation is not a fair operational comparison.

Measure on-time service, completed jobs, unassigned work, actual distance and time, overtime, replans and dispatcher effort. Inspect plan-versus-actual differences and their causes. Separate improvements from changes in job mix or customer geography. A shorter planned distance is not evidence of lower operating cost if the route creates extra waiting or failed visits.

Connect dispatch to upstream availability

Confirm that goods are ready before planning their delivery and that a field-service job has the necessary parts. Inventory optimisation can inform availability and transfers, but dispatch needs the current released state. Loading sequence and depot capacity may affect departure time and should be included when material.

For an e-commerce operation, customer promises and order cutoffs shape the route scope. For facilities service, technician skills and access appointments may matter more than carrying capacity. Use the correct job model rather than assuming that parcel delivery, maintenance visits and bulk transport share one universal routing template.

Make planned and actual timestamps comparable

Define what each event means before measuring route performance. Arrival at a site, check-in, service start and completion are different timestamps. A vehicle may reach the gate on time but wait before unloading. If the customer commitment concerns service start, using gate arrival can overstate punctuality.

Check device clock consistency, time-zone handling and how missing events are recorded. Preserve manual corrections with their reason instead of silently replacing inconvenient observations. Use the same definition for the existing process and the proposed optimiser. Otherwise a change in measurement can appear as an operational improvement.

Close the loop with dispatchers and drivers when actual service differs from the plan. The cause may be access, customer readiness, loading sequence or an inaccurate estimate. Update the appropriate input rather than simply adding a larger buffer to every stop. Accurate event definitions turn route history into useful planning evidence.

Define a controlled first deployment

Choose one depot or service area with an identified dispatcher, a verified stop dataset and clear constraints. Deliver a baseline comparison, acceptance checks, an infeasibility report, versioned dispatch output and a manual fallback. Keep the dispatcher able to inspect and override the proposal with a recorded reason.

Trusted Data's Saudi logistics AI guide provides commercial context for routing and delivery intelligence. Bring a masked dispatch day, actual arrival records and examples of infeasible jobs to discuss an executable route-planning solution through OpenForAI's AI Solutions. Use tool evaluation to compare the complete dispatch outcome rather than the appearance of the map.