Test route optimisation against delivery windows and service time

The route planner puts the nearest customer first. That customer takes more than an hour to unload, so the next delivery misses its receiving window. The map looks efficient because it represents driving more carefully than the work performed at each stop.

Test route optimisation against the whole service schedule. The first question is whether the sequence can satisfy the agreed constraints. Distance and cost become useful comparisons after that feasibility check.

Define the promise at each stop

A window of 09:00–10:00 can mean several things: arrival during that period, starting service within it, or completing service before it closes. Confirm the customer's meaning and record it with the order. A planner that uses arrival time against a completion deadline will overpromise systematically.

Capture unloading method, service duration, appointment status, vehicle suitability, access restrictions and order dependencies. Use approved driver work and rest requirements for the actual operation; do not substitute a generic maximum driving period.

Travel time needs its own basis: route, departure period, vehicle type and observation or model date. Distance alone is insufficient where access, congestion or time-dependent restrictions change the usable path.

Oracle Transportation Management documents service-time methods with calendars, external estimates and simulation inputs. The relevant method and configuration must be demonstrated in the deployed version. Oracle Transportation Management 26C — Rate Service Details

A shorter route that fails the receiving window

This illustrative comparison uses two candidate routes on 15 October 2026 in Asia/Kolkata. Departure is 08:30. Customer A accepts service completion by 12:00 and needs seventy minutes on site. Customer B requires service to start no earlier than 09:00 and finish by 10:00; it needs twenty minutes.

The directed road inputs are fictional: depot–A is ten kilometres and twenty minutes; A–B is twelve kilometres and twenty-five minutes; B–depot is twelve kilometres and twenty-five minutes. Depot–B is eighteen kilometres and thirty-five minutes; B–A is twelve kilometres and twenty-five minutes; A–depot is ten kilometres and twenty minutes. Direction can change the usable road path.

The 34-kilometre candidate misses B's completion deadline by forty-five minutes. The 40-kilometre candidate meets both windows and returns ten minutes later. It is the feasible choice among these two candidates, assuming the other stated requirements are satisfied.

If the tool ignores service duration, it can present an attractive but false schedule. Ask it to display arrival, waiting, service start, service end and departure for each stop rather than a single arrival column.

Separate hard constraints from preferences

A confirmed receiving window may be a hard constraint. A preferred driver or a desire to minimise kilometres may be negotiable. Make the distinction explicit and define who can authorise a changed commitment.

Do not resolve infeasibility by hiding a stop, shortening its service duration or treating a required check as optional. The output should show the unserved order and the constraint responsible. The planner can then seek an approved later appointment, another suitable vehicle or a different allocation.

For the feasible route above, a fifteen-minute delay on the first leg moves B's service to 09:20–09:40. Twenty minutes remain before B closes. A forty-minute delay would move service to 09:45–10:05 and make the route infeasible. This sensitivity identifies which leg needs close monitoring.

These are scenario calculations, not statistical confidence intervals. A claim that a route has a 95% chance of meeting its window requires an appropriately tested uncertainty model and representative data.

Check load and sequence together

A feasible driving sequence can still conflict with the load arrangement. If B is first, its goods need an approved accessible position without inappropriate handling of A's goods. Conversely, a load arrangement that fixes the unloading order can restrict the route options.

Link each stop to its allocated quantities and handling units. A partial order or changed vehicle requires a new feasibility check, including capacity and the remaining stops. Avoid treating a reroute as a map-only change after the truck is loaded.

Compare methods on the same work

A manual sequence with explicit stop times is a useful baseline for a small fleet. A native TMS optimiser is valuable when it represents the actual constraints and explains exclusions. A specialist routing service may add useful travel estimates, but the integration must preserve order identity and policy constraints.

Use a fixed order population and the same input versions for each comparison. Count all original orders, including those deferred or assigned to an exception vehicle. A lower cost per planned stop can hide an expensive remainder.

Measure completed commitments, total operating effort, kilometres, extra vehicles and manual interventions. Record the original plan alongside the executed route. Rewriting the plan after each delay can make historical adherence look perfect.

Make the demonstration include a failure

Provide a tight receiving window, a long service stop, a vehicle restriction and an order amendment. Require the presenter to show both a feasible plan and an honest infeasibility explanation. Export the stop schedule so another planner can reproduce the arithmetic.

For a route-planning assessment, begin with the stop whose service work or receiving window is most often missing from the current calculation.

Optimise the journey the driver must actually perform

The useful route is a sequence of achievable services, not merely nearby addresses. Once the commitments are feasible, the business can compare the cost of the alternatives transparently.

Next actions

1. Define each stop's window and service duration precisely.
2. Reproduce a difficult route as a stop-by-stop schedule.
3. Test delays, changed quantities and loading-order restrictions.
4. Compare feasible alternatives with the full original order population visible.