A Shopify-connected 3PL receives a client’s orders automatically the moment shoppers place them, builds those orders into picking waves, scan-verifies every pack against the order, and pushes tracking numbers back to the store — no CSV exports, no order emails, no re-keying. The same floor can serve pallet-in/pallet-out clients at the same time, and every step of the flow — returns included — writes a billable event against the client’s rate card.
How do orders get from the store to the floor?
The client’s Shopify store connects directly to the WMS: SKUs map to that client’s segregated inventory, and orders land in the queue as they’re placed. The alternative — daily CSVs or orders forwarded by email — fails exactly when it matters most: the flash-sale Friday when 900 orders drop before lunch and somebody is copy-pasting order numbers while the queue grows. A native connection means the promotion is a picking problem, not a data-entry problem.
What does wave picking change?
Walking, mostly. Industry studies put travel time at up to 50% of picking activity — half the labour of your most labour-intensive process is spent moving between bins. Wave picking batches orders so a picker crosses the floor once for many orders instead of once per order, with the pick path sequenced through the bin locations that were assigned back at putaway. This is also where GRN and putaway discipline pays its dividend: waves are only as good as the bin data underneath them.
Why scan-verify every pack?
Because the arithmetic of “pretty accurate” is brutal at volume: on 500,000 orders, 97% pick accuracy is 15,000 mispacks; 99.5% is 2,500. A barcode scan at the pack bench catches the wrong item while fixing it costs a re-pick — not a return, a reshipment, an apology and a dent in your client’s reviews. Scan-verification is also what makes the per-order and per-item pick & pack charges self-documenting: the same scan that verifies the item writes the billing event.
Can item-level clients share a floor with pallet clients?
They should — that’s the economics of third-party warehousing. A Shopify apparel seller tracked at item level, an FMCG client on pallets, an industrial client with batch-and-expiry stock: one floor, three owners, three rate cards, three sets of rules. This is the line between e-commerce-only fulfilment software, which models the item-level client and nothing else, and a 3PL WMS, which models the floor. Binsy runs item-level and pallet operations side by side, with client-level segregation underneath both — the comparison is drawn out in Binsy vs a standard WMS.
Why should returns be a billable VAS?
Because returns are work: receive the parcel, inspect the item, restock it to a bin or grade it out. US-published anchors put returns processing at $3–7 per unit — and because returns arrive outside the standard outbound flow, they are among the likeliest charges to go unbilled entirely. A returns-heavy apparel client processed free of charge is a leak you chose. Treat every return as a VAS event with a client and a rate, and the work pays for itself.
Order in, wave built, pack scanned, tracking back, return processed — five operations, five billing events, zero month-end reconstruction. That’s the whole thesis: the guide covers the full flow, and the calculator shows what the unbilled version costs.
From reading to the rack.
Bring one client's rate card and one month of invoices. We'll walk your flow through Binsy and show where the billing events would have written themselves.
Book a walkthrough