Inventory

A Case Study in Predicting Stock Outs Before They Happen

There's a moment in every manufacturing business when someone walks into the warehouse, looks at an almost-empty shelf, and says the most expensive sentence in operations: "I thought we had more."

That sentence costs more than you think. Not just in lost sales or idle production lines, but in the frantic phone calls to suppliers, the expedited shipping fees that eat your margins alive, and the slow erosion of trust with customers who were told their order would ship on Tuesday.

This is the story of a South African manufacturer that decided to stop being surprised.


The Problem That Hides in Plain Sight

Here's what most inventory systems do: they tell you what you have. Right now. Today. They're a photograph of the present moment, which is a bit like checking the fuel gauge only when the engine sputters.

The team at this company had stock levels. They had spreadsheets. They had experienced people who could "feel" when things were getting low. And yet, stockouts kept happening.

Why? Because a stockout isn't a single event. It's the end of a chain reaction that started weeks or months earlier, when someone should have placed an order but didn't because the numbers looked fine at that moment.

The real question was never "how much do we have?" It was "when does the music stop, and did we already miss our chance to prevent it?"

They called that moment D-Day.


Building a Time Machine Out of Data

The Stockout Forecast Dashboard doesn't do anything revolutionary in isolation. Each piece of it is unremarkable. What makes it work is how those pieces combine to create something no spreadsheet can deliver: a view of the future that's honest about what it doesn't know.

Here's what it actually does.

It starts by looking backward. For each critical imported product, the system pulls weekly stock snapshots going back six months. Not just current levels, but the trajectory. A photograph versus a film. The snapshot history creates context: are we burning through stock faster than usual? Has demand shifted? Is there a seasonal pattern we're ignoring?

Then it calculates a burn rate. Using a configurable sample window, typically the last four weeks of stock movements, it computes the net weekly change. Not just dispatches, but the full picture: goods dispatched, returned, exchanged, received, repaired, substituted. The real number. The honest number. And it expresses this as a weekly average, the velocity at which stock is disappearing.

With current stock on hand, reserve levels, and the burn rate, it does simple but consequential arithmetic: at this rate, when do we hit zero? More precisely, when do we dip into reserve stock, the emergency buffer that exists precisely because forecasts are imperfect?

That's D-Day. The date the dashboard shows in bold, colour-coded red, amber, or green depending on how much time you have left to act.


Your business is unique — your software should be too. Let's talk about a system built around how you actually work.

Book a free consultation

The Part Nobody Else Builds

But here's where it gets interesting. Most systems would stop there. Calculate depletion, show a date, done. This one doesn't, because the team understood something crucial: knowing when you run out is useless unless you also know when you needed to have already ordered.

And that calculation is surprisingly hard.

The system works backward from D-Day through a chain of lead times. These aren't simple constants. They're dynamic, context-aware calculations that account for the real-world mess of international supply chains.

Manufacturing lead time. Each product has a different production cycle at the overseas factory. Some take six weeks, others twelve. This is the floor; you can't compress it.

Shipping lead time. Six weeks on the water from China to South Africa. Not negotiable. Not compressible. A hard constraint that most people underestimate until they've been burned by it.

Chinese New Year. This is the detail that separates a dashboard from a decision-making tool. The system contains a lookup table of Chinese New Year dates extending to 2035. It knows that factories shut down for roughly three weeks around these dates. And it doesn't just flag the holiday; it calculates whether the holiday will interrupt a production run, and if so, pushes the entire order timeline forward to ensure manufacturing completes before the shutdown begins.

This is worth pausing on. Most inventory systems treat lead times as fixed numbers. This one treats them as living calculations that shift based on where they fall on the calendar. The same product ordered in November has a fundamentally different timeline than the same product ordered in January, and the dashboard knows this.

December shutdown. The company itself closes for several weeks around Christmas. Nobody is there to receive a container. So if a shipment would arrive during shutdown, the system pulls the entire timeline forward again. Stock needs to arrive before the doors close, or it might as well not exist.

The result of all this backward calculation is the order cutoff date: the last possible moment you can place a purchase order and still have stock arrive before D-Day. When that date turns red, you're no longer forecasting. You're watching a problem you can no longer prevent.


Making the Invisible Visible

The dashboard presents all of this as a single, scrollable list of critical products, sorted by cutoff date. The most urgent items appear first. Each line item shows four things at a glance: available stock (minus reserves), the weekly burn rate, D-Day, and a colour-coded risk indicator.

One click expands any product to reveal the full story. A Chart.js line graph shows twenty-six weeks of history and twenty-six weeks of projection. The historical line is solid; the forecast is dashed. This distinction matters. It's a visual reminder that the right half of the chart is a prediction, not a fact.

The chart includes two annotations. A shaded horizontal band marks the reserve level, the stock you never want to touch. A shaded vertical band highlights Chinese New Year, a visual cue that the calendar is working against you.

Below the chart, a four-step timeline lays out the recommended action plan: cutoff date, shipping date, arrival date, D-Day. Each one is a computed date, not a guess, derived from the interlocking lead-time calculations described above. It's a visual contract: if you place the order by step one, stock arrives by step three, before the deadline at step four.

The dashboard also shows what's already in the pipeline. Open consignments and shipments appear with their ETAs, quantities, and the ability to update arrival dates in real time. Because a forecast is only as good as its inputs, and shipment ETAs change constantly.

Three headline metrics sit at the top: the nearest D-Day across all tracked products, the number of items at danger level, and the number of items currently on order. These exist so that the managing director, who will never expand a single product row, can glance at the screen and know whether to worry.


You shouldn't need to find workarounds.
Let's build the software so you won't have to.

The Design Decisions That Matter

Several architectural choices in this system deserve attention because they reveal a particular philosophy about how software should serve a business.

The sample window is adjustable. A dropdown lets users change the burn-rate calculation from four weeks to eight or twelve. This isn't a feature; it's an acknowledgment that the right answer depends on context. If there was a once-off large dispatch last week, a four-week window will overstate the burn rate. Widen it, and the anomaly dilutes. This is a tool that trusts its users to apply judgment.

Reserve stock is treated as sacred. The system doesn't calculate depletion to zero. It calculates depletion to the reserve threshold. This is a design decision that embeds a risk management philosophy directly into the arithmetic. The reserve exists as a buffer against forecast error, and the tool respects that buffer by raising alarms before it's touched, not after.

The projection floor is zero. When the forecast line dips below zero, it clips to zero. This is a small thing, but it matters. A chart showing negative stock levels would be technically accurate and completely misleading. You can't have negative stock. The floor at zero communicates the reality: once you're out, you're out. The duration of the outage is a separate conversation.

Shipments are integrated into the forecast. Expected arrivals aren't shown as a separate number to mentally add. They're factored into the projection curve itself. The system adds incoming shipment quantities to the forecast at their expected arrival dates, creating a line that dips, then steps up when a container lands, then resumes its decline. This is the shape of reality, and showing it honestly means nobody has to do mental arithmetic to understand whether the pipeline will save them.


What Actually Changed

Before this dashboard, the ordering process was a monthly conversation. Someone would pull up stock levels, compare them to a mental model of lead times, and make a call. It worked until it didn't. And when it didn't, the consequences were severe: a manufacturer without product is just a building with a parking lot.

After the dashboard, the conversation shifted. People stopped asking "what do we have?" and started asking "when do we need to act?" That's a fundamentally different question. The first one is reactive. The second one creates space for decisions.

The colour-coded alert system created a shared language. Red means the cutoff date has passed or is imminent. Amber means it's approaching. Green means relax, but don't forget. When the Monday meeting pulls up the dashboard and two items are red, the conversation is focused before anyone opens their mouth.

The Chinese New Year adjustment alone probably paid for the development time. In an industry where a three-week factory shutdown can cascade into a two-month stockout if you're not prepared, having a system that automatically adjusts timelines around the holiday is the difference between planning and panic.


The Lesson

This dashboard is not artificial intelligence. It's not machine learning. It's not a blockchain or a digital twin or any other technology that makes venture capitalists reach for their chequebooks.

It's arithmetic. Careful, contextualised, domain-specific arithmetic, wrapped in a presentation layer that makes the answer obvious to a human being who needs to make a phone call to a factory in China.

And that's the point. The most valuable software in a business is rarely the most sophisticated. It's the software that takes a question the business asks every week, computes the answer automatically, and presents it in a way that makes the right decision feel obvious.

The companies that run out of stock aren't companies that lack data. They're companies that have data in one place, calendars in another, lead times in someone's head, and no tool that stitches it all together into a single honest picture of the future.

This dashboard is that tool. Not because it predicts the future perfectly, but because it forces the conversation to happen early enough that imperfect predictions are still useful.

The best time to order stock was weeks ago. The second best time is before D-Day turns red.


This case study examines the Stockout Forecast Dashboard built for a South African manufacturer, illustrating how domain-specific inventory forecasting, supply chain lead-time modelling, and honest data visualization can transform reactive stock management into proactive procurement planning.

Run your business, your way.

Your business is unique, but your software is off the shelf? Ditch the workarounds and let's build your ERP systems to fit your teams.