Forecasts that beat the obvious guess

What this actually solves

Almost every expensive decision in an operating business is a guess about the near future. How much to order, how many people to roster, which customers to phone this week, whether this quarter's revenue supports the hire. Those guesses are usually made by one experienced person, and that person is genuinely good — but they can hold twenty lines in their head, not two thousand, so the long tail gets a rule of thumb applied to it and the errors accumulate quietly at both ends.

Both ends cost money in different currencies. Order too much and cash sits in a warehouse in a form you cannot spend. Order too little and the sale simply does not happen, which is worse because it leaves no trace in your reporting — you can see the stock you bought, you cannot see the customer who found it out of stock and went elsewhere. Churn behaves the same way: a customer who leaves quietly looks identical in the data to one who never existed, and by the time the revenue drop is visible in a monthly report the window for intervening closed weeks ago.

What a forecasting project buys is not a crystal ball. It is a defensible number attached to a specific decision, produced consistently across every line rather than carefully for the top twenty, with an honest error range around it so the person acting on it knows how much weight it will carry.

How the work runs

1. Pin down the decision, the horizon and the threshold. What choice does this number change, how far ahead does it need to see, and how accurate does it have to be before it is worth acting on rather than ignoring. A four-week SKU-level forecast that drives a weekly purchase order is a different build from a quarterly revenue view for the board. Three to five days.
2. Audit the data and check it means what it says. Length of history, granularity, completeness of promotions records, and above all whether stock-outs were recorded. Anything missing is documented with its consequence rather than quietly worked around. About a week.
3. Build the baselines and score them. Same as last period, same period last year, and a moving average. They take a day to construct and they set the bar the model has to clear. Without them there is no way to answer whether eighteen percent error is a good result or an embarrassing one. One to two days.
4. Clean, engineer features, and fit. Calendar effects, holidays, promotions, price changes, weather where it genuinely matters. Then Prophet or statsmodels for well-behaved seasonal series and LightGBM where many features interact, validated on time-ordered splits so the model is never scored on data from before its training window. Three to five weeks, most of it in the cleaning.
5. Turn the output into something usable. Not a table of predictions — a screen or a feed that says what to order, which accounts to call, what the range is, and how much confidence to place in it, built in Streamlit or Metabase or written back into the system where the decision is actually made. One to two weeks.
6. Set up monitoring and the retraining rule. Live error tracked against the same baseline, with a documented trigger for refitting. Three to five days.

What moves the price

The range is $2,500–$25,000 over 6–14 weeks, and three things account for almost all of the movement inside it.

The state of the data. This is almost always underestimated, by us as much as by anyone. Inconsistent SKU codes, a promotions log that stopped being maintained two years ago, three systems that disagree about the same week — cleaning is routinely the largest block of hours in the project, and how bad it is cannot be known until someone looks.

Scale and horizon. Forecasting forty product lines four weeks out is not the same job as several thousand lines twelve months out. More series means more failure modes, more slow-moving items where the metric misbehaves, and a heavier pipeline underneath.

Where the answer has to land. A dashboard is the cheap end. Writing forecasts back into an ERP or a purchasing system, on a schedule, with error handling and alerting when the feed fails, is a piece of integration engineering sitting on top of the modelling work.

What usually goes wrong

No baseline exists, so the result cannot be judged. Three weeks of work produce a model and a headline error figure, you ask whether that is good, and there is no answer. If last year's same-month rule was already more accurate, the model is worse than doing nothing and the project has been a costly way to arrive back where it started. The baseline takes a day and gives every number afterwards a meaning.

Sales history gets treated as demand history. They are not the same thing. Your sales records show what you managed to sell, capped by what you had on the shelf. If stock-outs were never logged, the model learns your past shortages and forecasts them forward — you under-ordered a line last summer, it looked like low demand, so it recommends under-ordering again. Establishing whether stock-out records exist is one of the first questions asked, because it changes both the modelling approach and what can honestly be promised.

A number gets delivered where a decision was needed. The model is sound, the accuracy beats the baseline, and it is handed over as a spreadsheet of predictions that nobody opens because the buyer already has a process and this does not fit into it. The forecast has to arrive at the moment the purchase order is raised, in the form the person raising it works in, or it changes nothing at all.