The team knew their rules were mis-allocating orders when they built them. They built them anyway, because the alternative did not scale.
Anonymized to protect customer confidentiality
National nutrition brand
Outcome
Average label cost
$10.07 → $8.69 (−13.7%)
Time to fulfil an order
5 min → 2 min (−60%)
Monthly saving, as reported
~$12,000
Also covers · Cartonization
A national nutrition brand shipping bars and drink mixes direct to consumer, on ShipStation, growing quickly enough that the fulfilment process was being revised roughly every time volume stepped up.
The operations team was small and the order profile was varied — small single-item orders alongside larger mixed cases, with meaningfully different optimal handling.
The team began by going order by order, confirming weights and dimensions and selecting the lowest-cost carrier by hand. It produced good decisions and it did not scale; as volume rose, the time available per order fell.
So they did what most operations at that stage do: replaced the manual review with a set of automation rules based on educated guesses about which carrier was usually cheapest for a given weight and size band.
What makes this review worth reading is that the team was explicit about the trade. They knew the rules would mis-allocate some proportion of orders and accepted a known amount of expense leakage as the price of getting orders out of the door. The choice was between shipping slowly and correctly or quickly and approximately, and neither option was good.
The rules engine did precisely what it is designed to do. Given a weight band and a size band, it applied the mapped service consistently and quickly, and it removed the per-order labour that was the immediate problem.
What it could not do is tell the team when a rule was wrong. A static rule encodes an assumption about which carrier wins for a class of orders. That assumption is correct for most of the class and incorrect at the edges, and it silently becomes more incorrect every time a carrier adjusts a rate card or a surcharge.
The leakage was therefore invisible by construction. Nothing in the system reports the gap between the service the rule selected and the service that would have won, because the losing options are never priced. The team knew the leak existed only because they had previously done the work by hand.
Replacing an estimate with a calculation meant moving the decision from the class of order to the individual order:
The interaction that matters is between package and carrier: dimensions determine cubic weight, cubic weight determines which services are competitive, and the competitive set changes whenever a rate card does. This is why the leakage compounds — the rules do not decay visibly, they decay quietly.
Average label cost fell from $10.07 to $8.69, a 13.7% reduction, and time to fulfil an order fell from five minutes to two. The team reported approximately $12,000 a month.
The operational point is that both moved together. The team had been treating speed and cost as a trade-off because, with the tools they had, it genuinely was one. Removing the manual comparison removed the trade.
The second-order effect is maintenance. The rules had been a standing obligation — something to revisit whenever rates moved, which in practice meant something nobody revisited. A calculation that re-derives against live rates does not accumulate that debt.
"As we scaled, we outgrew our manual process and implemented a set of automation rules based on educated guesses about which carrier would be cheapest according to variables like weight and dimensions. We knew this would result in mis-allocated orders and substantial expense 'leakage,' but the alternative was going order-by-order to compare rates, which we just didn't have the bandwidth to do anymore."
What another operator can take from this review, whether or not their operation looks anything like this one.
Rules built on educated guesses do not fail visibly. They produce a plausible label on every order, which is what makes the leakage hard to detect and easy to tolerate.
If you cannot see the options a rule rejected, you cannot know what the rule cost you. Absence of complaints is not evidence of correctness.
Any rule encoding a carrier assumption has a shelf life set by the carrier, not by you. Rate card changes silently invalidate it.
Speed and cost only trade against each other while a person is doing the comparison. That trade-off is a property of the process, not of fulfilment.
Other operational reviews
Cartonization
4 min
A packing process that depended on the judgement of whoever reviewed orders that day. The judgement was good. The dependency was the problem.
Rate Selection
3 min
A carrier relationship that solved a real reliability problem, then kept being applied to orders it was no longer the right answer for.
Exception Monitoring
4 min
Rules made fulfilment faster and, at the same time, removed the human check that used to notice when an order never actually shipped.
Start here
A short conversation, an export of your order data, and a String Operational Review you keep — along with an honest answer about whether String can meaningfully improve your fulfillment operation. If it can't, we'll tell you. That answer requires a detailed review by us and could save you a year of building the wrong solution.
