Operations
When the stock stops
agreeing with itself
Two channels disagree about what's on the shelf. Someone reconciles it by hand every morning, and you oversell anyway. It's rarely the storefront's fault.
Replatforming without fixing it moves the fault rather than clearing it, so the platform decision and the systems decision belong together.
Why stock desynchronises
Three causes, in the order to check them. The first is the cheapest to fix.
No source of truth
Two or more systems each believe they own the stock figure, and each will happily write to the other. Nothing's broken. There's just no answer to "which one is right", so the last writer wins and the figures drift apart by the hour.
Latency at the wrong moment
The sync works, but it isn't fast enough for the sales rate. A fifteen-minute cycle is invisible on a slow catalogue and catastrophic on a product doing thirty units an hour during a promotion.
Reservation logic
Stock comes off at the wrong point in the order lifecycle: at fulfilment rather than at checkout, or it's never released when a basket is abandoned. The count is arithmetically correct and operationally wrong.
What overselling costs
The refund is the smallest part of it, and often the only part anyone counts.
A single source of truth plus a buffer stops it. A faster sync doesn't: it narrows the window without closing it, because two channels can always sell the last unit inside any window. A held buffer on fast-moving lines accepts a little unsold stock in exchange for never making that call, and once the cancellation cost is counted properly, the trade pays.
Count all four
- The refund. The smallest of the four
- Marketplace metrics. Cancellation and defect rates that throttle visibility, or suspend the account outright
- Support time. Per incident, every incident
- The customer. Told the order was confirmed, then told it wasn't
When a second location makes things worse
A second warehouse usually opens to solve a space problem, and it brings an allocation problem, which is harder. Every order now needs a decision about where it ships from, every SKU can be in two places, and any line held in both locations can be sold twice unless the allocation logic is aware of both.
The fix here often isn't software. Holding fast-moving lines at one site only, and accepting slightly worse use of space, can remove the allocation problem entirely.
The tell
A split-shipment rate nobody chose.
If orders routinely go out in two parcels because the picking location was decided line by line rather than order by order, you're paying twice the carriage to work around your own inventory model. You can measure it from the despatch data you already hold, without buying anything.
WMS or 3PL — how to work out which is cheaper
No published figure answers this. 3PL pricing depends on the shape of your operation (order profile, unit sizes, storage footprint, seasonality), and in-house cost depends on premises you may already be paying for. Here's the method, and where the two models differ.
| In-house + WMS | 3PL | |
|---|---|---|
| What you pay for | Labour at peak, the fulfilment share of rent and rates, packaging, licence and implementation | A per-order and per-storage rate quoted against your real order profile |
| The line most under-counted | Implementation, and the management time that disappears into the warehouse | Surcharges outside the quoted profile — returns, oversize, peak |
| Who absorbs a peak | You do, in hours and in hiring | They do, at a rate agreed in advance |
| Where the risk sits | Operational, and yours to fix at 6am | Commercial — someone else's operation, still your customer |
| The wrong choice when | Volume is spiky and premises are already tight | The proposition depends on how the parcel arrives |
Build the in-house cost in full, using the first column. Implementation and management time are the two lines that get under-counted, and they're the two that decide it.
Then get 3PL quotes on your real order profile rather than an average. The per-order economics of a five-line order and a one-line order aren't close.
Compare at current volume and at twice current volume. The crossover usually sits between them, and what decides it is which model you want to be in when the business is bigger.
The one non-financial factor worth weighting sits in the last two rows: 3PL makes fulfilment someone else's operational problem and your commercial risk.
What Shopify Plus doesn't solve
Plus is a strong storefront and checkout, with real multi-location inventory and a solid API. It will hold stock levels across locations and expose them to channels properly, and for plenty of operations that's enough.
It isn't a warehouse management system. It won't tell a picker the efficient route, direct putaway, replenish a pick face or handle batch and expiry. It does now carry the purchasing record (purchase orders against supplier records, and receiving against a linked inventory transfer, in the admin since June 2026), but that's a stock ledger, not a warehouse: there are no bin locations behind it, so nothing tells anyone where the pallet went. It allocates only by the rules you give it.
And a picking bottleneck is often a process problem in a software costume: pick paths that follow the SKU list rather than the shelves, wave sizes set by habit, packing benches short of the packaging they need most. Fix those before buying a licence. They're free.
Diagnosis before purchase. A migration that fixes the storefront and leaves the warehouse untouched has moved the fault, not cleared it.
When the diagnosis does land on a purchase, the selection (which system gets to be right, and the four numbers every candidate has to show) is on what a stock control system has to get right. If you're already on Shopify, the narrower version is what Shopify already covers and the four reasons to add to it.
Tell us what you need
What the systems are doing now, and what you need them to do. We'll tell you whether it's a platform problem or something cheaper.