Ask a merchant how big their best-selling product is once it's packed for shipping, and most can't answer with any confidence. Not because they don't know the product — because nobody has ever measured the packed version of it. A jacket folded into a satchel isn't the same shape as a jacket on a hanger. A pair of boots doesn't ship in an envelope no matter what the product photo suggests. That gap between "what the product is" and "what the parcel actually is" is where a large share of shipping cost surprises start, and it's rarely the merchant's fault — it's a data problem nobody built the tooling to solve.

This matters more than it looks like it should, because packed dimensions are the input every downstream shipping decision depends on: whether an order should route to parcel or freight, whether cubic weight makes a light item expensive to ship, and whether the number shown at checkout bears any resemblance to what the shipment will actually cost.

The estimation problem, tiered

Product AI is built to solve this in tiers, cheapest and most certain method first, rather than jumping straight to guesswork:

Tier	Method	What it does
0	SKU match	Looks up a global dimension library; confidence increases as more merchants confirm the same SKU
1	Category	Uses median (p50) dimensions for a known category — apparel vs hard goods vs bulky
2	LLM	Reads title, description, vendor, and variant (AU size 10, 1L, 32-inch waist) to estimate packed shipping size
Confirm	Merchant	Confirmed dimensions become ground truth and feed the shared library

Low-confidence estimates go into a review queue rather than being trusted blindly; high-confidence ones auto-fill at booking and at checkout. The model is deliberately trained on the packing problem, not the product-photo problem — the goal isn't to describe what the product looks like, it's to estimate what box or satchel it will actually leave the warehouse in.

Once an order has actually been packed, the platform remembers the specific product combination — which SKUs, which box, which weight — so the next order with the same mix auto-fills instead of being re-estimated from scratch, with partial matches flagged for the merchant to override rather than silently assumed. The loop compounds: estimate, ship, confirm, and the next store benefits from what this one just measured. That's also where the agentic onboarding process matters — it's what kicks the catalogue crawl off on day one instead of waiting for the first few dozen manual bookings to build up any data at all.

Why this is worth solving instead of shrugging off

Bad dimensions are not a rounding error. They compound into two very different, very expensive failure modes on either side of the same problem.

Underestimate a package and the checkout quote looks great — until the real invoice includes a reweigh or a cubic recalculation the merchant never priced in. Overestimate it, or default to a generic large box "to be safe," and the checkout quote looks worse than it needs to, at exactly the moment shipping cost is doing the most damage to conversion. Baymard Institute's checkout research — based on large-scale usability testing — found that unexpected extra costs including shipping are the single most common reason shoppers abandon a checkout, cited by 39% of people who abandon, ahead of every other reason tracked, including having to create an account (Baymard Institute). A shipping quote is either accurate or it's contributing to that number — there's no safe direction to be wrong in.

The freight side of the same problem is covered in detail in our volumetric weight guide: once a shipment crosses into freight territory, carriers bill on cubic (volumetric) weight, not actual weight, using a published conversion factor — commonly 250kg per cubic metre for express freight in Australia (One World Courier, cubic weight explainer). A merchant who has never measured a bulky-but-light product has no way to know it's about to be billed as if it weighed 200kg.

And residential delivery — covered in our dedicated guide — is its own accessorial fee that depends on address type, not dimensions, but it's applied at the same booking step, which is exactly why getting the dimension and address signals right together, upfront, matters more than solving either one in isolation.

What "good" looks like

A merchant with accurate packed dimensions on file sees three concrete things change: checkout quotes shrink toward what the shipment actually costs (rather than a padded default box), freight-eligible SKUs get flagged before they're accidentally booked through a parcel network that was never going to accept them, and booking an order takes less manual correction because the platform already has a confirmed or high-confidence estimate on file. None of that requires the merchant to personally measure a warehouse full of stock — it requires a system willing to do the tiered estimation work and get smarter every time a real order ships.

For how estimation, review, and confirmation work in the app, see the Product AI feature guide. Chargeable kg from those packed sizes is in Cubic Weight and Chargeable Freight. The catalogue crawl that fills estimates on day one is part of Agentic Onboarding. Account-wide packaging defaults are in the Packaging Optimisation help doc.