Transport loading optimization: where planning breaks down
When there are ten trips, the dispatcher keeps delivery windows, batch weights, and the detour order in their head.
At thirty routes, manual trip planning turns into brute force: every new request changes chains already assembled, and decisions are made based on the morning picture, although by noon it is already different.
The delivery window schedule breaks first. Clients with narrow acceptance intervals compete for the same hours, a vehicle queues up, and dwell at the dock consumes the driver's shift even before departure.
The denser the schedule, the more expensive an error in the detour order: a delay at one point shifts the entire route and disrupts subsequent windows.
Second is the vehicle body. Consolidated trips are assembled “by intuition,” and a quarter-empty body looks normal until you compare it with the actual needs of the stops.
Empty mileage lives right next door: the return leg is driven empty because no one is manually looking for a suitable backhaul request anymore—it remained in the spreadsheet, but not in the route.
In sum, the task stops being linear.
The number of feasible combinations “order—vehicle—window” grows faster than the fleet, and transport loading optimization hits the human limit: no person can physically check all the variants that would produce both a full body and short empty mileage. Let's break down how this is addressed.
What AI trip and route planning delivers
A planner built on AI trip planning calculates not an individual route but the entire matrix of orders for a shift: delivery windows, driver work schedules, and cargo-body compatibility.
The problem is solved on a solver of the OR-Tools class, so the effect is visible not on a single trip but on fleet utilization as a whole.
Empty mileage drops thanks to backhaul loading
For every outbound trip, the planner looks for a pair from return orders and glues them into one route if the windows and body type match.
The share of empty mileage decreases from 30–35% to 12–15%, and the remaining runs become short approaches to the next point instead of a return to base.
Average body load and fleet utilization increase
Instead of the manual “whoever is free gets loaded,” the algorithm balances load between vehicles and fills underloaded trips with on-the-way orders.
Average body load evens out across the fleet: the spread where some vans run at half volume while others are overloaded disappears.
More stops fit into one trip
The route is assembled based on the actual geometry of passages and unloading time, not average standards. The number of stops per trip grows by 15–25% without violating delivery windows—trips that were previously split into two now run as one.
A class of planning failures disappears
Failures due to driver schedule conflicts, weight overload, and double assignment of a vehicle to two orders disappear. The dispatcher sees the reason an order did not enter the plan instead of manually editing routes.
Transport planning modes: rules, heuristics, model
The planning mode is chosen not by how “smart” the algorithm is, but by what data the carrier has and how strict the constraints that must be held in the plan are.
The more non-formalizable exceptions there are in a shift, the more expensive a planner error is—and the more important it is that the mode matches it.
Below are four options that are actually chosen between when building transport loading optimization. They do not replace each other: rules set boundaries, heuristics provide speed, and the model provides plan quality.
Three modes and their boundaries
| Option | When it fits | Constraints |
|---|---|---|
| Hard rules | Fleet and route legs are stable, regulations are fixed, an explainable shift plan is needed | Does not find non-obvious consolidations: load grows only by revising the rules themselves |
| Planning heuristics | A fast plan for the day is needed, conditions change partially | The solution is close to manual, quality depends on the rule set, and on complex routes it is inferior to optimization |
| Model on historical data | There are waybills and telemetry for a season, demand fluctuates | Sensitive to data quality and rare events, the ready plan needs verification |
| Mixed planning | Need to simultaneously maximize load and stay within the driver's work and rest schedule | Requires transparent logs: without an explanation of the plan, the dispatcher stops trusting the system |
Mixed planning usually becomes the working one: the model proposes routes, rules cut off inadmissible ones, and driver work schedule constraints are held by a separate layer of checks. The choice after that is up to your operational reality.
How implementation proceeds: from data audit to handover
Implementation begins not with the model but with data.
Until it is clear what trip exports the customer has and what condition they are in, any transport loading optimization remains theory—so the first weeks go into analyzing actual data and agreeing on what the system considers a good plan.
- Trip data audit. We analyze exports from accounting systems, telematics data, and logistics spreadsheets: completeness of records, duplicates, discrepancies in time and weight, gaps in route points. The result is a source map and a list of what we restore and what we exclude from the calculation.
- Objective function definition. We fix exactly what we optimize: total mileage, share of empty runs, adherence to delivery windows, or a weighted combination thereof. Constraints—payload capacity, driver work schedule, cargo compatibility—are agreed in writing; this is the basis for acceptance.
- Pilot on historical trips. We run the system on past trips and compare its plan with the actual one: where mileage was reduced and where the proposed route is infeasible. We verify the logic before it touches live transportation.
- Setup in the operational environment. We connect the system to current sources, configure exchange and access rights, and agree on how the dispatcher accepts or rejects the proposed plan.
- Production launch. We move planning into daily mode, monitor load metrics and calculation stability, and retrain the rules on new data.
- System handover. We hand over configurations, exchange schemes, regulations, and instructions, train dispatchers, and support the customer's team through the first planning cycles.
What remains with the customer: configurations, schemes, regulations
The tangible result of implementation is not a report or a demo but a working environment that your team can support and develop without us.
That is why we hand over the configured system, its description, and operating rules: everything needed so that planning remains manageable when volumes, routes, and people change.
- Planner configuration: client and cargo type priorities, constraints on capacity, delivery windows, and cargo compatibility in one trip; parameters are collected into an editable set—they can be changed without editing code.
- Integration scheme with accounting systems: which reference data and events come from where, at what frequency, what happens when a source is unavailable, and where the boundary of responsibility between systems lies.
- Replanning regulations: in which cases recalculation is triggered automatically (new order, cancellation, missed window) and where the decision remains with the dispatcher; the plan freeze window before vehicles depart.
- System documentation: description of the allocation logic, a parameter reference with permissible ranges, and instructions for the dispatcher and administrator.
- Responsibility matrix: who owns the reference data, who approves rule changes, who investigates discrepancies between plan and fact.
- Decision log: preserving the reasons an order was assigned to a specific vehicle—for reviewing disputed situations without reconstructing the logic after the fact.
- Validation scenarios: reference days with a known result, which show that after configuration changes the solution has not degraded.
Case study: fleet utilization and empty mileage before and after
A fleet of 140 vehicles planned trips manually in the 1С:УАТ accounting system: the dispatcher assembled route legs based on experience and phone arrangements, and looked for backhaul loading only after unloading.
Vehicles left with a partially filled body, the return mileage often ran empty, and fleet utilization was held up by month-end crunches. Delivery window failures accumulated where a new trip was scheduled immediately after the previous one, without a buffer for unloading.
We captured metrics before and after over comparable periods, and switched planning into suggestion mode: the system proposes a loading option for the body and hard delivery windows, and the dispatcher confirms or rejects it.
| Metric | Before | After |
|---|---|---|
| Share of empty mileage | 36% | 17% |
| Average body load | 62% | 85% |
| Delivery window failures | 8% of trips | 2% of trips |
| Dwell at the dock | 45 min | 22 min |
| Dispatcher time for shift plan | 3.5 h | 25 min |
What matters is not the peak figure but reproducibility. Constraints on clients, body type, and dock time are fixed by rules, so the result does not depend on who is on shift.
The trip optimization case also produced a side effect: the freed-up time is spent by the dispatcher on non-standard trips and reviewing deviations, rather than on routine brute-force enumeration of options.
What to do if some trips are already planned manually
Partial automation is a standard mode, not an intermediate stage that must be outgrown as quickly as possible.
The planner connects to what already exists: a register of orders in spreadsheets, a reference of addresses and time windows, constraints on body, tonnage, and driver work and rest schedules.
At the output, the dispatcher receives not a blank sheet but a ready draft of routes that remains to be checked and, if necessary, corrected.
The transition from manual schedules proceeds one area at a time. First, a direction or group of vehicles where data is already maintained carefully is taken into calculation, and the machine plan is compared with what the dispatcher built by hand.
When the discrepancy in mileage and departure time becomes explainable, the area is moved to automatic calculation, and the next one is connected after the first has completed a full cycle.
Unplanned orders are handled by a separate rule. An urgent order is either added into an already formed route if it fits the time and load corridor, or gets a separate vehicle with priority by delivery window.
The dispatcher can at any moment disable automation and replan manually—the system suggests an option rather than blocking decisions.
The point of phased implementation is that the current process does not stop for even a day.
Alongside the new environment, the familiar schedule continues to live, data from spreadsheets enters the system at every step, and the share of trips calculated without edits grows from week to week.
If the result diverges from expectations, the area returns to manual planning without losing prior work.
Frequently asked technical questions about data and model accuracy
Doubts at this stage are usually the same: will there be enough data, will the calculation diverge from reality, and what to do when an order arrives outside the plan. Below are four questions most often raised by the customer's team before the start.
Transport loading optimization begins not with the model but with an inventory of sources: a reference of points, body constraints, and a history of actual departures.
Data is in Excel and three systems—will that be enough?
To start, a history of trips and a reference of points with delivery windows is enough. We consolidate sources into one layer, mark gaps, and define filling rules; where there is no history, constraints are entered explicitly and agreed with the dispatcher.
How to verify that the plan is feasible, not just “optimal”?
Every route passes a constraint check: tonnage and volume, driver work schedule, delivery windows, vehicle availability.
Infeasible options are cut off before output—the calculation runs on the OR-Tools solver, and we verify accuracy against facts: the share of trips without manual edits and missed delivery windows.
What happens to an urgent order in the middle of the day?
Recalculation runs on the current state of the fleet: free vehicles, already started trips, nearest windows. The order is embedded into a route with minimal mileage deviation, and changes go to the dispatcher and driver.
What happens after launch—do we support everything ourselves?
No. We hand over the configuration, validation rules, and documentation, and train dispatchers. Support is by agreement: we monitor data quality and model accuracy, and revise constraints when the fleet changes and new points appear.
Let's discuss the task: what data to send for assessment
To come back with an assessment and work plan rather than generalities, one set of inputs is enough for us. Below is the minimum data set for assessment: it can be assembled by your accounting system in a couple of hours and does not require stopping processes.
If some items are missing, this does not block discussion of the task; the absence of data is also part of the work.
- Trip export for a representative period: date, direction, vehicle, actual departure and return time.
- Order data: stop addresses, delivery time windows, cargo weight and volume, body type.
- Vehicle and driver reference: capacity, tonnage constraints, available shift time.
- Downtime history: waiting time during loading and unloading, causes of failures according to fact, not regulations.
- Current allocation rules: who and by what logic currently assigns a vehicle to trips.
- Constraints: warehouse working hours, service zones, client priorities, night departures.
- Target indicators: what we consider improvement—load share, number of trips, repeat departures.
Format does not matter: exports from the accounting system, spreadsheet files, or a set of reports are suitable—we will bring them into a unified form on our side.
Describe the task in free form and attach what you already have: we will return with a scope estimate, work composition, and stage timelines. If there is not enough data yet, we will propose a minimal slice that will cover the transport loading question.