We have officially declared the annual stocktake dead in our logistics module. An 18,000-SKU warehouse with a December 28th "all shelves, whole weekend, 14 people" event delivered 91.4% accuracy. Nine weeks after switching to cycle counting at the pilot tenant we were at 98.7%. Here is how it happened.
Why the annual stocktake does not work
Two reasons. First: in an 18,000-SKU warehouse a 14-person team counting for two days loses focused attention after hour four. Errors compound. Second: the annual stocktake closes the warehouse for ~48 hours, which at our B2B partner translates into 2-3 days of shipping slippage across the December 28-30 weekend. Customer experience suffers too.
Cycle counting goes the opposite direction: 5-15 minutes of counting per day, the warehouse stays open, and errors surface immediately.
ABC categorisation
Every SKU falls into A, B, or C based on the last 90 days of revenue (not units).
- A: 80% of revenue, ~20% of SKUs. Counted weekly.
- B: 15% of revenue, ~30% of SKUs. Counted monthly.
- C: 5% of revenue, ~50% of SKUs. Counted quarterly.
The allocator runs every night and writes cycle_count_assignments for the next day's shelves. A picker logging into the PWA in the morning sees a "cycle count today" wave with 15-25 SKUs. They walk to the shelf, scan the location, scan the SKU, type the counted quantity.
Variance threshold
If the counted quantity is within ±2% of the system stock we accept it automatically, with a stock_movement row of type adjustment. If variance is between 2-10% the line drops into the supervisor wave for a re-count. If variance is >10% (or any variance at all on an A-category SKU) it gets an automatic investigate flag, and the operations lead opens a manual investigation: wrong shelf location? theft? data-entry error on a previous movement?
The change-management lesson
The pilot tenant's warehouse team hated the rollout for three weeks. "We used to count once a year, now every day?" The perception problem was not the volume of work; it was adding a new task on top of existing pick/pack. The fix: we run the cycle count wave at the start of the shift (08:00-08:15) before the picking wave starts, so it does not interrupt core work. The second fix: through the nine-week ramp the supervisor shared the stock-accuracy metric with the team every week, as a board metric. The 91.4% -> 98.7% journey became the team's own story.
After three weeks the tone flipped. Pickers started saying "I counted this shelf this morning, but yesterday's order was two units short, we should check." The process became theirs.
Mobile-driven
Cycle counting runs entirely on the PWA. No paper, no Excel. Scan the shelf, scan the SKU, type the count, hit submit. One SKU averages 22 seconds. A weekly A-wave has 60-80 SKUs, so 22-30 minutes per picker. None of this would work on paper.
The 9-week ramp curve
- Week 1: 91.4% (baseline).
- Week 3: 94.1% (most A-SKUs stable).
- Week 5: 96.8% (B-categories start aligning).
- Week 7: 98.0% (C-categories on their first cycle).
- Week 9: 98.7% (steady state).
Since then it sits at 98-99% with minor wobbles. The remaining 1-2% variance is mostly new product introductions (SKU master data errors), not picker error.