share
06:10, a Load Planner's Desk
Meera is a load planner at a central distribution centre. The optimiser ran at 05:30 against yesterday's released stock transfer orders. Twenty-three shipments, six loads, one run, ninety-four seconds. By the time she sits down with her first coffee, the plan is waiting for her.
Five of the six loads look fine. LD-5001 does not. The control tower has thrown an orange flag against it: load utilisation 51%, below the yellow threshold. The truck is a 32-foot container running 412 km from the North Zone DC to the Export Region, with two intermediate stops.
She opens the 3D view. It is a good picture. Ten items, four shipments, colour-coded, neatly stacked, every carton labelled with its item ID, the whole thing rotatable, exportable as JSON. The optimiser has done exactly what it was asked to do. It has packed the shipments it was given, and it has packed them well.
And roughly three metres of the trailer, from the last pallet to the rear doors, is air.
Meera knows what should go in that space. DC-42 at the destination is running thin on two fast-moving SKUs and will raise a replenishment order next week anyway. There is a pallet pool of spares sitting in bay 7 that has been waiting nine days for a truck going that way. She has done this before, on a whiteboard, with a tape measure and a phone call to the dock supervisor.
What she does not have is forty minutes. Carrier tendering closes at 07:00, and there are five other loads to review. So she clicks publish at 51%, the indent goes out, and the truck leaves at 08:00 carrying half a load of goods and half a trailer of nothing.
The diesel burns the same either way.
What is Actually Going Wrong
The problem is not that the optimiser is bad at packing. Bin-packing is a solved-enough problem, and most modern TMS platforms do it competently. The problem is narrower and more stubborn than that.
- The optimiser can only see what was released to it. Load building takes stock transfer orders as a fixed input and treats the truck as the variable. It answers one question: given these shipments, what is the best way to fit them into a vehicle? That is a packing question. The question the business actually needs answered is a different one: given this truck, this route and this departure time, what is the best thing to put in it? Nobody is asking the optimiser that, so it never answers it.
- The 3D output is a record, not a recommendation. Look closely at what a load planner gets today. A rotating container, a set of coloured boxes, and underneath it a placements file with x, y, z, l, w, h for every item. It is precise. It is auditable. It is also inert. It tells you how the truck was packed. It does not tell you how the truck should have been packed, and it has nothing at all to say about the space it left empty.
- Utilisation thresholds report, they do not act. Most systems let you configure green at 90%, yellow at 70%, red below. Those bands colour dashboards and raise alerts. They do not feed back into the plan. The system is, in effect, very good at telling a planner she has a problem and completely silent on what to do about it.
- So filling the gap stays a human, undocumented activity. It happens on the dock, in a WhatsApp group, in the memory of whoever has been doing the job longest. Sometimes it happens well. Often it does not happen at all, because the planner has six loads to clear and forty minutes to do it. And because it is undocumented, the saving is unrepeatable, invisible in the P&L, and lost the day that planner changes jobs.
The cost of this shows up in three places. Freight cost per unit shipped, because a fixed trip rate is being divided by half a truck. Carbon per unit shipped, for exactly the same reason. And a second trip later, to move the stock that could have travelled in the space that went out empty.
The Fix: Change the Question the System is Asked
The instinct is to reach for a better packing algorithm. That is the wrong place to look. Bin-packing is not where the value is hiding.
The shift is in the question. Today the system is asked: given these shipments, how do they fit? It needs to be asked: given this truck, this route and this departure, what is the best thing to put in it, and what is that worth? Everything else follows from that change.
Three things must be true before the answer is trustworthy.
Eligibility must be a governed decision, not a dock decision. Deciding which item may travel ahead of its demand is a planning judgement with real consequences at the far end. It belongs in master data, owned by planning, with the policy that goes around it. How far ahead may this item move. To which destinations. Against what shelf life, what value exposure, what ownership transfer. Get this wrong and filler is just a license to create dead stock four hundred kilometers away, which is why most planners are right to be skeptical of the idea until they see the guardrails.
The recommendation must survive the dock. A simulation that ignores unloading order, axle distribution, stackability or reachability is a slide, not a plan. The moment a crew has to break the sequence to get at a stop-1 pallet, the credibility is gone and the feature is never used again. Most of the engineering effort sits here, not in the geometry.
The planner must stay in charge. The system proposes; it does not edit. The baseline STO plan remains intact and auditable. A scenario is a proposal carrying its own trade-off, and publishing it is a deliberate act with a name and a timestamp against it. Planners adopt tools that expand their judgement and quietly abandon tools that overrule it.
Do those three things and the picture stops being a record of what happened and becomes an argument about what should happen. That is the whole change.
What That Looks Like
Figure A — the plan as it is published today. The optimiser has packed the four shipments correctly. Volume utilisation 51%, weight utilisation 50%, and a clear run of empty trailer behind the last item.
Figure B — the same load with filler simulated. Same vehicle, same stops, same departure. Eleven filler units have been placed into the residual envelope: replenishment pallets for DC-42 in the tail, fast-moving spares in the headroom above the low crates. Dashed edges mark them as simulated, not yet committed.
Figure C — the trade, stated in numbers.
Two things in that table deserve a planner's skepticism, so state them plainly. The truck's own emissions go up, not down, because it is carrying three more tones. And the follow-on trip is only genuinely avoided if the filler stock was going to move within its policy horizon anyway. Both are honest, and both survive the arithmetic: emissions per cubic meter shipped still fall by around 40%, and the avoided trip is real whenever the filler policy is set correctly.
At Smartlinks, this is the kind of problem we take on
Filler simulation is one example of a pattern we see across supply chain operations. The hard problems are rarely the ones with clean textbook answers. They are the ones where the data exists, the constraint is understood, the planner already knows roughly what the right answer is, and no system in the landscape will let them act on it inside the time they have.
That is the work. Not adding another screen but closing the distance between what an experienced planner knows and what the system will let them do.
It shapes how we build Trukr TMS. We start from the planner's morning, not the feature list. We measure ourselves on decisions made per hour, not clicks saved. We put the trade-off in front of the person making the call rather than burying it in a report they will read next quarter. And we treat domain judgement as something to be encoded and scaled, not replaced, because the planner who knows that DC-42 is running thin is an asset, and the only real failure is that she had no way to act on it before 07:00.
Meera's truck leaves at 08:00 either way. The question is only whether the system helped her decide what was in it.
