Forecast

Forecast of demand, load and key metrics — calculated from your history and from what's happening outside: season, weather and city events.

• AURA THINKLevel
• IntelligenceFamily
• in AURA subscriptionBilling

Problem

Demand is uneven, and shift schedules, supplier orders and campaigns rarely keep up with its rhythm. Tuesday stands empty, on Friday a queue forms, and decisions about staffing and inventory are made "as usual" — meaning based on last week and gut feeling. After the fact it's always clear how it went; before the fact, no one knows.

What we do

We build forecasts of demand, load and key indicators: what will likely happen in the nearest period and how certain we are about it.

• The foundation is your own sales history, not the industry average
• We add seasonality and external signals to the history: weather, events, holidays
• The forecast is a number with a range, not a single promise — and that's exactly how we show it

What's included

Four elements; the last one distinguishes forecast from fortune-telling:

• Sales and traffic history organized enough to calculate from
• Seasonality and repeatable weekly rhythms
• External signals: weather, city events, holidays
• Comparison of forecast with what actually happened

How long it takes

The module doesn't start separately — it activates together with the AURA level it's part of. But it has its own start condition: the forecast is calculated from history, so until there's history in the system, there's nothing to build it from. The longer the module works, the more it has to compare to — that's why forecast vs. actual comparison is included from day one, not added later.

How much it costs

A forecast cannot be lifted out of the system and sold separately — it is calculated from the history the other modules collect, and without them it would show an empty axis. Billing goes for the whole system in the venue. How much exactly comes out of how long a history you already have and how many places have to be forecast at once.

Demand forecasting is included in the THINK level. At the SEE level, indicators and basic external signals remain — what's already happened, without looking ahead.

What you get

Decisions made in advance, not after the fact: shift staffing, supplier orders and campaigns align with expected traffic. The forecast with a range also tells you when it doesn't trust itself — and that's equally useful information, showing where it's not worth betting everything on one outcome. We don't promise results: the forecast reduces guessing, it doesn't replace decisions.

How forecast accuracy is measured

A forecast with no error measure is just a number you either trust or don't. The standard statistical method is the mean percentage error:

• Forecast error (MAPE) = the average of |forecast − actual result| ÷ actual result, worked out after each closed period and expressed as a percentage
• It is worked out separately for each period (day, week), because the error on a Monday and the error on a Saturday are usually not the same
• The trend of the error over time says more than a single value — a shrinking error means the model is learning your own rhythm, not just repeating an average

That is why a forecast in AURA is shown with a range rather than a single figure: the range itself is information about how confident the model is.

How much history a forecast actually needs

This is a question about method, not a specific number of weeks, because it depends on which rhythm you are trying to predict.

• For the model to see the rhythm of a week, it needs several full weeks of history — otherwise it cannot tell Friday from Tuesday and just averages the two
• To see a yearly season (summer, holidays, breaks), it needs at least one full year — a shorter history does not contain a single complete cycle
• The data needs to be organised at transaction or day level, not as one monthly total — a monthly total cannot be unpacked back into a weekly rhythm

A new venue with no history of its own simply has nothing to calculate a forecast from — and that is not a technical limitation but a statistical fact: a forecast is a formula built on recurrence, and there is no recurrence yet.

Why the forecast runs on your own history, not an averaged industry curve

An averaged industry curve sounds tempting, because it hands you a number right away, without waiting for your own data. The trouble is it averages hundreds of different venues into one curve that fits precisely none of them.

• Two restaurants on the same street can have a completely different weekly rhythm — one lives on the office lunch crowd, the other on Saturday dinners
• An industry curve knows nothing about your local events, a refit next door, or a competitor changing its opening hours
• The error of a forecast built on someone else's curve cannot be measured against your own numbers until you compare it with your own result — and at that point you need your own history anyway

That is why we do not quote any averaged industry norm here: we have no such data, and a made-up figure would be worse than none at all.

When a forecast will not hold up

A statistical model assumes the future resembles the past to some degree. Wherever that assumption breaks down, the forecast stops making sense:

• The venue has been open for less than one full seasonal cycle, so the model has not yet seen the pattern it is meant to predict
• The business runs mostly on one-off, non-repeating events (weddings, bespoke banquets) with no recurring weekly rhythm
• The company is right in the middle of a fundamental change — location, menu, hours — so the history from before it no longer describes what comes next
• Nobody on your side plans staffing or orders in advance — then the forecast is a number with nobody to act on it

What you need to have on your side

A forecast runs on data, so the quality of the data sets the quality of the forecast — that is not a formality, it is a starting condition.

• Sales or footfall history in a form a machine can read, not paper reports
• Someone who flags known exceptions (a refit, a breakdown, a one-off event) — otherwise the model learns them as the normal rhythm
• A regular export of new data, so the forecast keeps updating on current numbers rather than data from six months ago
• A person who actually makes staffing and ordering decisions based on it — a forecast that gets read but not acted on changes nothing

How to check after a month whether the forecast is useful

Don't judge a single forecast that hit or missed — judge the trend across several periods in a row.

• The forecast error (MAPE) from the previous point — is it falling or standing still across several consecutive periods
• The number of urgent 'right now' corrections to supplier orders — should fall if staffing and orders are planned ahead
• The gap between planned and actual shift staffing, measured in hours of overtime or downtime

Compare the same type of period with the same: a Friday with a Friday, not a Friday with a Tuesday.

What a forecast does not do

A forecast shows a number and a range of uncertainty — it does not make any decision for you. It does not order stock from a supplier by itself, does not build the shift schedule (that is the scope of a different module in the ACT tier), does not predict random events outside the pattern, such as a breakdown or a sudden protest, and does not work without a plan for its own error — because any forecast with a range, by definition, is sometimes wrong.

The most common mistake when using a forecast

The most common mistake is reading the middle of the range as a certainty and ignoring how wide the range actually is. A forecast of '120 people, plus or minus 40' is completely different information from '120 people, plus or minus 5' — and the staffing decision should differ in both cases even though the central number is identical. A second common mistake is not feeding the model your own exceptions: a refit reported after the fact damages the accuracy of several following weeks, not just that one.