Packing software runs the station between picking and shipping. It pulls up the right order when a picker scans a cart or tote, forces a second scan of every item so the wrong unit cannot go in the box, applies your rules to pick a parcel, rate shops the connected carriers, and prints the shipping label and packing slip together. Tracking goes back to the sales channel automatically.
Most warehouses do not have a packing problem. They have a packing handoff problem. Picking is measured, shipping is measured, and the twenty seconds in between where somebody decides which box to use and whether the contents are correct is run on memory and paper. That gap is where mis-ships, oversized parcels, and unbilled dimensional weight come from.
This page covers what packing software does mechanically, the decisions it has to make on your behalf, and where it stops helping. It is written from what we see in warehouses running SkuNexus, so the SkuNexus sections are labeled as such.
Strip away the vendor language and every packing system is trying to answer four questions in sequence.
Software that only does one or two of these is not a pack station. Label printers do the fourth. Barcode apps do the second. A pack station needs all four wired to the same order record.
Here is the sequence as it runs in a wave-based operation, which is the setup most mid-market ecommerce warehouses land on once volume passes a few hundred orders a day.
A picker walks a cart with totes on it, filling twenty orders in one trip through the warehouse. At the bench, the packer scans the tote. The system already knows which fulfillment that tote holds because the pick step assigned it, so the screen loads the order, the line items, and the fulfillment ID. No paper changes hands. This is also why batch and wave pick and pack only works when packing is integrated: the tote is the link between the two steps.
Parcel selection runs on rules you write. A rule can key off item count, product attributes, order tags, shipping method, or dimensional weight. For example: if the item count is greater than one and the order does not carry a specific attribute, use a particular carrier and parcel size. When the rules match, the parcel is already selected when the screen loads. When nothing matches, the packer can choose a parcel manually or enter custom dimensions, and that exception is visible rather than silent.
The packer scans each item again as it goes into the box. The screen turns green on a match and refuses anything that does not belong to that fulfillment. This is the single highest-value step on the bench, because it is the last point where a wrong item costs cents instead of a return, a refund, and a replacement shipment.
With the parcel confirmed, the system requests live rates from your connected carriers and returns the options. You can leave the choice to the packer or automate it, for example always taking the cheapest service that still meets a ground, two-day, or next-day commitment. Only then does anything print: the shipping label peels off for the box, the packing slip goes inside. Printing at the end rather than the beginning is deliberate. Paper printed before the box is packed is paper that goes stale.
The label is the obvious output. The packing slip is the one that gets underestimated. It is the only document the customer physically handles, it carries your order number into any support conversation that follows, and several marketplaces have opinions about what belongs on it. Treat it as configurable output tied to the channel the order came from, not as a fixed template. Some operations also print carrier-required documentation, return instructions, or handling certifications at the same moment, which is only possible if all of it is generated from one order record at one point in the flow.
The tracking number posts back to the storefront or marketplace in real time and the order flips to fulfilled. Nobody keys a tracking number into a store admin. For a fuller view of how this sits inside the wider flow, see the pick, pack, and ship process and the shipping and receiving workflow guide.
Cartonization software gets sold as a packing algorithm. In practice, the algorithm is the easy part. The reason cartonization projects stall is that the dimension and weight data behind them is incomplete, so the engine has nothing to reason with.
Before evaluating any cartonization feature, check three things in your own catalog:
There is a second measurement problem that catches people: the dimensions that matter are the shipped dimensions, not the product dimensions. A shirt has catalog dimensions taken flat and shipped dimensions taken folded in a poly mailer. A kit has component dimensions and an assembled footprint. If your data captures one and your engine assumes the other, the parcel recommendations will be consistently wrong in the same direction, which is at least easy to spot.
If coverage is thin, attribute-based rules will outperform a dimension-based engine on day one. Rules like "any order with more than four units of this category goes in the large mailer" are crude, but they are correct more often than a bin-packing calculation run on missing data. Populate dimensions in parallel, then move the rules toward true cartonization as coverage improves. That sequencing matters more than which vendor has the better packing algorithm.
Single-warehouse, single-channel packing is close to a solved problem. The failures show up when the order is not simple.
One order, several fulfillments. When stock for one order sits in two warehouses, or part of it is a dropship, the order has to split into separate fulfillments that each get their own container, their own pack event, and their own label. The packer at bench three should never see the half of the order that is shipping from another building. Handling this cleanly is a property of the order management layer, not the packing screen.
Partial shipments. If three of five units are available, you may want the three to go out now. That means the pack station has to accept a fulfillment that is deliberately short, and the remainder has to stay tracked rather than disappear.
Channel-specific rules. Marketplace orders often arrive with packaging, insert, and label requirements that differ from your own storefront. Those need to be rules the packer sees on screen, not tribal knowledge.
Product-specific handling. Perishables need cold chain instructions calculated per order. Serialized and high-value goods need capture at the bench. Fragile items need a documented method. These are packing requirements even though no packing software markets them.
Worth saying plainly, because it saves evaluation time:
SkuNexus is an inventory, order, and warehouse platform for mid-market ecommerce operations that have outgrown off-the-shelf tools but cannot justify an enterprise WMS. The packing module is part of that platform rather than a separate product, which means the pack station reads from the same order and inventory records as everything upstream.
The difference customers point to is that the workflow is not fixed. Parcel rules, verification behavior, what prints, what gets captured at the bench, and how exceptions are routed are all configured to how the warehouse already works. We have built pack workflows around dry ice calculations for frozen goods, triple scanning and weight capture for precious metals, and prescription documentation for optical orders. None of those are separate products. They are the same pack station configured differently.
Related capabilities that touch packing: warehouse management for the pick side, barcode scanning for verification hardware, and purchase orders for vendor and dropship flows.
A family-owned craft ice cream producer in Cincinnati with over 50 locations and nationwide grocery distribution. As ecommerce grew, manual order processing and packing caused delays and errors, inventory visibility across multiple warehouses was limited, and dry ice packing decisions were made by hand. Shipping label requirements were complex and prone to mistakes.
SkuNexus integrated with their existing Magento storefront and automated order routing, packing, and shipping. Dry ice packing instructions became precise and system-generated. Custom shipping labels with all required certifications were automated. Inventory tracking went real time across all warehouses. The result was 100% order automation, fewer operational errors, and enough processing speed to handle over 550,000 pints annually, up from 270,000.
An ecommerce retailer of home health products running a zero-inventory dropshipping model. Inconsistent vendor and dropshipper communication caused delays, and manual processes hurt order accuracy. SkuNexus integrated directly with their BigCommerce platform for real-time data flow, automated purchase order generation for dropship orders, and centralized vendor communication. Order accuracy and customer satisfaction improved. Carewell has since secured $30MM in venture capital funding and ranked #74 on Inc.'s 2021 5000 Fastest-Growing Private Companies in America.
Canada's largest eyewear retailer, with over 477 locations. Manual fulfillment created bottlenecks and complex data exchange between Magento 2 and other systems added delays. SkuNexus automated their pick, pack, and ship processes, integrated with Magento 2 and Canada Post, and delivered training and documentation for staff. Online sales and fulfillment accuracy both improved, and the implementation was completed in nine months.
Use this before you shortlist software. Most of it is warehouse work, not vendor work, and doing it first makes any packing system land better.
| Area | What to have in place |
|---|---|
| Bench setup |
|
| Data |
|
| Rules |
|
| Measurement |
|
A packing rollout is short compared to an inventory or order management rollout, and it is best run as its own phase.
By requiring a scan of each unit at the bench, after picking. The system holds the fulfillment on screen and only accepts barcodes belonging to that fulfillment. A wrong scan is rejected on the spot. This second scan is separate from the pick scan and is the reason a verified pack station reduces mis-ships even when the pick step was already scanned.
Cartonization chooses the parcel for an order by fitting item dimensions against the cartons you stock. It needs length, width, height, and weight on the products involved, plus a defined box library. Without reliable dimension data it will produce confident, wrong answers, which is why attribute-based parcel rules are the better starting point for most catalogs.
Yes, and it should. Both documents are generated at the moment the box is confirmed packed, from the same order record, so the slip inside the box and the label on the outside cannot disagree. Packing slips are typically customizable with your logo, order number, and any fields your channels require.
The order splits into separate fulfillments, one per shipping location, plus a separate fulfillment for anything going out as a dropship. Each fulfillment gets picked, packed, labeled, and tracked independently, and all of them stay linked to the original order so the customer and the channel see one coherent picture.
It has to. The pack station needs order data coming in and shipment data going out, and both usually cross a system boundary. The integration questions that matter are which system owns inventory at the moment of packing, how tracking numbers get back to the channel, and what happens to the queue if the connection drops mid-shift.
The fastest way to evaluate a pack station is to watch it handle your hardest order, not a clean demo order. Bring a multi-warehouse split, an oversized item, or whatever your team dreads. Schedule a demo and we will run it.
Yitzchak Lieblich, known as Yitz, is the founder and CEO of SkuNexus. He has spent his career building inventory, order, and warehouse systems for ecommerce operations, and personally runs the technical discovery calls where these workflows get mapped. The pack station sequence described on this page is the one he walks through with prospective customers.