A forecast you have to open is already late

Suppose a product that sold forty units a week for a year suddenly sells sixty-five this week. The dashboard shows it. A line ticks up. Nobody is looking, because the dashboard looked fine yesterday and nobody opens a thing that looked fine yesterday. By the time someone notices the shelf is empty, the spike is three weeks old, the reorder takes two more, and the customers who wanted sixty-five units bought from someone else.

The number was right there the whole time. That was the problem.

A forecast you have to open is already late. The value was never the chart. The value is the moment the curve breaks from its own pattern, and the message that arrives to tell you, with the reason attached. This post is about why those are two completely different products, and why almost everyone builds the wrong one.

The thing you actually want is not a prediction

Ask someone what a demand forecast is for and they’ll say: to know how much to make, or stock, or staff. True, but incomplete. You don’t make a decision against a forecast every day. You make it when something is about to be wrong, when next month is going to look unlike the months that taught you what normal is.

So the job isn’t producing a number. Producing a number is easy; a flat average produces a number. The job is noticing, before it costs you, that the number is no longer the right one. The forecast that matters is the one that interrupts you.

A forecast you have to open is already late.

Let’s explain why the dashboard version of this, the one everyone has, structurally cannot do that job, and what has to replace it.

The naive version: a chart you’re supposed to watch

Here is the forecast almost every company actually has. A tool reads last year’s sales, fits a line, draws a curve into next quarter, and puts it on a page behind a login. Maybe it’s clever about seasonality. Maybe it has confidence bands. It is, by the standards of the math, a perfectly good forecast.

And it sits there.

The failure is not in the model. The model is fine. The failure is the delivery: a forecast on a page is a question waiting to be asked, and nobody asks it on the day it matters. You open the dashboard when you remember to, which is to say when nothing is wrong, which is to say never at the moment you needed it. The chart updated overnight; the spike was visible at 6am; you saw it at 3pm two Thursdays later when a stockout forced you to look.

The cost isn’t the accuracy of the curve. The cost is the gap between the data knew and you knew. That gap is where the lost sale lives, the panic reorder, the overtime shift you scheduled too late. A pull-based forecast pushes the most time-sensitive decision in the business onto the one thing humans are worst at: remembering to check a thing that was fine last time.

You can make the chart prettier. You can make the model smarter. Neither closes the gap, because the gap isn’t in the chart or the model. It’s in who has to go looking.

The shift: stop predicting the number, start watching the break

The naive instinct, when the chart fails you, is to forecast harder, more history, a fancier model, tighter bands. That’s solving the wrong problem with more effort. The problem was never that the prediction was off by a few percent. The problem was that nobody was watching when reality walked away from the prediction.

So flip it. Don’t build a system whose output is a number you go read. Build a system whose output is an interruption when the number stops being true.

The mechanism is plain once you name it. The forecast becomes the baseline, the system’s standing expectation of what this week should look like, given every week before it. Then something watches the live signal against that baseline, continuously, and stays completely silent as long as reality tracks the expectation. The instant reality breaks from it by more than noise, the spike, the cliff, the slow drift that’s about to become a cliff, that break is the event. Not the number. The departure from the number.

That’s the whole reframe. A dashboard answers “what is the forecast?” The thing you want answers a question nobody had to type: “is anything about to be wrong?”, and only speaks when the answer turns to yes.

Notice what changed and what didn’t. The math is the same, you still need a baseline, and a good baseline still needs seasonality and trend and the lumps your business actually has. What changed is the trigger. The old system triggers on you opening it. The new one triggers on the world disagreeing with it. One of those happens on a schedule you’ll forget. The other happens exactly when it has to.

Why the alert is worthless without the why

Here’s where a worse version of this idea fails, and it’s the version most “anomaly alerts” ship as. The system watches the baseline, the signal breaks it, and you get a ping: Sales up 60% this week.

You read it standing in a hallway. And now you have a new problem, because that ping told you something is different but nothing about whether it’s real. Is it a genuine demand shift you should reorder against? A pricing change someone made on Tuesday? A holiday the model didn’t know about? One big customer front-loading an order they’ll skip next month? A data glitch double-counting a channel? The bare number can’t tell you, so you do the thing the alert was supposed to save you from: you go open the dashboard and start digging.

An alert with no reason is just a louder dashboard. It moved the interruption earlier, which is good, but it handed you the same scavenger hunt, which is most of the cost.

The reason is the product. The same way a useful coworker doesn’t say “the 2pm matters” but “the 2pm matters because their contract renews in nine days,” a useful forecast doesn’t say “demand is up 60%.” It says: demand for this product broke 60% above its baseline this week; it started Tuesday, it’s concentrated in one region, and it lines up with the promotion that went live Monday, here’s what reorder this implies if it holds. Now you’re not investigating. You’re deciding.

Producing that reason is the hard part, and it’s exactly the part a charting tool can’t do, because the reason doesn’t live in the sales numbers. It lives across the corners of the business that a dashboard never connects.

Where the reason comes from

To say why a curve broke, a system has to do something a forecasting model never does: look outside its own column of data. The sales line knows that demand jumped. It has no idea that a promotion launched, that a price changed, that a competitor went out of stock, that a holiday landed early this year, that one account placed an unusual order. Those facts live in other systems, the calendar, the pricing log, the CRM, the company’s own notes and decisions.

A break in the curve and the cause of the break are almost never in the same place. That’s why the dashboard can show the break and never explain it: a chart of sales can only ever know about sales.

So the move is to make the watcher reach. When the baseline breaks, the system doesn’t just report the delta, it pulls the threads near that delta. What changed in this product’s price recently? What was scheduled this week? Which accounts moved? Was there a decision logged that touches this line? It assembles the candidate explanations and ranks them, the same way a sharp analyst would, except it does it in the seconds after the break instead of the hours after you noticed.

That assembly is the difference between an alarm and an analyst. An alarm tells you the smoke detector went off. An analyst walks in and says it’s the toaster, it’s been the toaster for ten minutes, and here’s whether to evacuate.

This is why “can Apollo forecast your demand?” is the wrong question, or rather the small half of the right one. Anyone can fit a curve. The forecast you actually want is the one that watches its own baseline, catches the break the moment it happens, reaches across your whole business to explain it, and arrives in one message before the stockout, not a chart you were supposed to remember to read.

A forecast you have to open is already late.

The turn: the cost was never the model

Strip away the math and here’s what this is really about.

In most companies, somebody is the forecast. A founder who senses when something’s moving because they happen to glance at the right number on the right day. An operations lead who carries the seasonal patterns in their head and gets a bad feeling on a Tuesday. A buyer who notices the spike, sometimes in time, sometimes a week too late, depending on what else was on fire that morning. The accuracy of your demand planning is, quietly, a function of whether the right person looked at the right line on the right day. That’s not a system. That’s luck wearing a spreadsheet.

And it’s the most expensive kind of work to do by hand, because the cost of doing it badly is invisible until it’s a stockout or a pile of unsold inventory. You don’t get a bill for the alert that never fired. You just get the empty shelf, the panic order, the customer who quietly went elsewhere, and you file it under bad luck instead of seeing it for what it was: a forecast you had to open, opened late.

The promise isn’t a smarter chart. It’s that the person who’s currently the early-warning system gets to stop being it. The break finds them, already explained, while there’s still time to act, so the most capable person in the company stops being the one who remembered to check the right line, and gets to be the one who decides what to do about the break.

---

That’s what we’re building at Apollo, not a prettier dashboard, but a forecast that watches itself and speaks the moment the curve breaks, with the reason already attached. If you’ve ever found out about a spike from an empty shelf, you already know the chart was never the point. The point was the message that should have arrived three weeks earlier.