Orthodox Easter moves, August empties the cities and heatwaves arrive unannounced. What we have learned about forecasting when the calendar runs the business.
Most of the businesses we forecast for live by the calendar. Water demand in Athens follows the heat and the holidays. Hotel bookings on the islands follow the flights. Electricity load follows all of it at once. The textbook treatment of seasonality assumes a tidy yearly cycle. Greece does not offer one, and the gap between the textbook and the data is where forecasting projects are won or lost. These are the notes we wish we had at the start.
The calendar is a feature, not a nuisance
Orthodox Easter moves by up to five weeks from year to year. The fifteenth of August empties the cities and fills the coast. Name days matter for some retailers. School terms shift demand for everything from bakeries to bandwidth. A model that only knows the day of the year will see these as noise and smooth them away.
So the first artefact on every project is a calendar table: public holidays, moveable feasts, school terms, the tourist season’s rough start and end, and any events the client knows about, such as a festival or a trade fair. Every model gets it as input. The improvement from this table alone is often larger than from any modelling choice made afterwards.
Weather explains a lot, but only if you have it at prediction time
Water and electricity demand track temperature closely. The tempting move is to feed actual temperature into the model and watch the backtest improve. The trap is that at prediction time you do not have actual temperature; you have a forecast of it. A model trained on actuals and run on forecasts is being tested on a different problem than the one it will face.
We train on the weather forecast as it was issued, when the client can get the archive, and on actuals with added noise when they cannot. It makes the backtest look worse and the production model honest. For a utility planning tomorrow’s operations, honest is the only useful kind.
Your history contains a pandemic
Two years of history is comfortable for a seasonal business. Longer is better, until it is not: any series that reaches back to 2020 contains a year that will never repeat. Lockdowns, empty hotels, cities with no traffic. Left in, that year teaches the model that spring can vanish.
There is no elegant fix. We mark the period explicitly with an indicator the model can learn to discount, and we check the backtests separately for the years before and after. Where the business changed permanently, remote work shifting weekday demand for example, we let the recent years carry more weight.
Forecast at the level people decide at
A network operator plans per zone and per day, sometimes per hour. A hotel group plans per property and per week. Forecasting at a finer grain than the decision adds noise; forecasting at a coarser grain hides what the planner needs. We ask what the decision is, forecast at exactly that level, and reconcile upwards so the district totals match the zone totals. When the client’s planning still happens in a spreadsheet, the forecast lands in the spreadsheet.
Beat the baseline, then show the uncertainty
Every planner already has a method: the same week last year adjusted by a percentage, or a seasonal average with a gut-feel correction. We measure it first, on the same time-based backtest, and only claim improvement over it. For seasonal data, classical methods and gradient-boosted models with good calendar and weather features win far more often than deep learning, and they retrain in minutes on a schedule.
Then we ship intervals, not just a number. A forecast of 400 with an 80% range of 380 to 420 and one with a range of 300 to 500 call for different decisions. Planners who see the range trust the point forecast more, not less, because they can see when the model itself is unsure. The week before Easter, it usually is.
Drift arrives with the season
A model that looked fine through winter can wander in June, because summer demand has a different structure and the training data underweighted it. Input monitoring catches this early: temperature outside the training range, volumes above anything seen before, a new zone appearing in the feed. We alert on inputs the same day and on accuracy the same week, and the retraining schedule tightens around the season changes rather than running on a fixed monthly cadence.
The short version
Build the calendar table before the model. Train on the weather you will actually have. Mark the pandemic. Forecast at the level of the decision. Beat the planner’s baseline, show the range, and watch the inputs when the season turns. The models are the easy part.