Given these hubs and this order book, how should the freight be grouped onto trucks?
The tool takes an order book, assigns every order to its cheapest hub, then repeatedly tries to combine orders into shared truckloads. Each combination is only kept if it beats shipping those orders separately — including the option of leaving them on LTL. Constraints that planners actually live with are enforced: equipment weight and cube, stop count, out-of-route deviation, and DOT hours of service. The output is a load plan you could hand to a dispatcher, plus the numbers that tell you whether the plan is worth executing.
Who uses it
Transportation planning, network analysts, anyone preparing a consolidation business case
When
Monthly or quarterly, on the live order book
Time to first answer
About 90 seconds — generate, run, read
Quick start
From open page to a load plan
Open tab 2 and generate an order book
The tool starts with 400 synthetic orders already loaded. Move Order count to 400–800 for a fast run, then press Generate orders. Keep the seed fixed if you intend to compare scenarios — the same seed always produces the same orders.
Press Run optimizer
The solver runs Seed construction, then Break, then Move/Swap, at each radius in the sweep, then merges the best loads across all of them. The log on tab 3 narrates each stage. On 400 orders this takes a few seconds; 1,000 orders takes longer and a time budget will cut the sweep short rather than hang the page.
Read the green savings block first
That is the headline. Underneath it, Consolidation ratio tells you how many orders now share a truck, and Avg %Full tells you whether those trucks are actually loaded.
Scroll to the flags
Coloured strips call out loads that break a rule — excessive out-of-route, fill below the floor, capacity overflow, SLA misses. These are the loads a planner would argue with. Click any row in the load table to trace its route on the map.
Change one thing and re-run
The most useful single experiment is the consolidation radius on tab 3. Widen it and watch fill go up while out-of-route also goes up. Where those two cross is the practical limit for this network.
Screen map
What each tab is for
Defaults are set to a workable mid-size network. Most first-time users only need tabs 2 and 4.
Tab
What it controls
Leave it alone unless
1. Network
Hubs and their capacity, equipment types, linehaul rate and fuel surcharge, distance engine, and which baseline the savings are measured against.
You want to test a different hub set, or you have real contracted rates to put in.
2. Orders
The order book — either generated or uploaded as CSV. Weight, cube, destination and hub assignment.
Never. This is the first place to go.
3. Solver
Constraints (max stops, minimum fill, out-of-route ceiling, SLA), hours-of-service mode, which algorithm stages to run, and the radius sweep.
You are testing a policy change — a different stop limit, a wider radius, team drivers.
4. Results
Savings, load detail, flags, charts. Clicking a load highlights it on the map.
Never. This is where the answer is.
Reading the output
The five numbers that matter
Savings percentage is the least reliable of these, because it moves with the baseline assumption. The operational metrics are the ones to trust.
Metric
What it means
What to do about it
Consolidation ratio
Orders per load. 1.0 means nothing was combined; 3.0 means the average truck carries three customer orders.
Below 2.0 on a dense order book usually means the radius is too tight or the stop limit too low.
Percent full (governing)
The higher of weight utilisation and cube utilisation. Both are shown because a truck can be 95% full by weight and 40% by cube.
Below the floor means you are hauling air. Widen the radius or drop to smaller equipment.
Out-of-route
Extra miles travelled beyond the direct hub-to-furthest-stop distance, as a percentage.
Above 15% is flagged. Those lanes are usually better served direct — the consolidation is buying fill at the cost of mileage.
Loads by mode
How many single-order loads stayed on LTL rather than being forced onto a truck.
A high LTL count on light freight is correct behaviour, not a failure. Forcing everything to TL is what makes savings go negative.
Integrity check
Confirms every order was assigned exactly once, with no duplicates or drops.
If this ever fails, ignore every other number on the page.
Use cases
Three questions this actually settles
Use case 1
How far should we widen the consolidation radius?
Set up
Tab 3 → set the radius sweep to a single value, e.g. 100. Run. Repeat at 200, 400, 800, recording consolidation ratio, average fill and average out-of-route each time.
Watch
Fill and consolidation ratio rise with radius, but out-of-route rises too and the count of flagged loads grows. Total cost usually falls, plateaus, then starts climbing.
Decide
Take the radius one step before out-of-route flags start multiplying. That is the point where the plan stops being executable, regardless of what the cost curve says.
Use case 2
Which lanes should be pulled out of multi-stop and shipped direct?
Set up
Run with default settings, then sort the load table by out-of-route descending.
Watch
Loads above 15% out-of-route are drawn as dashed lines on the map. They typically cluster in one or two thin corridors where the network has no density.
Decide
Those corridors are direct-ship candidates. Set the out-of-route ceiling to 15% on tab 3, re-run, and compare total cost — if the difference is small, take the simpler plan.
Use case 3
Where is the LTL to truckload breakpoint for our freight profile?
Set up
Tab 1 → make sure Allow the solver to choose LTL is ticked and put your real CWT table in. Tab 2 → sweep average order weight from 1,000 lb upward, regenerating each time.
Watch
The share of loads staying on LTL falls as weight rises. Somewhere in the middle the solver flips from mostly LTL to mostly consolidated truckload.
Decide
That crossover weight is the threshold your routing guide should encode. Below it, consolidation costs more than it saves.
Pitfalls
Where people misread this tool
Every one of these has actually happened during testing.
Savings percentage moves with the baseline, not with your plan
The figure is measured against whatever baseline is selected on tab 1. Change the hub set and the baseline changes too, so a higher savings percentage can accompany a higher absolute cost. When comparing network options, compare total freight cost in dollars — never the percentage.
Distance is estimated, not routed
Great-circle distance multiplied by a regional circuity factor. Benchmarked against real highway mileage it runs about 5.8% mean absolute error, worst case 15.9%. On a six-stop load those errors compound. Read the output as a comparison between scenarios, not as a freight quote.
The result is a heuristic, not the optimum
Vehicle routing is NP-hard. Seed order, radius sweep and merge sequence all influence the answer. It is reproducible — a fixed seed always gives the same plan — but a different seed may give a slightly different one. Do not read small differences between two runs as meaningful.
A high LTL share is not the tool failing
During testing, an early version had no LTL option and reported −79% savings on light freight — consolidating was actively losing money. Light shipments genuinely belong on LTL. If you untick the LTL option you will reproduce that behaviour.
Data in and out
Files this tool reads and writes
Direction
File
Purpose
In
orders_YYYY-MM.csv
Order book. Required columns order_id, dest, weight_lb; cube_ft3, lat, lng optional. dest accepts a ZIP, a state code or a city name.
In
hub_config.csv
Hub set, exported by the Coverage or TCO simulator.
In
assumption_registry.csv
Rate and fuel surcharge from actuals, exported by the Budget simulator.
Out
freight_optimization_result.csv
Full load plan with sequence, miles, fill, out-of-route, cost per load.
Out
network_performance_for_S2.csv
Miles-per-pound improvement, consolidation ratio and fill, formatted as a budget target for the Budget simulator.
Where it sits in the loop
This is the planning stage. It receives a hub set from the Coverage and TCO simulators, and hands its structural improvement to the Budget simulator as next year’s target. Import the assumption registry before exporting the network result — otherwise the improvement is measured against an unconsolidated baseline rather than against current actuals, and the Budget simulator will refuse the file.