Forecast accuracy and bias
Objective. Define forecast accuracy and forecast bias as two different things, show how each is measured at app-logic level, and explain why they must be read together.
A dictionary entry. Forecast accuracy measures how far forecasts were from actuals regardless of direction; forecast bias measures whether forecasts systematically ran high or low. A forecast can be unbiased but inaccurate, or biased and misleadingly precise.
See it in the demo
What it is
Forecast accuracy measures the size of forecast error - how far predicted volume (or demand) was from actual, ignoring direction. Forecast bias measures the direction of error over time - whether the forecast consistently over- or under-predicted. They answer different questions: accuracy asks 'how close were we?', bias asks 'do we lean one way?'. A forecast with low bias (errors cancel out) can still have poor accuracy (large errors in both directions), which is why both are reported.
How it is calculated
At app-logic level: accuracy is derived from the error between forecast and actual across intervals (commonly an absolute-error or percentage-error style measure, read as closeness); bias is derived from the signed error accumulated over the period (positive if the forecast ran high, negative if it ran low). Included: the forecast version being evaluated and the matching actuals, at the agreed grain (interval, day, skill, queue). Excluded or adjusted: periods with known anomalies or events may be handled separately. The exact error measure, the grain, and how events and outliers are treated are configurable and must match the method the customer agreed - confirm with product. Always evaluate the forecast version that was actually used, not a later revision.
How to read it and the common misread
Read accuracy and bias together and at the grain decisions are made: a plan can look accurate at the daily total yet be badly off interval by interval or by skill. Targets are the customer's agreed accuracy and bias thresholds by method, not a universal figure. The common misread is reading an aggregate accuracy as proof that staffing will be right everywhere - an overall figure can mask interval and skill-level error, the same caution as coverage by interval (MET-13). A second misread is confusing low bias with high accuracy: canceling errors hide real volatility. A third is grading a forecast against a revised version rather than the one actually used to plan.
Where it appears
In Capacity Planning (volume forecast, accuracy, seasonality and events) and in Intraday Management (forecast vs actual and forecast drift during the day). It underpins coverage and scheduling decisions downstream. Demo figures are seeded illustrations.
Interpretation check
Accuracy (size of error) and bias (direction of error) are different and must be read together, at the grain decisions are made. A low-bias forecast can still be inaccurate, and an accurate daily total can hide interval and skill error.
Practical task
In the Capacity Planning demo, find the forecast accuracy view and write down one accuracy figure and one bias observation, then a sentence on the grain you checked (total vs interval/skill) and the method you would confirm with product before quoting accuracy to a customer.
Self-check
What is the difference between forecast accuracy and forecast bias?
Accuracy measures how large the errors were regardless of direction; bias measures whether the forecast systematically ran high or low. Close answers 'how far off', bias answers 'which way we lean'.
How can a forecast have low bias but poor accuracy?
If large over-predictions and under-predictions cancel out, the signed error (bias) is near zero while the typical error size (accuracy) is still large. Both must be reported.
Why is an accurate daily total not enough?
It can mask interval- and skill-level error. Staffing decisions are made at those grains, so the forecast must be evaluated there, not only at the aggregate - the same caution as coverage by interval.
Which forecast version should be graded, and what should you confirm with product?
The version actually used to plan, not a later revision. Confirm the error measure, the grain, and how events and outliers are handled, since these are configurable and must match the agreed method.
Verified vs demo. The demo shows accuracy and bias on seeded forecasts and actuals. A customer's figures depend on their chosen error measure, grain, event handling and the forecast version evaluated, which must be validated in their instance.