Introduction

A customer orders a bathroom renovation from a DIY store: 30 cartons of floor tiles, 5 bags of tile adhesive, four two-meter drain pipes, and a handful of fittings. Two questions decide what this order costs to deliver: where does it ship from, and how do you split its items across the shipping options at hand?

Answering both is the job of order routing. In fulfillmenttools, Advanced Order Routing makes that decision, at the heart of our order management system. Inside it, the 3D Packing Cost Optimizer prices shipping costs to the cent, on your own carrier rates, before the routing decision is made. It is deterministic optimization, so the same order under the same rules always produces the same packages. Routing looks simple from the outside, much like a navigation app picking a route (pick a warehouse, ship the order), and indeed, finding some way to deliver the order is easy. Finding a good one is a genuinely hard combinatorial problem though, and we have to solve it in a very short time, while the customer is still in checkout. But it is worth the effort, because every improvement shows up directly as lower logistics costs or better service quality for our customers.

Suppose the whole order ships from one warehouse, here is the packing our optimizer finds for the bathroom order.

A pallet, a bulky goods shipment and a parcel, each filled close to its limit. None of that is obvious from the order itself, so let's retrace how we got there:

‍

Where can the ordered items come from?

The ordered items are rarely all in one place. The tiles and the adhesive might sit in one warehouse, the pipes in another, the fittings in a store that ships directly to customers. Each location could ship its part straight to the customer, or first send it to another facility so that it travels on together with the rest. Every combination of these moves is a possible answer, and there are far too many to list them one by one. Instead, our order routing maps all possible moves as one fulfillment network: the facilities and the customer are its locations, and every possible move between them is a transfer. Every way to deliver the order is now a set of transfers that brings every item to the customer, and finding a good sourcing option turns into a search through that network. A sourcing option costs what its transfers cost together, so to pick the best one, the router needs a price for every transfer. Cost does not have to be the only goal: routing can also weigh trade-offs, such as delivery time against cost.

‍

Every transfer needs a price

A transfer's price depends on which carriers can service the transfer, which package options they offer, and how the items can be packed into those packages. For the bathroom order, that means: which packages do we select, and how do we distribute the items among them?

Pricing a single transfer is an optimization problem in its own right, nested inside the routing search. The outer loop searches over sources, carriers and transfers for the cheapest way to reach the customer. For every transfer it considers, the inner loop packs the items and hands back a price.

Every price in the network comes from a real packing.

That nesting is why speed matters so much: the inner loop runs thousands of times per routing decision, so every millisecond it saves counts thousands of times. Running both loops in one process is what makes this possible: packings that have already been solved get reused across candidate sourcing options, and pruning skips branches of the search that can't beat the best sourcing option found so far.

‍

What fits where, and under which rules

The first question in pricing a transfer is physical: what fits into which package? That is the job of our single-bin 3D solver. Given one package type and a set of items, it decides whether the items fit and exactly where. It places items axis-aligned, tries every orientation, and returns exact coordinates for every item. The bin packer calls it for every candidate package, which makes it the hottest loop of the whole routing search, and it is optimized accordingly.

The pallet below carries the tiles and the adhesive: together they weigh 545 kg, and with parcels capped at 31.5 kg they would need 20 of them.

But fitting can be about more than volume and orientation. At 200 cm, the drain pipes are too long for the pallet and parcel. The cheapest option that takes them is a bulky goods shipment, and that one has a limit of its own: its girth limit caps how bulky a single package can be, measured as the longest side plus twice the sum of the two other sides. Bundled side by side, with the towel rail lying on top, the four pipes measure 200 × 50 × 19 cm, a girth of 338 cm against a limit of 360 cm.

Carriers add further rules. Some items are hazardous goods and can only travel with certain carriers or package types, or cannot share a package with other items at all. Packages can also cap their weight or how many items they take, with a minimum or a maximum count, and some package types accept only certain article categories.

fulfillmenttools makes all of these settings configurable per customer, per carrier, and per transfer, instead of hard-coding one packing policy. The same solver respects very different constraint sets from one deployment to the next.

‍

Choosing the cheapest combination

One level above sits the bin packer (in operations research, a package is called a bin). It asks the 3D solver questions like "do these 30 tile cartons, 5 bags of adhesive and the mirror cabinet fit on one pallet?" and from the answers decides which combination of packages covers the whole order at the lowest total cost. That is a set cover problem, and we solve it optimally over all candidate packages for most orders. Only for very large orders do we fall back to a fast solver that finds good, but not guaranteed optimal, results. In logistics, this step is often called cartonization.

For the bathroom order, the bin packer finds more than 10,000 packages to choose from. These are the bins that no other bin beats across the board: each one is better than every other bin in at least one respect, be it content, cost or fewer restrictions.

The greedy pick button shows why this needs a real solver. Always taking the bin with the lowest price per new item looks sensible at every step, yet on these fifteen bins it ends at €164.03, 52 % above the optimum of €108.21. The optimal cover is not built from the locally cheapest bins, and with 10,344 candidates instead of fifteen, an exact search is what finds it.

‍

When fewer packages cost more

Finding the cheapest cover is only half the difficulty, because the prices of the bins we choose from are not smooth either: they move in steps. A pallet is priced in weight steps of 100 kg, and the pallet of the bathroom order carries 559 kg in the 600 kg step. Three more tile cartons would push it into the 700 kg step and add €8.71. A packing rule that only looks at volume or total weight cannot see steps like these.

An optimal solver follows these steps wherever they lead, and the results can be counterintuitive. To see this effect, take items out of the bathroom order in the example below and you would expect fewer packages and a lower price. Instead, the number of packages first drops and then comes back, because the cheapest packing is decided by the pallet's weight tier, not by the item count. Remove items from the order below and watch what the optimal packing does.

That looks backwards until you look at the pallet. With 26 tile cartons it holds 25 of them, the adhesive and the mirror cabinet at 489 kg, just under the 500 kg tier. The 26th carton would tip it into the 600 kg tier and cost €8.12 more, so it ships in a parcel for €4.78, together with the silicone and the toilet seat. That is what optimal use of cost tiers looks like: the objective is the price, not the number of packages. Minimizing packages or volume would never produce this solution. Pricing the tiers does: every pallet stays just below a limit, and whatever does not fit under it goes by the cheapest other package, even if that means opening another package.

‍

Why it matters

This is what we call pack-first routing: with the 3D Packing Cost Optimizer, Advanced Order Routing works out the packing first and lets its shipping costs inform the routing decision. Routing on real packing instead of estimates pays off in three ways:

• Lower shipping spend: carrier rates are driven by package count, weight steps and dimensions. Routing grounded in real packing instead of volume guesses removes packages and avoids tipping a pallet into the next price step, and the savings compound across every order.
• Better split-shipment decisions: shipping part of an order from a warehouse and part from a store is only as good as the cost model. Accurate per-transfer packing avoids sourcing options that look cheap on paper but explode into extra packages at the packing station. See how Kanmo Group made ship-from-store a cost lever across more than 300 stores.
• Fewer surprises on the floor: when the plan says one pallet, one bulky goods shipment and one parcel, the packing station gets exactly that, with a matching placement layout. Predictable material usage and less manual re-packing.

Every order raises the same two questions: where it ships from, and how its items split across the shipping options at hand. With the 3D Packing Cost Optimizer, fulfillmenttools answers both together, with real packing behind every price, found while the customer is still in checkout.

‍

[cg_inject-el="card"]

‍