IceBossPro Blog — Packaged Ice Delivery

Blocks, Cubes, and Bags: SKUs in Packaged Ice Software

Most packaged ice operations do not sell just one thing. A single route can carry bagged cube ice in a couple of weights, dense block ice for coolers and ice sculptures, and specialty cube packs for events — and each product moves differently, prices differently, and stores differently. Handling that variety cleanly is a core job of packaged ice delivery software. This post covers how blocks, cubes, and bags each become their own SKU, and why keeping them distinct keeps par-levels, restock quantities, and billing accurate across a mixed product line.

Three products, three behaviors

Bagged cube ice is the everyday mover — fast turnover, tight par-levels, high visit frequency. Block ice is a slower, heavier product bought by campers, caterers, and cooler users who want it to last; it melts differently and often sells in smaller numbers. Cube packs and specialty presentations spike around events and holidays and can sit quiet in between. Because these behaviors diverge, lumping them together would wreck every downstream calculation. Modeling each as its own SKU lets the software treat a fast 7lb bag line and a slow block line with the different logic each one needs.

Distinct SKU setup for each form

In the catalog, a block, a cube pack, and a bag each get their own record with their own price, barcode, weight, and IPIA label details. That separation is what makes the rest of the system work: a scan-to-restock at the freezer resolves a block barcode to the block SKU and a bag barcode to the bag SKU, and each drops onto the invoice as its own priced line. It also means you can retire, reprice, or reconfigure one product — say, change block pricing for the summer — without touching the others.

Par-levels across mixed products

Par-levels only make sense per SKU, and a mixed product line proves why. A c-store freezer might carry a high par of 7lb cube bags, a low par of block ice, and no cube packs at all until an event is coming. Packaged ice delivery software stores a separate par for each product in each merchandiser, so the driver's suggested restock quantity is calculated independently for blocks, cubes, and bags. The block par can sit at four while the bag par sits at forty, and neither number distorts the other.

Restock quantities that respect the product

Because pars are per SKU, so is the restock math. At the stop the app compares on-hand to par for each product and suggests a drop for each — top the fast bag line back to forty, add a couple of blocks to bring that line to par, skip the cube packs entirely. The driver adjusts as needed, and the actual quantities are logged by SKU. This is what prevents the classic mixed-line mistake of over-dropping a slow block that then melts, or shorting the bag line because the numbers were blended into one total.

Billing a mixed load

When products carry different prices, clean SKUs are what keep invoicing correct. A delivery that includes bags, a block, and a cube pack produces an invoice with three priced lines, each pulled from its SKU price, totaled automatically. Per-bag pricing, per-delivery charges, and consignment all coexist — you might bill bags per-unit and blocks per-unit on the same invoice, or run one product on consignment while another is charged on delivery. The billing follows the products because the products are structured, not guessed.

Inventory, load planning, and shrink by form

A mixed line also complicates the truck, and SKUs untangle it. The software tracks blocks, cubes, and bags separately through load, delivery, and return, so you can plan a load that carries enough of each without hauling a pallet of blocks that will not sell. Shrink and melt surface per product too, which matters because a block and a bag lose weight at very different rates. Seeing the loss by form tells you whether it is the slow-moving block that is bleeding margin or the fast bag line that is being over-ordered.

Adding specialty SKUs for events

Event and holiday demand often calls for products you do not carry year-round — larger cube packs, party bags, or extra block for a festival. Because the catalog is modular, you add these as new SKUs with their own pricing and pars, push them to the accounts that need them, and pull them back when the season passes. The same par-level, scan-to-restock, and per-bag billing machinery picks them up automatically, so scaling a product line up for a busy weekend is a catalog change, not a system rebuild.

For a related look at the number that drives every restock, see Setting Bag Par-Levels in Packaged Ice Software