Optimizing the network, not just the lane: Why per-vehicle cost is the wrong KPI

When asking fleet operation teams how they measure success, most point to metrics that look at cost per vehicle, cost per route, or cost per drop on a particular lane. These metrics make intuitive sense, are easy to track and display on a dashboard, and most importantly will look good on a per-vehicle or per-lane basis. A route could be operating at low cost per drop, vehicles could be maxed out at 100% utilization, and a hub could be clearing all daily inventory, all of which are metrics that look good on a per-vehicle or per-lane basis. But does operating a network of locally excellent numbers translate into a well-run network as a whole? The answer is no.

This is one of the major blind spots in freight and logistics optimization. Each of the metrics looks good on its own, so they endure as the way that a network is operated. The real cost, however, is revealed when one looks at the entire network rather than one lane at a time.

Local optimization looks like progress but isn't always

In supply chain analysis, it’s a well-established paradigm to distinguish between local and global optimization. In terms of measuring per-vehicle KPIs, this leads to rather misguided decisions, as local optimization is restricted to improving a single function, such as a single lane, a single hub, or a single vehicle. In order to determine potential disruptions or risks in other parts of the network, global optimization considers the entire supply chain before any changes are made. Local optimization is not without value. It is often the best way to test a single idea quickly. However, using it as the main operating model for an entire freight network leads to rather negative consequences.

One of the classic examples of this type of trade-off is the transportation function that attempts to create volume to get discounted freight rates by filling a truck. On the surface, this appears to be a good example of local optimization for improved efficiency. But in reality, the inventory created at destinations by this type of freight strategy can end up having a higher carrying cost than the savings gained on the freight. Therefore, in an effort to optimize one function, the rest of the network incurs higher costs. If the dispatcher or route planner is measured on a per-vehicle basis or a per-lane basis, then they will optimize to the metrics that they are measured against. Unfortunately, without visibility and accountability for the rest of the network, they can have negative impacts on other parts of the chain.

Where this actually shows up: Hub and capacity imbalance

Another word for this type of failure in freight networks is capacity imbalance. In general, this means that while some facilities are running at capacity overload, others have excess capacity well below efficient utilization. The root cause is that resources have not been allocated at the network level. As a result, costs of such distribution network failures (underperforming lanes or unavailability of transport capacity where it is needed most) accumulate in rather predictable ways. Interactions between the various allocation decisions made at individual facilities (e.g., dark stores, regional fulfillment centers, and distribution hubs) create consequences that cannot be detected from within any individual facility or single lane.

What this looks like in reality is a multi-lane optimization problem, found in dark stores, regional fulfillment centers, or a multitude of distribution hubs serving the same geographic market. The way a route planner today optimizes for one lane at a time doesn’t give him or her any reason to care that Hub A is running near full capacity every afternoon, while Hub B, a mere 20 km away, is running half the practical throughput of A. The local metrics of each individual hub look fine—cost per drop is acceptable, and % utilization is not a trigger point for a crisis, yet the overall network is hiding idle capacity in one part of town while creating risk of a bottleneck in another. And, as noted, this is a condition that cannot be revealed by a view that is only per-vehicle or per-lane, because such a view was never designed to look at more than one lane at a time.

Why per-vehicle cost actively rewards the wrong behavior

The deeper issue isn't just that per-vehicle KPIs miss network-level problems; it's that they actively create incentives that make those problems worse. A route planner evaluated on cost per vehicle for their assigned lanes has every reason to keep routing through the hub and the vendor relationships that already produce a good number for them, even when a different allocation, sending some volume through the underutilized hub, and rebalancing which vehicles serve which lane would lower total network cost. Nobody is measuring total network cost at the level where that decision gets made, so the locally rational choice keeps winning, lane after lane, even as the aggregate picture drifts further out of balance.

This is the same trap that shows up in route optimization when the objective function targets the wrong variable, which is a metric that's easy to calculate and satisfying to minimize but a poor proxy for what actually matters. Cost per vehicle is calculable, intuitive, and locally controllable, which is exactly why it became the default. It's also blind to everything happening one hub over, which is exactly why a network can look efficient on every individual scorecard while running meaningfully below its actual potential in aggregate.

What network-level optimization actually requires

Fixing this doesn't mean abandoning per-vehicle metrics entirely; they're still useful for spotting an individual route or vehicle that's genuinely underperforming. It means adding a layer above them that evaluates allocation decisions against total network cost and balance, not just the local number a given planner or dispatcher is accountable for. That requires a live, shared view of capacity and demand across every hub and lane simultaneously and a planning engine that can shift volume, vehicles, and routing across that shared view rather than optimizing one lane in isolation from the rest.

This is the specific design principle behind Libera's capacity and route planning engine: reducing cost per drop by evaluating capacity and routing together across the network, rather than lane by lane, which is what allows the system to notice and correct for the exact imbalance that a per-vehicle KPI structurally cannot see. The same logic extends across the full journey through Libera's approach to all-mile logistics, where first, mid, and last mile are coordinated as one connected plan specifically so that a bottleneck forming at one stage of the journey gets addressed using capacity available elsewhere in the network, rather than each stage optimizing independently and discovering the mismatch only after it's already caused a delay.

A network, two ways

Picture two regional hubs serving overlapping delivery zones, each running its own dispatch and reporting its own per-vehicle cost.

Lane-by-lane optimization: Hub A's planner sees strong numbers of daily, vehicles well utilized, a cost per drop within target, and nothing flagged as a problem. Hub B, twenty kilometers away, is running the same reporting cadence with numbers that look adequate but unremarkable. Neither planner has visibility into the other hub's load, because neither system was built to compare them. Over several months, Hub A quietly drifts toward chronic overcapacity, with routes running later and occasional missed windows during demand spikes, while Hub B's spare capacity sits unused every single day. Every individual report looked fine. The network was never actually balanced.

Network-level optimization: The same two hubs are evaluated as one shared capacity pool. When Hub A's afternoon volume consistently pushes past efficient throughput, the system reallocates a portion of that demand to Hub B automatically, based on live capacity data from both facilities rather than a planner's manual judgment call made without visibility into the other hub. Hub A's per-vehicle numbers might look marginally less "optimal" in isolation where a few routes are drawing from Hub B's fleet instead of running purely local assignments, but the total network cost drops because idle capacity at Hub B is finally being used instead of sitting unmeasured and unnoticed.

Same two hubs, same underlying freight. The only difference is whether the system measuring performance could see both of them at once.

What to ask when evaluating a TMS on this point

If you're evaluating transportation management system software for a network with more than one hub, lane cluster, or fulfillment center, the question worth asking isn't "Can it report cost per vehicle?" Every platform can do that. The better question is whether the system can see capacity and demand across every hub simultaneously and reallocate across that shared view, or whether "optimization" in the platform actually means optimizing each lane independently and hoping the sum of good local numbers adds up to a well-run network. Those are very different capabilities wearing the same label, and the difference only shows up once your network has more than one hub for imbalance to hide between.

This distinction tends to matter most exactly when it's hardest to notice, during steady, unremarkable operating periods rather than obvious crises. A capacity mismatch that costs a few percentage points of network efficiency every week doesn't trigger an alarm the way a missed SLA does; it just quietly compounds, showing up eventually as a facility that "needs expansion" when the real problem was that demand was never being routed to the capacity that already existed twenty kilometers away. Supply chain automation aimed only at the lane level will never catch this, because it was never built to look past the lane in the first place, which is precisely why network-level visibility, not another local efficiency gain, is the upgrade most multi-hub freight operations actually need next.