A global re-commerce marketplace running around 25,000 labels a day did something I wish more buyers would do. They decided to do a deep dive into their shipping, right down to the package level. I think we could all agree that most organizations are leaking money somewhere. This team wanted to know where, specifically, so they ran their own data through Luma AI to find out.
The AI tool came back with specific places to look. Routes they were overpaying on. Service levels running faster than the delivery promise they had actually made the customer, and trigger conditions nobody had revisited since the rules were written.
The recommendations all looked good on paper. But rather than just change everything and hope, they applied the changes to a portion of their daily shipping and ran it alongside shipments sent in the original manner. Well, things we well. They were saving money and shipments were arriving on time at higher rates. When they saw that what happened in the real world matched what the data said would happen, they moved 10x more volume over.
By the end they were saving over $2 million a year, and roughly 273,000 packages a year that used to arrive late were arriving on time. Without adding a carrier. Crazy, right?
Nobody went and got a better network
Most shipping cost projects follow the same script. You add a carrier or two, or you go back to the table on a contract. Somebody inherits the work on top of their real job, and two quarters later you’ve got a spreadsheet, a new integration to maintain, and a win you have to defend in a review because it came in smaller than the business case said it would.
But this operation skipped all of that. They added no carriers. No contracts went back to the table. And nobody got hired to run it, which is usually the tell that a savings project is really a headcount request in a costume.
I read that twice, because it’s the kind of claim I would push back on if somebody else brought it to me. But their carrier network on the last day was the same network they had on the first, so whatever produced these results, it came out of the assignments and not the roster.
Cheaper and faster at the same time
Both of those numbers moved in the same direction.
Cost and delivery performance usually get treated as a tradeoff. Pay less, wait longer. That’s how most shipping decisions get framed, and it’s how most routing rules get written.
When both improve, the setup they started with was never a tuned compromise between cost and speed. It had room on both axes at once and nobody could see it, and I doubt this team is unusual in that. If you’re the person who wrote those rules, that probably lands a little differently for you than it does for the rest of us.
I’ve raised enough teenagers to know that nobody throws a party for the kid who came home on time. You only have complaints about the ones that arrive home late. And noisy. Time and time again. Packages are the same. The 273,000 that stopped arriving late don’t generate a tracking check or a support ticket or an angry reply, so they never land on anybody’s dashboard and nobody builds a business case out of them.
I don’t have a clean number for how many tickets those 273,000 prevented, and I’d be suspicious of anyone who did. But anyone who has staffed a support queue through December knows the direction.
And the $2 million? That came entirely out of reallocation, without anybody negotiating a thing.
A rule written in March still describes March
Now, most teams I talk to have already done the multi-carrier work. They’ve got the integrations, the accounts, the rate sheets. What they don’t have is a current answer to which carrier and which service should get the next label, so they fall back on rules.
And rules are where this leaks. A routing rule is a snapshot of what was true on the day somebody wrote it, so it described that week accurately and then the week ended. Carrier performance moves by lane, by service level, and by week, and those variables move independently of one another.
I see this one constantly. A carrier came in cheapest on a lane during contract season, so it became the default for that lane. Nine months later its transit times there have slipped by a day, its cheapest-on-paper status is now inside a couple of cents of the alternative, and neither of those facts has reached the routing logic, because nothing in the system is set up to surface them. The carrier isn’t underperforming its contract. It’s underperforming the reason you chose it, and those are different problems with the same invoice.
I don’t think anybody’s being careless here. The rule was right when it was written, and there was never a moment where it announced that it had stopped being right. When did you last go back and check one of yours?
The half that looks and the half that acts
Luma AI Insights is the half that looks. It reads what your carriers are actually doing, lane by lane and service by service, against a base of more than a billion historic shipments across 100+ carriers, which is wide enough to tell a pattern from one facility having a bad week. That’s what surfaced the slack for the marketplace.
Luma AI Select is the half that acts, once the decisions are made. It applies the assignments at label generation under rules your team writes and owns, and it keeps checking them against what the carriers are doing now instead of what they were doing the week the rule went in.
Neither half removes the thinking. The first one makes the thinking possible, and the second one keeps you from having to do it by hand on every label.
Where this doesn’t apply
Below a certain size, I don’t think there’s much here for you. If you’re running a few hundred labels a day across a handful of lanes on one or two carriers, there’s very little to reallocate, and you’d spot a problem like that without any help. This starts paying somewhere north of a few thousand labels a week across enough lanes that a single bad origin and destination pair can matter and still hide inside your total.
Your starting point matters too. Their on-time rate had room in it, so if yours is already high, the same work returns less, and you should size the business case off your own baseline instead of somebody else’s improvement.
And the savings here came without touching rates. If your base rates are genuinely bad, better assignments will help you at the margin and you’ll still have a rates problem.
The other thing this took was somebody’s sustained attention. Luma produced the list, but people still had to work through it and decide what to do, so if nobody on your team has that time to give, better visibility will sit in a dashboard and change nothing.
The evaluation is what I’d copy
They didn’t run a bake-off on paper or decide off a projected savings model. They put live volume through it, at a size where the numbers would mean something but a bad outcome wouldn’t hurt much, and they let it run long enough to produce a trend instead of a good week. Then they scaled, and the size of the move was proportional to the confidence the data had earned.
That’s a reasonable way to evaluate anything that claims it will change your shipping costs, including ours. If a vendor can’t survive a measured slice of your live volume, the pitch was all there ever was.
See what Luma AI Insights finds in your own shipping data. Then pick the slice of your volume you’d be willing to test it against.
