This demand forecasting case study starts with a familiar complaint. A retail chain in Tangerang with a handful of branches came to us with a pattern that had been quietly bleeding margin for years: their best-selling items ran out mid-month, every month, while slower items piled up in the back of every store until they were marked down to move at all. Nobody was incompetent. The ordering was still being decided by gut feel and a spreadsheet, and gut feel does not scale across stores with different customer bases.
The owner's instinct was to blame the branch managers for bad ordering decisions. The actual problem was structural: each manager was ordering from head office based on what they remembered selling well last month, with no visibility into seasonal patterns, no comparison across branches, and no time to properly analyze twelve months of transaction history by hand.
The diagnosis: three symptoms, one root cause
Before touching any technology, we spent two weeks just looking at their existing sales data, which they already had in their POS system but had never actually analyzed as a set.
- Stockouts clustered around the same items every month. Certain SKUs sold out reliably by the 20th of the month at every branch, meaning ten days of lost sales on their best performers, every single month, for years.
- Dead stock clustered at specific branches, not company-wide. A product that moved well at one branch sat untouched at another with a different customer demographic, but head office ordered the same mix for every store.
- Seasonal spikes were invisible until they happened. Ramadan, back-to-school, year-end, each caused a demand spike that surprised the ordering team every single year despite it being the same pattern as the year before.
The root cause was not a lack of data. They had over two years of daily transaction history sitting in their POS exports, untouched. The root cause was that nobody had time to turn history into a forecast, so ordering defaulted to memory and vibes.
Start simple: moving averages beat gut feel
Before recommending anything resembling machine learning, we built the simplest model that could work: a weighted moving average per SKU per branch, with a seasonal adjustment layered on top for known spike periods. This is not exotic. It is the kind of forecasting that has existed in supply chain textbooks for decades. The insight was not the math, it was actually applying it, consistently, per store, instead of relying on one person's memory of what sold last time.
The model took each SKU's last twelve weeks of sales at that specific branch, weighted recent weeks more heavily than older ones, and produced a suggested reorder quantity. For known seasonal periods, we applied a multiplier based on the same period the previous year.
That is the entire model for phase one. No neural networks, no vendor platform, just structured spreadsheet logic running against their existing POS export, refreshed weekly.
Results after two ordering cycles
| Metric | Before | After 2 cycles |
|---|---|---|
| Stockout days per month (top 20 SKUs, avg across branches) | 8-10 days | 2-3 days |
| Dead stock write-downs per quarter | Recurring, significant | Reduced by roughly half |
| Time spent on manual ordering per branch per week | 3-4 hours | Under 1 hour |
The stockout reduction alone paid for the entire project within the first two months, because those were their highest-margin, highest-velocity items. The dead stock reduction took longer to show up but mattered more structurally, because it freed up shelf space and cash that had been quietly tied up in products nobody wanted at that particular branch.
Where machine learning entered, and where it did not need to
After the moving-average model proved itself for two quarters, we introduced a slightly more sophisticated model for a subset of high-value SKUs, one that accounted for cross-branch demand patterns and price elasticity during promotions. This is where you could reasonably call it machine learning, though it was still a modest, explainable model, not a black box. The important sequencing point: this only made sense after the simple model had already fixed the majority of the problem. Jumping straight to a complex model on day one would have been slower to build, harder to trust, and would have solved the same stockouts that a moving average already solved for free.
This mirrors what tends to work in choosing a POS system decisions too: the sophistication should follow the proven need, not precede it.
What almost went wrong
The rollout was not frictionless. Branch managers initially distrusted the system's suggested order quantities, since it contradicted their own instincts on a handful of SKUs in the first cycle. Rather than forcing adoption, we ran the model in parallel with manual ordering for the first cycle, comparing suggested quantities against what managers actually ordered, and reviewing the gap together after the fact. In most cases the model's suggestion held up better against actual sales, which built trust faster than any argument about methodology could have. That parallel-run period, often skipped by teams eager to declare a system live, is usually the difference between a forecasting tool that gets used and one that gets quietly ignored after month two.
The takeaway for any multi-branch retailer
If your stockouts and dead stock follow a predictable, repeating pattern, and most do, you do not need artificial intelligence to fix it. You need someone to actually look at the transaction history you already have, build a forecast model simple enough that your team can understand and trust its recommendations, and run it consistently every ordering cycle instead of relying on memory. Start with the simplest model that addresses your actual pattern, prove it over two or three cycles, and only add complexity once the basics are locked down. The chain in this case study did not need better software so much as better discipline about using the data their software was already collecting.