Should Your TMS or OMS Embed Packing Optimization?

This one is for product managers and architects at TMS, OMS and WMS vendors rather than for shippers. If you sell logistics software, packing optimization eventually appears on your roadmap — usually as a line item called "cartonization" or "load planning" that someone added after losing a deal.

We build a packing API, so our bias is obvious. What follows is still the most useful version of the argument we can write, including the parts where the answer is "not yet" or "not from us".

The Signals That Say You Need It

Very few customers walk in asking for a packing algorithm. They ask for things that quietly require one. In rough order of how strongly they predict that this is now a real gap:

1. Your freight quotes are consistently wrong in one direction. Most platforms estimate shipments by summing item volume and adding a fudge factor. That is not how boxes work, and the error is always optimistic — a set of items with a total volume of 0.6 m³ does not fit in a 0.6 m³ box. If your customers routinely re-quote after the warehouse packs the order, this is why.
2. Customers are exporting to spreadsheets. When a planner pulls data out of your product to work out pallet counts by hand, you have located a missing feature precisely. It is also the point at which a competitor's demo starts to look good.
3. Dimensional weight is eating your customers' margin. Parcel carriers bill on max(actual weight, volume ÷ DIM divisor). If your platform picks the box, your platform is setting their invoice. Getting that wrong is expensive and highly visible.
4. "Cartonization" is appearing in RFPs. Not as a nice-to-have. Enterprise WMS evaluations have scored this for years, and TMS and OMS RFPs increasingly do too.
5. Customers are asking for packaging reporting. Under EU PPWR, empty space becomes a documented, regulated number. Whoever chooses the box is the natural place to measure it, and that is your platform.

One of these is a feature request. Three or more at once is a gap in your product that is costing you deals you never hear the reason for.

Why This Is Harder Than It Demos

Here is the trap, and it catches good engineering teams.

3D bin packing is NP-hard. But a naive version is genuinely easy: sort items by volume descending, place each one in the first position where it fits, done. A competent developer builds that in a week and it produces plausible-looking output on the demo dataset. The feature gets marked shipped.

Then reality arrives, and it arrives as a queue of individually reasonable requests:

• "These items must not be stacked more than two high."
• "Everything for one customer has to go on the same pallet."
• "This SKU can only travel upright."
• "We have four pallet types — which combination is cheapest?"
• "Can we see a diagram? The warehouse won't follow a list of coordinates."
• "It takes eleven seconds. Our pack station has two."
• "These items are cylinders."

Each one is a week that turns into a month. Meanwhile the packing quality gap between your greedy heuristic and a tuned solver is somewhere between 5% and 20% of bin count — invisible to you, directly visible in your customer's freight bill, and the exact number a competitor will benchmark against you in a bake-off.

The honest framing is not "can we build this". You can. It is: is a packing solver something your team wants to still be maintaining in three years? Because that is the commitment. It is a research-flavoured problem with an infinite constraint backlog, and it will never be the thing your customers renew for.

Build, Buy, or Wait

The last row is worth dwelling on. Most packing engines model everything as a rectangular box, so cylindrical goods get wrapped in a bounding box and 21.5% of every item becomes phantom volume. If a segment of your customer base ships round things, that is a differentiator you can offer and most of your competitors cannot.

If You Buy: What Actually Takes the Time

The API call is an afternoon. These are the parts that are not.

Per-tenant packaging catalogues

Every customer has their own boxes, pallets and containers, and they change. You need somewhere for a tenant to maintain that list, and a sane default for the ones who never will. This is usually the single largest chunk of the integration and it is entirely on your side of the line.

Constraint modelling

Stacking limits, orientation locks, consolidation groups and weight caps have to come from somewhere in your data model. If your product has no concept of "these two order lines must ship together", adding packing means adding that concept first. Scope this before you scope the integration.

Where the call happens

Server-side, always — never from the browser, so credentials stay yours and results are cacheable. Pack once at order confirmation and store the plan; do not recompute on every page load. For overnight batches, run asynchronously and cache by a hash of the item set, because the same order shapes recur constantly.

Visualisation

This is the part product teams under-weight and users care about most. A pallet count is a number someone has to trust. A diagram is something they can check in two seconds and then act on. Adoption of packing features tracks visualisation more closely than it tracks packing quality, which is mildly depressing and completely consistent across every deployment we have seen. Make sure whatever you buy returns item coordinates, not just totals.

Multi-tenant credentials and cost

Decide early whether you resell under one account or provision per tenant. One account is far simpler operationally and lets you mark up; per-tenant gives your customers their own usage visibility and billing relationship. Both are normal. Get the commercial model agreed with your vendor before you build against it, because retrofitting is painful.

Questions Worth Asking Any Vendor

1. Do you return item coordinates, or only bin counts and utilisation?
2. Can a single request mix bin types and sizes, and choose between them?
3. What is the p95 latency for a hundred-item request?
4. How are stacking, orientation and consolidation constraints expressed?
5. Do you support non-cuboid geometry — cylinders, and cylindrical containers?
6. Is there an embedding or reseller agreement, and what does the pricing look like at our volume?
7. What happens when items do not fit? Partial plans, or an error?
8. Can we run a benchmark against our own historical orders before signing anything?

That last question is the one that matters. Any vendor confident in their solver will let you test it on real data. We will.

Frequently Asked Questions

What is cartonization?

Cartonization is deciding which carton, tote or pallet each order should go into, and how the items are arranged inside it, before the order reaches the pack bench. It is the same underlying problem as 3D bin packing; "cartonization" is the term WMS and OMS vendors tend to use, and it is what appears in RFPs.

Can we white-label a packing optimization API?

Yes. The API is called server-side, so nothing about it is visible to your end users unless you choose to surface it. Most platform integrations run under a single reseller account with the platform handling its own tenant billing. Talk to us before you build if that is the model you want.

How long does integrating a packing API take?

The call itself, an afternoon. A production feature with per-tenant packaging catalogues, constraint mapping and a visualisation is realistically four to eight weeks of product work, most of it in your own data model rather than against the API. That is still an order of magnitude less than building a solver.

What about performance at scale?

Cache aggressively and pack asynchronously where you can. Order shapes repeat far more than teams expect, so a cache keyed on the sorted item set gets a high hit rate in practice. For interactive use, pack at order confirmation and store the result rather than recomputing on render.

Can we try it before committing?

Yes, and you should — on your own historical orders, not on a sample dataset. If you want to skip the integration entirely for an initial benchmark, our MCP server will run batches from a conversation without you writing any code.

Send us a message.

Name

Email

Subject

Message

Close Send message