AI for Logistics, Transportation, and Supply Chains

Translate operational requirements into constraints, then check every proposed plan against them.

A delivery plan can have a short route and still fail. It may arrive after a receiving window, exceed vehicle capacity, or return too late for the next assignment. A tidy list of stops does not establish feasibility.

AI is useful for extracting constraints from instructions, organizing demand records, and explaining alternatives. Route selection itself needs a representation that can be checked: locations, travel times, service durations, capacity, windows, and the objective being optimized.

This article works through a complete small example. Its travel times and requirements are fictional. No real route has been dispatched.

Separate the objective from the hard constraints

An objective tells you what you prefer among feasible plans: less travel time, lower cost, fewer late deliveries, or greater resilience. A hard constraint tells you what a plan must satisfy.

If a receiving window is mandatory, a shorter route that misses it is infeasible. If lateness is allowed at a penalty, that is a different problem and must be stated explicitly. Do not let a model convert one into the other because it produces an attractive answer.

Some requirements are preferences rather than constraints. “Prefer the usual driver” is different from “only a driver with the required authorization may take this assignment.” Preserve the distinction when converting natural-language instructions into a worksheet.

Google’s operations-research documentation provides a concrete example of routing with travel-time data and visit time windows. It illustrates why these requirements belong in a formal model rather than only in prose. See OR-Tools’ vehicle routing problem with time windows. Using an optimizer still requires correct inputs and appropriate interpretation of the returned solution.

Write the complete teaching packet

Our fictional vehicle begins at depot D and serves stops A, B, and C. It carries six cartons, two for each stop. Vehicle capacity is six cartons. There are no pickups, split deliveries, reloads, or other stops.

The normal departure is 9:00 a.m. An approved alternative departure as early as 8:50 a.m. is available for this exercise. The vehicle must return to D by 10:30 a.m. Service takes ten minutes at each stop.

Receiving windows apply to the start of service. A vehicle may arrive early and wait. This definition is important: a requirement to finish service within the window would produce a different check.

The symmetric travel-time matrix is:

All entries are minutes. These fixed teaching values exclude additional traffic, loading, and break requirements. In a real packet, identify the source, retrieval time, directionality, vehicle restrictions, and validity period of travel estimates. Do not assume real travel times are symmetric because this example is.

Check a feasible route step by step

Consider D → A → B → C → D, departing at 9:00.

Each service starts within its window. The initial load equals capacity, and the load decreases after every delivery. Return is ten minutes before the deadline.

Travel time is 10 + 10 + 10 + 20 = 50 minutes. Service adds 30 minutes. With no waiting, total elapsed time is 80 minutes.

This demonstrates feasibility under the supplied assumptions. It does not prove that this route is globally optimal. An optimality claim requires a suitable method and evidence about the alternatives or solver result.

Check a route that looks equally efficient

Now reverse the visit order: D → C → B → A → D, still departing at 9:00.

The travel total is again 50 minutes. A quick summary might call the routes equivalent. The receiving windows show otherwise.

The route requires twenty minutes of waiting at C. Its elapsed time is therefore 100 minutes, even though travel and service totals are unchanged.

This is why a schedule must calculate waiting explicitly. Starting service at C at 9:20 to preserve an attractive return time would violate the packet. Ignoring the receiving window would not solve the original problem.

The useful AI output is a rejection with a reason: “This ordering is infeasible because A is served too late and the vehicle returns after the deadline.”

Test a disruption before claiming resilience

Return to the feasible route. Suppose travel from A to B takes fifteen minutes longer than the matrix value. All other travel times remain unchanged.

With the 9:00 departure, service at A still ends at 9:20. Travel to B now takes 25 minutes, so B is served from 9:45 to 9:55. C is served from 10:05 to 10:15. The vehicle returns at 10:35.

All three service-start windows are satisfied, but the return deadline fails by five minutes. A system that checks only customer windows will miss the failure.

The approved 8:50 departure provides a feasible alternative for this specific disruption:

The change uses a permission explicitly present in the packet. If the driver or depot cannot support an earlier departure, AI cannot invent that availability. It must present another feasible alternative or identify that the constraints cannot be met with the available resources.

Passing one disruption test is not proof of general robustness. Record the scenario tested and the remaining margins.

Bring inventory and capacity into the same discipline

The example uses cartons as its capacity unit. Real operations may also be constrained by mass, volume, temperature requirements, loading sequence, or item compatibility. A plan that satisfies one capacity measure may violate another.

If an additional carton is added to the teaching route, the starting load becomes seven and exceeds the six-carton capacity. The model must flag the conflict. It cannot merely add the item to the stop list and leave the route marked feasible.

Inventory planning needs similar definitions. Distinguish stock on hand, stock already committed, expected receipts, and demand. An order in transit is not physically available just because it appears in a purchasing system.

Dates and units can create subtle errors. Cases, cartons, and individual items may represent different quantities. A demand record for next week should not be combined with today’s availability without the relevant lead-time assumptions.

Give the operator a plan they can inspect

A useful route packet includes the dated input version, route sequence, load assumptions, arrival and service times, waiting, return time, and unresolved conditions. It should also identify who can approve changes.

The explanation should distinguish an AI-drafted candidate, a solver-generated candidate, a checked feasible plan, and an actually dispatched route. These are different statuses.

Keep a manual fallback for missing data or unavailable systems. That fallback may be the organization’s existing dispatch process. AI should not improvise new driver instructions when the current plan cannot be verified.

After execution, compare actual arrival, service, and travel times with the assumptions. Record reasons for deviations so a later planner can distinguish a bad estimate from an unusual event.

A reusable prompt

Translate this logistics problem into objectives, hard constraints, preferences, required data, and unresolved assumptions. Use the supplied travel matrix and service rules to calculate arrivals, waiting, service starts, departures, loads, and return time for each candidate route. Reject infeasible plans with the exact violated constraint. Do not assume additional capacity, earlier departure, split deliveries, or relaxed windows unless authorized in the packet. Distinguish feasibility from optimality and a proposed plan from a dispatched route.

For students: act as planner and checker

Work in pairs. One student proposes a route; the other independently calculates the schedule. Exchange roles after changing one constraint.

Mathematics students can enumerate the six possible visit orders. Computing students can write a checker before attempting an optimizer. Business students can discuss the cost of extra capacity versus a changed service promise, keeping both options subject to actual approval.

Use the fictional matrix. You do not need real customer addresses or driver records to learn scheduling logic. If you use a map later, verify that its travel estimates match the vehicle and timing question.

Practice: explain the failed route

Recalculate both routes from the packet. Include early-arrival waiting. Then apply the fifteen-minute A-to-B delay to the first route with both allowed departure times.

Write a short operator note identifying which plan meets all constraints in each scenario. Include the remaining return margin and explain why matching total travel time does not make two routes equivalent.

Completion check: The normal A–B–C route returns at 10:20; the C–B–A route returns at 10:40 and misses A’s window; the delayed 9:00 departure returns at 10:35; and the delayed 8:50 departure returns at 10:25. Capacity and service-start definitions are checked explicitly.

Stretch: Enumerate all six visit orders and compare feasible routes under two additional fictional disruptions. Report what you tested without calling the best observed route globally robust.