Ecommerce Warehouse Management System: Setup Guide

What an ecommerce warehouse management system actually replaces

An ecommerce warehouse management system replaces the combination of a spreadsheet, a clipboard and Shopify’s own stock count field with a system built around the one thing none of those track: where the item physically sits. Shopify tells you a SKU has 340 units. It does not tell you that 200 of them are in bin A-01-03-B and 140 are still on a pallet in receiving that nobody has put away. A WMS closes that gap by attaching every unit to a bin location the moment it is scanned in, and by making every pick, pack, count and receipt a scan against that location instead of a number someone typed from memory.

For a brand running its own warehouse — not a 3PL, not a garage with a shelving unit — this matters at a specific point: when the person picking orders can no longer hold the layout in their head. That is usually somewhere past a few thousand SKU-locations or a few hundred orders a day, and it is almost always the point where “we’ll just recount it” stops being a five-minute job and starts being a half-day one.

This guide covers implementation for a brand that already operates its own facility, or is about to: receiving design, bin locations, cycle count settings, the Shopify connection, the parallel run, and the cutover — the order that keeps a go-live from turning into a stock-accuracy fire. If your warehouse is run by a third party, the questions are different; see warehouse management system for 3PL for what the system looks like from inside a fulfilment provider’s four walls, and warehouse pick and pack software for the floor-level tools a picker actually touches once the WMS is running.

Who should read this, and who should not

This guide is written for a Shopify or Shopify Plus brand doing $3M–$30M in revenue, running its own warehouse or about to open one, with enough order volume that a spreadsheet-based count has already caused a stockout or a double-sold item in the last quarter. Below that floor, the honest answer is usually a 3PL, not a WMS — implementing bin locations and cycle counts for a few hundred SKUs in a single small room is overhead a 3PL absorbs at scale for less than the labour cost of running it yourself. If that is your situation, 3PL fulfillment covers the decision from the other side.

Above that floor and running your own facility, a WMS is not optional once order volume outpaces what one experienced picker can hold in memory. The rest of this guide assumes that decision is already made.

Step 1: Map your receiving workflow before you evaluate a single WMS

Every WMS implementation that goes badly starts the same way: a team demos three vendors, picks the one with the nicest dashboard, and only discovers during setup that its receiving workflow does not match how pallets actually arrive at their dock. Do the mapping first.

Write down, for a single representative purchase order:

• Who opens the dock door and who signs for the delivery.
• Where the pallet sits between arrival and the first scan — this “receiving dock” stage is where WMS implementations lose the most accuracy, because it is the one step still done on paper at most brands even after go-live.
• Who breaks the pallet down to cases, and who breaks cases down to units.
• Where the count is first entered into any system, and whether that count is checked against the purchase order or just typed in.
• Who decides the bin location for a new SKU versus a restock of an existing one.

This exercise produces the requirement list a vendor demo should be scored against, not the other way round. A WMS that handles case-pick receiving elegantly but has no clean workflow for split-case receiving of apparel with size and colour variants will cost you more in workarounds than it saves in sticker price.

Step 2: Design the bin location scheme

The bin location code is the single piece of infrastructure every other step depends on, and it is the one most teams improvise instead of designing. A workable scheme has four segments, in a fixed order, printed on the shelf and scanned every time:

Zone – Aisle – Bay – Shelf-and-bin. For example, A-01-03-B reads as zone A, aisle 01, bay 03, shelf-bin B. Keep every segment a fixed width — two digits for aisle, one letter for shelf-bin — so the codes sort correctly and a scanner never has to guess where one segment ends and the next begins.

Three decisions to make explicitly, before a single bin gets labelled:

• One SKU, one primary bin, for fast movers. A-tier SKUs (see Step 3) get a fixed home location a picker learns by repetition. Reassigning a fast mover’s bin every restock is the single most common cause of pick errors in a new WMS.
• Overflow locations are named, not implied. If a SKU outgrows its primary bin, the overflow location gets its own code — never “wherever fits” — and the WMS is told both locations exist for that SKU.
• Reserve a zone for returns and holds, separate from sellable stock, so a returned item cannot be picked for a new order before it has been inspected. This is the zone most brands forget to plan and then bolt on after their first mis-shipped return.

Print the bin labels as barcodes, not just text. A picker reading a shelf label and typing it in defeats the entire point of scan-driven putaway — it reintroduces the same manual-entry error rate the WMS was bought to remove.

Step 3: Set cycle count tiers and count frequency

A cycle count is a scheduled recount of a subset of bins, done continuously, instead of shutting the warehouse for a full physical count once a year. The setting that makes this work is an ABC classification by sales velocity:

• A-tier — your top-selling SKUs by units shipped, typically the smallest share of your catalogue driving the largest share of order lines. Count these monthly.
• B-tier — moderate movers. Count these quarterly.
• C-tier — slow movers and long-tail SKUs. Count these twice a year.

The exact percentage split of A, B and C SKUs varies by catalogue — a brand with twelve hero products counts more of its catalogue at the A-tier frequency than a brand with eight hundred SKUs and a long tail. Set the classification from your own sales report, not a rule of thumb, and reclassify at least twice a year as new products launch and old ones taper off.

Two settings inside the WMS matter as much as the tier itself:

• Blind counts. The counter does not see the system’s expected quantity before entering their count. A count screen that shows “system says 340, confirm?” trains staff to confirm the system number instead of counting the shelf, which defeats the purpose of counting at all.
• Variance threshold for auto-approval. A count that differs from the system by more than a percentage threshold you set per tier routes to a supervisor for recount before it adjusts the ledger. A count within threshold posts automatically. Without this setting, every trivial rounding difference either needs manual sign-off or silently corrupts the count, depending on which way your team gets it wrong.

Step 4: Connect the WMS to Shopify and set the sync direction

Cutover is the step where “warehouse management system ecommerce” implementations either start paying for themselves or start causing oversells, and the difference is almost always the sync direction, not the integration itself.

The WMS is the source of truth for on-hand quantity once it is live. Shopify’s own inventory field becomes a mirror, updated by the WMS, not edited directly. The moment a staff member adjusts a count inside Shopify admin instead of inside the WMS, the two systems drift, and neither the picker nor the storefront knows which number is correct.

Three settings to confirm with your WMS vendor or integrator, by name, before go-live:

• Sync interval. Real-time (via webhook) for fast movers is worth insisting on; a 15- or 30-minute batch sync is common for the rest of the catalogue and is fine for anything that does not sell out within that window.
• Safety buffer per SKU. A small reserved quantity — commonly a handful of units — held back from what Shopify shows as available, so a sync delay on a fast-selling SKU does not create an oversell in the gap between a sale and the count updating. Set this per SKU, not globally; a slow mover does not need a buffer that ties up sellable stock.
• Multi-location mapping. If you run more than one warehouse or a warehouse plus a retail location, each Shopify location ID has to map to exactly one WMS location. A SKU present in two physical warehouses but mapped to a single Shopify location is the most common cause of “it says in stock but the warehouse that has it isn’t the one fulfilling the order.”

Shopify Plus and Shopify’s standard plans expose the same Inventory API for this purpose; the WMS integration itself is usually built and maintained by the WMS vendor or a middleware layer, not hand-rolled against Shopify’s GraphQL endpoints. Confirm which of the three settings above your specific vendor exposes before signing — some mid-market WMS platforms only support a single global sync interval, which is a real limitation if your catalogue has a wide range of sell-through speed.

The step most teams get wrong: cutting over before the data is clean

Every WMS vendor’s onboarding guide describes receiving, bin mapping and counts. Almost none of them say this plainly enough: the Shopify sync should not go live until the SKU master and the bin map are both clean, and “clean” has a specific, checkable meaning.

A SKU master is clean when every SKU in Shopify has exactly one matching SKU in the WMS, with identical capitalisation, no trailing variant suffixes on one side and not the other, and no SKU that exists in one system but not the other. A bin map is clean when every unit currently in the warehouse has been scanned into a bin — not counted on paper and entered later, scanned at the shelf.

The failure mode when a team skips this and cuts over anyway looks the same every time: the WMS goes live with a clean-looking dashboard, because the opening balances came from the same spreadsheet that was already slightly wrong. Within a week, pick discrepancies start appearing on SKUs nobody expected, because the WMS is now confidently wrong instead of admittedly uncertain. Orders that were open at cutover — picked in the old system, shipped after go-live — are the single most common source of this, because they get counted twice or not at all depending on which system’s clock the warehouse trusts that morning.

The fix is not a setting; it is a sequencing rule: reconcile the SKU master and complete a full physical count of every bin before turning on the Shopify sync, and hold any order that was open at the exact cutover moment in a separate queue until it is manually confirmed shipped or not. That queue is usually small — a few dozen orders, not a few hundred — and clearing it by hand once is far cheaper than chasing phantom discrepancies for a month afterward.

Step 5: Run a parallel pick before cutover

Before the legacy process is retired, pick and pack one full day of real orders in both systems side by side — the old spreadsheet-and-clipboard process running exactly as it always has, and the new WMS running the same orders in parallel without touching live inventory. Reconcile every mismatch: a bin location scanned wrong, a variant mapped to the wrong SKU, a count that came out different between the two processes.

A parallel pick is the cheapest place in the whole implementation to catch a configuration mistake, because nothing is live yet. A parallel run that surfaces zero mismatches on the first attempt is itself a signal worth distrusting — it usually means the team is comparing against the same source data on both sides rather than genuinely testing independent counts.

Step 6: Cut over and freeze the legacy count

Set a fixed cutover time — a specific hour, not “end of week” — and stop all writes to the legacy spreadsheet or system at that moment. Take a final snapshot of the legacy count for audit purposes, then make the WMS the only place inventory is adjusted from that point forward, including manual adjustments for damage, shrinkage and returns.

Any staff member who still has edit access to the old system after cutover is a live risk: a well-meaning correction typed into the spreadsheet a week after go-live, out of habit, is exactly how a “clean” cutover quietly stops being clean. Revoke write access, not just remove the shortcut from the desktop.

How to verify it worked

A go-live is not verified by the dashboard looking correct on day one — it is verified over the following cycle count. Three checks, in order:

1. Run the first scheduled cycle count on the A-tier bins within the first two weeks, not on the normal monthly schedule. A fresh implementation should be checked sooner than its steady-state cadence, and any variance above your normal threshold in this first count is a configuration issue, not shrinkage.
2. Audit the safety-buffer SKUs for oversells in the two weeks after cutover. An oversell in this window almost always traces to a sync interval or buffer setting that was left at a default rather than set for that SKU’s sell-through speed.
3. Confirm every order held in the cutover queue (Step 4) resolved to a single shipment record, not zero and not two. A SKU that shows as shipped twice for one order is the clearest sign an open order crossed the cutover without being caught.

If all three checks come back clean, the WMS is doing the job it was bought for: a bin location for every unit, a count that matches the shelf, and a Shopify storefront that never sells what the warehouse does not actually have.

Warehouse inventory accuracy is an ops automation problem

Every failure mode in this guide — the drift between two systems that both look correct, the manual entry that defeats a scan-driven process, the open order that crosses a cutover uncounted — is the same underlying problem: work that depends on a person remembering to do a manual step correctly, every time, forever. That is not a warehouse problem specifically; it is the same shape of problem as a failed payment retry that nobody actioned or a stock sync that silently stopped running. Pointerflow’s ops automation work treats a WMS-to-Shopify sync the same way it treats any other operational handoff: instrumented, alerted on when it drifts, and designed so the manual step is the exception, not the daily routine.