Regression, and the Driver You Can Actually Get
A driver-based forecast is only as good as the driver's own forecast. The question that decides whether regression is worth it, and the drivers that pass it.
A regression forecast replaces one forecasting problem with another: instead of forecasting demand, you forecast the driver and convert. That is only an improvement if the driver is easier to forecast than demand, and the test is whether you will actually have the driver's value at the horizon.
The method in “Regression, and the Driver You Can Actually Get” is only as useful as the definitions and source records behind it. A team exploring check the corresponding feature page for time tracking software can add timely work and project context, with transparent settings, limited access and a documented correction route around every consequential use.
Most driver models fail this test and are built anyway.
Additional context for “Regression, and the Driver You Can Actually Get” is available from Eurostat population and workforce data. External material is most useful when it prompts a specific validation check rather than replacing local judgement.
The question that decides it
At the moment the forecast is needed, will the driver's value for the forecast period be known, or will it have to be forecast too?
At the moment the forecast is needed, will the driver's value for the forecast period be known, or will it have to be forecast too? Known: worth having. Forecast: two uncertainties where there was one.
Known: the model is worth having. Forecast: you have two uncertainties where you had one, and the result is usually worse.
Drivers that are known in advance
Dispatch volumes and dates. Campaign schedules. Billing cycles. Release calendars. Customer counts, which move slowly. Contract starts. Opening hours.
These are the drivers worth modelling, and they are mostly internal schedules rather than external variables.
Drivers that are not known in advance
Weather, beyond a few days. Competitor activity. Economic measures, which are themselves forecast with wide error. Anything that would itself need a model.
Building on these produces a forecast whose error includes the driver forecast's error, usually invisibly.
The relationship has to be stable
As well as the driver being knowable. A coefficient estimated three years ago on a relationship that has decayed is worse than no model.
This is the subject of its own note here; the practical point is that a regression needs a review date as much as it needs a coefficient.
How many drivers
Few. Two or three strong, knowable drivers plus a baseline outperforms a model with fifteen variables in almost every workforce application.
Each additional variable adds estimation error and another thing that can decay, and the marginal explanatory power falls quickly.
Correlation between drivers
Common and troublesome: campaigns are scheduled around billing, which is scheduled around month-end. The model cannot separate their effects and the coefficients become unstable.
The symptom is coefficients that change sign or size between re-fits. The remedy is usually to combine them into one calendar effect rather than to model them separately.
Testing out of sample
Non-negotiable here. A regression will always fit the history better than a simple method; the only question that matters is whether it forecasts better.
Hold back periods, forecast them using only information available at the time, and compare against a weighted average. Many models do not survive this.
Information available at the time
The subtlety that invalidates most in-house tests. Using the actual driver values for the held-back period, when in production those values would have been forecast, flatters the model substantially.
The test has to replicate what would really have been known.
What a good driver model looks like
A baseline from the series, plus two or three named schedule effects with sizes and dates, plus a stated band. It is barely a regression in the statistical sense and it is what most operations actually need.
The explicit form also means a wrong forecast can be traced to a wrong driver value, which a fitted model rarely allows.
When the driver is wrong
It happens: a campaign is cancelled, a dispatch slips. The forecast should be re-run rather than defended, and the error record should note that the driver was wrong rather than the model.
Separating driver error from model error is what makes the record usable, and it needs one extra column.
The driver that is available late
A practical constraint separate from whether it is knowable: the dispatch volume may be fixed six weeks ahead but only reach the planner two days before.
The model is then unusable at the horizon it was built for, and the fix is a data arrangement rather than anything analytical.
Lags
Most driver effects are not same-day. A dispatch produces contacts over four or five days; a release produces questions for a fortnight.
Estimating the lag structure matters as much as the size, and a model that applies the whole effect on day one is wrong about the shape even when it is right about the total.
The coefficient that is really a calendar
Worth testing: where a driver's apparent effect is actually the day of week it usually falls on, the coefficient will collapse once weekday is controlled for.
This is the commonest spurious driver and it is caught by one extra term.
Where regression genuinely wins
Where a large, knowable, stable driver exists — a dispatch schedule driving the majority of contacts, a contract with a fixed volume profile. In those cases it is much better than anything built from the demand series alone.
Those cases are worth finding, and they are usually obvious once somebody asks which part of demand the organisation itself schedules.