Predictive Analysis

Some decisions have to be made before the moment they are about. Server capacity for next quarter is too late once traffic has already arrived, and support staff hired after the queue has built up need another month of training first.

Substituting last month's figure for those decisions was common. At Pagedeck, support staffing was set to last month's ticket volume, and in the month new signups doubled, first response times reached three days. Nobody had been careless; the number was simply describing a different month. Last month's number is the answer to last month.

Guessing was no better. Provision generously and money goes out on unused servers and idle staff; provision tightly and the service falls over in a busy month. Which way you were wrong only becomes visible the following month.

Another route opened as records accumulated and computation got cheap: taking twelve to twenty-four months of values as material and drawing next month's figure in advance. The goal is not being right but having a basis for how much to prepare.

Decide what to estimate and how far ahead, build a model from the record, check it against a period you already know, and report a range.

1. Fix the target and the horizon. The target has to reduce to a single number, like ticket volume next month, and how far ahead gets fixed alongside it. One month out and twelve months out cannot be produced the same way; the further out, the wider the range, and past some point it stops being useful.
2. Gather the material. Twelve months minimum, and twenty-four if the value is seasonal. With only one year, there is no way to tell whether a December rise is an end-of-year effect or something that happened once. Two years is the minimum price of separating a pattern from an incident.
3. Choose a model. Starting with something simple that captures trend and seasonality works better. More complex is not reliably more accurate, and a figure you cannot explain does not get used in a meeting.
4. Validate against a known period. Hold back the last three months, build the model on the rest, and see how well it predicts what you held back. Recording the error as a percentage settles how much weight this forecast carries. A model averaging 30 percent error cannot drive a hiring plan.
5. Report a range, not a point. Write 1,275 tickets next month and a month that comes in at 1,290 counts as wrong. Write 1,150 to 1,400 and the range becomes an amount to prepare for.
6. Compare against reality. Record the forecast and the actual side by side each month, and add one line explaining any month that missed badly. That record becomes material for the next model.

It fits decisions with lead time: hiring people, expanding capacity, ordering inventory. It also serves when building next quarter's budget or working a target backwards. What those share is that being wrong is recoverable. Hiring one more person leaves room to adjust; an announced price is hard to take back.

Four limits are worth knowing.

1. It cannot estimate anything without precedent. Change the pricing structure or enter a new market and the historical record stops being material. Those get settled by experiment instead.
2. Reported as a single point, it is remembered only as wrong. A range plus the error margin is what moves the conversation on to how much to prepare. The range is not hedging; it is the honest output of the method.
3. It does not explain causes. Even when the result that next month will rise turns out correct, why it rises is not something this method answers. That question belongs to diagnostic analysis.
4. Skip the earlier stages and it becomes arithmetic theater. Summarize what happened with descriptive analysis and confirm why before looking forward. Invert the order and you end up forecasting a badly defined metric with great precision.

"Next quarter comes out between 1,150 and 1,400 tickets. Let's budget one more support hire."

Converting a range into an amount to prepare.

"Validated against the last three months, the error is 28 percent. That's not enough to set headcount on."

Measuring the model's accuracy before deciding whether to use it.

"Change the pricing and the history stops being material. That one we test."

A judgment that this method does not cover changes without precedent, and that an A/B test does.

At Pagedeck, Mia estimates ticket volume and paid account count each quarter. The material is twenty-four months, and the method captures trend and monthly seasonality and nothing else. The error gets recorded monthly: ticket volume lands inside 15 percent and paid accounts inside 9 percent. Neither is precise enough to commit to externally, and both are precise enough to staff against.

One month missed badly. An ad campaign Ravi ran moved up by two weeks, traffic arrived early, and the actual figure exceeded the top of the range by 40 percent. Since then the ad calendar goes into the material, and unplanned traffic is documented as falling outside the range rather than being something the forecast should have caught.

The most common error is reading this as the most advanced of the three. It deals with the future, so it sounds more developed, and tool marketing usually lays them out in that order. But the three are ordered by the tense of the question, not by difficulty. A team that cannot count last month's conversion rate precisely will produce a forecast built on the wrong definition. Nine out of ten analyses in practice stay in the first two positions, and that is not a sign of being behind — it is because most decisions get made from those two.

The second error is assuming a more complex model is more accurate. Harder-sounding method names inspire more confidence, naturally enough. But which one is better is settled empirically at step 4. Trend plus seasonality frequently beats something far more elaborate, and with only twenty-four months of material, a complex model bends itself to fit those twenty-four months and misses the next one by more. On top of that, a figure nobody can explain does not survive as evidence in a meeting, and a simple method survives the person who built it moving on.