From Half-Empty Trailer to Full Load: How SKUBIQ-TMS Loads Every Cubic Foot
Somewhere in your operation a truck is being loaded. You can see from the ramp how much of the trailer is actually used. Most days the answer is less than you would like, and more than the planner intended.
Here is the part that makes it strange. The same operation is also overloading trucks. India's own freight report, published by NITI Aayog, records both in the same table: empty running at "28 to 43 percent", and load factors that are "typically above 100 percent". A truck can leave your site with a pallet crushed against the door and still return three days later with nothing on it.
That is not a contradiction, and it is not a driver problem. It is the signature of freight that is never matched to a vehicle at the right moment. This guide covers what trailer utilisation actually measures, the four constraints every real load has to obey, why a plan that fills 96 percent of a trailer can still be a bad plan, and what SKUBIQ-TMS and SKUBIQ-WMS each do about it.
The same truck is empty one way and overloaded the other
India moves most of its freight on roads that were built for cars, not for freight vehicles. NITI Aayog's freight report puts road at "Around 71 percent of India’s freight", with rail at "only 17.5 percent".
The consequence is a fleet whose assets are used badly in both directions. The same report says "trucks in India travel about 300 km per day compared to the global average of 500 to 800 km per day", and that "The truck sizes are smaller, they are often overloaded beyond their capacity" with "empty running rates as high as 40 percent".
The truck sizes are smaller, they are often overloaded beyond their capacity, and have empty running rates as high as 40 percent. - NITI Aayog, Fast Tracking: National Freight Planning for India
Read the comparison table on page 61 of that report again and the shape of the problem appears. Daily utilisation of 250 to 400 km against 700 to 800 km in the USA and Europe. Empty running of 28 to 43 percent against 13 to 29 percent in the USA and 15 to 30 percent in Europe. And load factors above 100 percent, because "Trucks in India are usually overloaded". For comparison, "Average load factors in Europe are in the 50 to 80 percent range".
Empty running is the half-empty leg. Overloading is the full leg carrying more than the axle should. Both are decided long before the truck reaches the ramp: one in the dispatch plan, the other in the loading plan.
It matters at national scale because "Logistics costs in India are high, accounting for 14 percent of the GDP", with transportation and inventory costs making up more than 90 percent of that. Utilisation is not a warehouse hobby. It is where that number comes from.
What trailer utilisation actually measures
Utilisation is one word for at least four different numbers, and a report that gives you only one of them can be made to say almost anything.
Transportial, which sells load planning software, reports it four ways: "Every trip reports utilisation in square metres, cubic metres, kilograms and load meters". The load meter is the European standard measure, and Transportial derives it automatically - "Every goods line gets load meters (length × width ÷ 2.4) and CBM computed from its dimensions" - so a capacity check still works when the customer only sends sizes.
| Measure | What it catches | What it misses |
|---|---|---|
| Square metres of floor | Freight spread thin across the deck | Empty air above the cartons |
| Cubic metres | Unused volume in the trailer body | A pallet standing proud of the roof line |
| Kilograms | Overloading, which is what an axle limit cares about | How that weight is distributed |
| Load meters | A standardised length measure that compares containers and trailers in one number | Whether the load can actually be unloaded |
A trailer can look full by floor area and be half empty by cube. A trailer can sit at 96 percent of its cube and be illegal on the third axle. Measure all four, or measure the one your customer asks for and know exactly which one you are reporting.
Why one number is never enough
NITI Aayog's own definition of the underlying measure is worth borrowing word for word, because it is precise. Load factor is "The average share of vehicle loading capacity that is productively used". Note what that definition does not say. It does not say how full the trailer looks, or how many cartons are on it, or how fast the team worked. It says how much of the capacity you paid for turned into productively used capacity.
That is the number to put in front of finance, and it is the number most operations have never computed.
A load plan is not a packing list
Cargo-Planner's guide to what a load plan is makes the distinction cleanly: "A load plan is a document that says which cargo goes into which vehicle, where each item sits, and in what order it is loaded."
It also warns about the paperwork confusion that produces bad loads: "Three documents get called load plans and are not, and confusing them is a common way to arrive at the ramp with the wrong answer."
The first of those three is the packing list, and the guide is blunt about what it is: "A packing list is an inventory. It says what is being shipped and how much it weighs." What it does not say is where anything sits, which means it cannot answer the only question that matters at the ramp.
The other two halves of a real load plan are the equipment and the rules. The equipment has to be the real thing - "not their nominal names" - because a nominal length is not an internal length, and the gap between the two is where most first-attempt plans go wrong. The rules cover what may sit on what, what may not travel with what, and what has to come off first.
Three questions a load plan has to answer
- What goes where? A position for every item, a count of vehicles, and something the loading floor can act on.
- What may not go together? The segregation rules that never appear in a naive calculation and always appear in a real load.
- What comes off first? The unload order that the driver and the customer will actually follow.
The four constraints every real load has to obey
Cube is the obvious constraint and the one most teams measure. But the load builder that ignores the other three produces plans that cannot be executed, and an unexecutable plan has a utilisation figure of zero.
| Constraint | What it limits | What breaks when it is ignored |
|---|---|---|
| Cube and floor area | How much freight fits in the body | Empty space above the load, paid for at line-haul rate |
| Weight and axle position | Where the mass sits, not just how much there is | Overloaded axles, fines, and goods damaged by pressure |
| Stacking and support | What can sit on what, and how much on top | Collapsed loads and rejected pallets at the customer |
| Unload sequence | The order freight comes off the vehicle | Goods re-handled at the kerb and late deliveries |
Weight and axle position. Cargo-Planner puts it plainly: "Axle limits apply per axle group, so where the weight sits matters as much as how much there is". Timefold's solver treats the same thing as a hard constraint, listing "axle group limits, the Federal Bridge Formula, center of gravity height" alongside gross weight and stop-order access, and then optimising inside those rules so that "the fewest trailers, then keeps axles below a safety margin".
Stacking and support. Transportial checks "support under every unit, maximum load on top", and every goods line carries its own orientation and stackable weight. A carton that cannot carry a tonne on top of it changes the entire shape of the plan, not just one line.
Unload sequence. For a multi-drop load the plan has to come off in the order it is delivered. Transportial handles it by "keeps goods for later drops deeper so nothing blocks an earlier unload". Cargo-Planner sequences the load the same way - "last on, first off" - so nothing gets unloaded at the kerb to reach what is behind it.
What may not travel together. Dangerous goods separation, temperature zones, fragile lines, customer-specific restrictions. These are not optimisable. They are a veto, and a load planner that treats them as preferences will eventually put two things on the same pallet that should never share one.
Why a fuller trailer can be a worse trailer
A plan that fills a trailer to 96% and cannot be unloaded at the first stop is worse than one at 88% that can. - Cargo-Planner
That single sentence separates a load plan from a packing exercise, and it is worth sitting with. Cargo-Planner states the underlying principle plainly: software that arranges cargo "is usually sold on utilisation, and utilisation on its own is a poor goal".
The reason is that the last 8 percent of a trailer is usually the 8 percent that forces the load to be re-planned at the first stop. The plan has to "leave the office in a form the floor can act on - a loading sequence rather than a final picture, since the person loading needs to know what goes in first".
That is also why cost has to be inside the calculation rather than bolted on afterwards: "A cost function adds a cost per loaded container, so the plan can be pushed toward the cheapest freight bill rather than the fullest vehicle." Two vehicles of different types at different rates will not produce the same answer, and a planner that only counts space will always pick the fuller one.
enVista's transport optimisation team put the operational version of the same point: "If a load cannot be built and loaded as planned, the savings in that plan never materialise." Their conclusion is about where the money is: "The biggest transportation gains are captured before the truck ever leaves the warehouse, when better-built loads turn transportation plans into realised savings."
That is the argument for building the load plan at the dock, not in a planning meeting three days earlier.
Empty running: the leg that earns nothing
The other half of the problem is the leg with nothing on it. NITI Aayog is plain about the cost: "High empty running increase VKTs, which in turn increases CO2 and criteria pollutant emissions. It also increases fuel costs for operators."
Intugine, which sells empty-mile reduction tooling into the Indian market, puts the rate at "30-40% of truck km in India are empty running" and attributes it to three structural reasons rather than one bad week.
- Asymmetric trade lanes. Goods flow from manufacturing hubs such as Gujarat, Pune, Chennai and the NCR outward to consumption points across the country. The reverse flow is far weaker, so trucks that deliver to tier-2 cities often return with nothing.
- Hub-and-spoke mismatches. Trucks from distant depots service regional routes and then have no local return freight to pick up. The hub model creates systematic one-way trip patterns.
- Last-mile dead ends. Trucks servicing final-mile delivery to industrial estates, SEZs or rural warehouses often have no onward freight at the destination. The return leg is structurally empty.
Notice what this list does not contain: nothing about drivers being careless, and nothing about roads being bad. These are planning failures, and they are precisely the failures a dispatch system that can see the whole network is positioned to fix.
It also connects to capacity the industry does not use. NITI Aayog notes that "around 28% of the current truck fleet is sitting idle due to the dearth of drivers". Empty running is not an idle fleet problem. The trucks are busy. They are simply driving with nothing on them, burning the diesel that the driver's shortage makes impossible to waste.
Load matching is the fix the report names
When NITI Aayog lists what India should do to fix truck use, the first action is not a road and not a vehicle. It is "Improve load matching using digital platforms and get freight on the right type of truck, depending on the use case". The second is "Maximise vehicle productivity through efficient packaging and loading".
Both of those are software problems before they are fleet problems.
C.H. Robinson's Navisphere describes what a TMS does when it is doing this job well: its planning engine can choose "the optimal route, mode and carrier for each delivery-maximising trailer utilisation and minimising empty miles", with "consolidation opportunities and automated freight tendering" handled inside the platform.
Shipwell frames the same capability from the shipper's side and lists the constraints its consolidation has to respect: "Trailer capacity", driver hours-of-service rules, delivery windows and "Location hours of operation".
And Timefold, which builds the optimisation solver layer, reduces the objective to two clauses: the model "uses the fewest trailers, then keeps axles below a safety margin", so that "less empty cube goes on the road".
What the warehouse has to hand the planner
None of this works if the order data arrives late, incomplete or in the wrong shape. This is where the warehouse system earns its place in the argument.
For a load to be built you need, per order line: the quantity, the dimensions, the weight, the gross weight and the stackable weight. Transportial lists exactly that set - quantity, length, width, height, weight, gross weight and stackable weight per goods line - and notes that load meters and cubic metres "follow automatically" once those are captured.
In SKUBIQ-WMS those attributes live on the order and the item, and the outbound process produces the pallets that the transport system then has to fit. The two systems are talking about the same cartons: the warehouse knows how many pallets a route produced and what sits on them, and the transport system knows which vehicle and which drop order they have to fit into.
When the two are connected, load matching can happen before the truck is booked rather than after it has left. That is the difference enVista describes when it says optimisation "evaluates demand patterns, shipment timing, network constraints, and transportation costs together with trailer cube utilisation, loading constraints, and warehouse execution".
For a 3PL running several clients out of one building, the same idea applies one level up. The SaaS WMS for India is built for multi-client operations, and the client split is itself a constraint on how a trailer can be built: two clients' freight can rarely share a pallet, but it can very often share a trailer.
The paper side of a load
A load is also a set of documents, and a load that is right on the ramp can still be wrong on paper.
In SKUBIQ-TMS the same plan is closed out on both ends. Freight booking covers "Order intake, rate validation, tendering, allocation and carrier confirmation workflows with a full audit trail". The carrier network module handles "Carrier onboarding, scorecards, capacity commitments, rate agreements and contract rate management in one place". Proof of delivery closes the consignment with "Geo-stamped ePOD, photo capture, e-signature, exceptions and returns workflows".
And dispatch and load planning is where the utilisation number comes from in the first place: "Load consolidation, trailer utilisation, multi-depot allocation and cross-dock sequencing built for high-throughput networks".
All of it hangs off the same plan. The load plan says what goes where, the proof of delivery says what actually happened, and billing and settlement then reconciles on "Trip-based invoicing, per-km and GRM reconciliation, fuel and accessorial claim handling with dispute workflows".
Which is the point of the whole exercise. A utilisation number that nobody bills against is a report, not a control.
What to measure every week
A weekly set, small enough that people actually fill it in, and specific enough that two sites cannot report different things under the same name.
| Metric | What it is | Where it comes from |
|---|---|---|
| Floor utilisation | Share of usable deck length occupied | Load plan against trailer dimensions |
| Cube utilisation | Share of usable body volume occupied | Load plan against trailer dimensions |
| Weight utilisation | Gross weight against legal gross and per-axle limits | Load plan against the vehicle's own limits |
| Load factor | "The average share of vehicle loading capacity that is productively used" | Every trip, aggregated |
| Empty running by lane | Share of kilometres run without load, per lane | Trip and telematics data |
| Cost per loaded cubic metre | Freight cost divided by productive cube delivered | Billing and settlement against the load plan |
If you report only one of these, report floor utilisation - but know what you are not seeing. And measure empty running per lane, not as a fleet average. Intugine's three structural reasons - asymmetric lanes, hub mismatches, last-mile dead ends - are all lane-shaped, so a fleet average hides exactly the problem you need to see.
The last row is the one that makes the rest worth collecting. Utilisation only becomes money when it reaches an invoice.
A 60-day plan to get trailer utilisation under control
The order matters. Measuring cube before the load is built tells you what you already know. The sequence below starts from the vehicle, because that is where the constraint bites.
| Phase | Days | What happens | What you get |
|---|---|---|---|
| 1 - The trailer | 1-15 | List every vehicle type you actually run, with real internal dimensions and real axle limits. Not the brochure numbers. | A vehicle library the plan can be measured against |
| 2 - The data | 16-30 | Capture quantity, dimensions, gross weight and stackable weight on every order line. Fill in what is missing rather than carrying the gap forward. | Lines a planner can actually place |
| 3 - The build | 31-45 | Build the load against the vehicle, then check the sequence for the delivery order. | A plan the dock can execute |
| 4 - The match | 46-60 | Consolidate across lanes and clients, then compare the resulting cost per loaded cubic metre against the baseline. | A number you can take to finance |
Start with the trailer, not the algorithm
It is tempting to buy a load optimiser first. Buy the data first. A planner that receives a dimension but no stackable weight will produce a plan that looks dense and cannot be built, which is a worse outcome than having no plan at all, because the team will trust the number on the report.
Support matters at this point too, because the first month of any load-planning rollout is a month of questions about specific lines. Training is provided at the implementation stage and the support team is on call Monday to Friday, 09:30 to 18:30 IST. When the answer to "what did the planner do with this pallet" comes out of someone's inbox, none of that helps.
The questions to ask before you buy
- Does it report utilisation in all four measures - floor, cube, weight and load meters - or only the one that flatters the plan?
- Can it take the loadlist from the warehouse system and hand back a finished plan the dock can act on?
- Does it enforce axle limits and stacking rules as hard constraints, or does it produce a layout the ramp has to fix?
- Does it sequence the load for the delivery order, or does it leave the driver to work out what comes off first?
- Does it cost each vehicle option, so the plan can be pushed toward the cheapest freight bill rather than the fullest vehicle?
- Can it match freight across lanes and clients, or only fill the trailer you already booked?
The SKUBIQ FAQs page covers the commercial basics, and the WMS pricing page sets out what a warehouse platform costs on its own. The SKUBIQ support page is where the implementation questions get answered before a contract is signed.
What to take away
Trailer utilisation is not a packing exercise. It is the difference between a truck you paid for once and a truck you paid for twice, and India's own freight report shows the country losing money on both halves of that equation at the same time: trucks that run empty on the way back, and trailers that are overloaded on the way out.
Fix it in the order the constraints arrive. Measure in all four units, not one. Treat cube, axle position, stacking and unload sequence as hard limits rather than preferences. Produce a loading sequence rather than a picture. And price the vehicles so the plan can be pushed toward the cheapest freight bill instead of the fullest trailer.
That last point is where a transport system earns its place. SKUBIQ-LMS already holds the shift, task and attendance record that decides who is on the floor; SKUBIQ-WMS holds the order data and produces the pallets; and SKUBIQ-TMS holds the vehicle, the load plan, the carrier and the invoice. If you want to see the three of them working on the same lane, talk to us through the SKUBIQ contact page and ask for a session with the product specialist who covers your operation.
