Zendesk Forecast Accuracy Report

Every staffing decision inherits the forecast’s errors. If the plan said 400 contacts and 470 arrived, no amount of schedule discipline recovers the gap — and the post-mortem will still blame the team.

A forecast accuracy report separates those two failure modes. It compares what you predicted with what actually happened, at the interval level, so you can tell whether a bad week came from bad planning, bad coverage, or genuinely unexpected demand. This guide covers how to build it in Zendesk Workforce Management, the interval traps that make daily accuracy misleading, and what to change when the forecast is consistently wrong in one direction.

What this report should answer

How close was forecast volume to actual volume, by interval and by workstream?
Was required staffing met, over-met, or under-met in each interval?
Did actual handle time match the assumption baked into the staffing model?
Did service levels hold in the intervals where the forecast missed?
Is the error random, or is it biased in one direction?

For definitions, use the glossary rather than restating them: forecast accuracy, shrinkage, schedule adherence, handle time, and ticket volume. Keep the report beside the support metrics dashboard.

How Zendesk WFM builds the forecast

Zendesk WFM generates inbound volume estimates from your historical data using the Prophet forecasting algorithm, based on the workstream scenarios you define. Alongside volume it calculates Full-Time Equivalent (FTE) requirements — how many staff are needed to handle the predicted workload.

Four constraints matter when you interpret the output:

Minimum history. If you enter a date with less than one month of data, no forecast is generated.
Maximum history. The system uses at most two years of historical data; anything older is excluded.
Business hours are not applied to required staffing. Requirements are shown against the historical times volume actually arrived, so you have to reconcile them against your own schedules. This is deliberate, but it surprises teams who expect the model to know their opening hours.
View aggregation differs. In day and week views, the staffing requirement shows the maximum FTE reached in that interval. In month and year views, it is the sum of required hours. Never compare a monthly figure to a daily one and expect them to mean the same thing.

Forecasts can also be adjusted manually for known events — a product launch, a pricing change, a marketing campaign — and those adjustments should be logged, because an unlogged manual override looks exactly like a model failure later.

How to build the report

1. Start with forecast vs actual

The forecast vs actual report compares predicted and actual data across four sections:

Section	What to read
Inbound volume	Forecast against actual arrivals per interval, filterable by workstream.
Staffing	Required FTE, scheduled FTE, and actual attendance, plus the net differences.
Average handle time	Forecast AHT against actual AHT for the interval.
Service level	Tickets that met and missed SLA, and the resulting service level.

Two derived numbers do most of the work:

Required vs actual net — the difference between required FTE and who was actually there. This is your true coverage gap.
Scheduled vs actual net — the difference between the short-term forecast and actual volume.

The report defaults to hourly across all workstreams and can be filtered per workstream. Future dates show forecast only; actuals, AHT, and service level appear once the period has passed. A CSV export is available when you want to do error analysis outside the tool.

One important subtlety: the forecast column reflects historical data generated under the current workstream parameters, while the actual column reflects the workstream as it was configured at the time. If you have recently changed workstream conditions, comparisons across that change are not clean.

2. Turn the comparison into an error metric

“Close enough” is not a metric. Convert each interval into a signed error and an absolute error:

Error = Actual − Forecast. Keeping the sign is essential, because it reveals bias.
Absolute percentage error = |Actual − Forecast| / Actual.
MAPE = the mean of those absolute percentage errors across intervals. Accuracy is 100% minus MAPE.

Report the mean signed error next to MAPE. A team with 12% MAPE and near-zero signed error has a noisy but unbiased forecast. A team with 12% MAPE and a consistently negative signed error is systematically under-forecasting, which is a much more expensive problem because it always shows up as missed service levels rather than idle agents.

3. Always report at interval level

Daily accuracy is the most misleading number in workforce management. A day can be perfectly forecast in total while the morning was under-forecast by 30% and the afternoon over-forecast by the same amount. The queue felt both; the daily number shows neither.

Report per interval, then aggregate the errors, never aggregate the volumes and then compute a single error.

4. Separate the three failure modes

Once you have interval-level error, staffing net, and adherence for the same interval, missed service levels decompose cleanly:

Forecast error	Coverage	Diagnosis
Accurate	Below required	Scheduling or adherence problem — see Zendesk Schedule Adherence Report.
Under-forecast	Met the plan	Forecast problem. The team did everything right.
Accurate	Met required	Handle time or complexity problem — check actual AHT against forecast AHT.
Under-forecast	Below required	Compounding failure. Fix the forecast first; coverage decisions downstream are all built on it.

This table is the reason the report exists. Without it, every bad week produces the same unhelpful conclusion that the team needs to work harder.

How to interpret the patterns

Consistent under-forecasting on one workstream

Usually the workstream’s historical basis is contaminated — a period of suppressed volume from an outage, a backlog cleanup, or a routing change. Re-check the two-year window feeding the model.

Volume forecast is accurate but staffing was still short

Look at AHT. If actual handle time exceeded the assumption, the required FTE was understated even though the volume prediction was right. Complexity drift is the most under-diagnosed staffing problem in support.

Accuracy is fine on weekdays, poor on weekends and holidays

Prophet handles weekly seasonality well and one-off events poorly. Manual adjustments for known events are the fix, and they need to be applied before the schedule is published, not after the miss.

Error grows steadily over the forecast horizon

Normal and expected. Track accuracy separately for short-horizon and long-horizon forecasts; using one target for both makes the near-term forecast look artificially bad.

Forecast accuracy improved but service levels did not

The bottleneck has moved. Check adherence, agent occupancy, and queue routing before touching the forecast again. See Zendesk Omnichannel Routing Queue Report.

Common mistakes

Reporting daily accuracy only. Offsetting interval errors cancel out and the report becomes useless.
Ignoring the sign of the error. Bias is more actionable than magnitude, and it is invisible in MAPE alone.
Comparing across a workstream configuration change. Forecast and actual are computed against different parameter sets on either side of the change.
Forgetting business hours are not applied to required staffing. Reconcile requirements against your schedules yourself.
Mixing day-view and month-view staffing numbers. One is a maximum, the other is a sum.
Building a staffing plan without shrinkage. A perfect forecast still under-staffs if the model assumes every scheduled minute is contact-ready.
Blaming the team before checking the forecast. Half the “performance” problems in support ops are planning problems wearing a performance label.

What to do when accuracy degrades

Confirm it is real: check whether a workstream parameter or routing rule changed inside the comparison window.
Compute signed error by interval to identify direction and shape.
Check whether AHT drifted; a volume-accurate forecast with rising handle time still under-staffs.
Look for structural changes in demand — new channel, new brand, marketing activity, or a shift in channel mix.
Apply manual forecast adjustments for known upcoming events, and log them so future accuracy reviews are interpretable.
Re-measure over four weeks. Forecast quality is a trend, not a single reading.

Where this report fits in your dashboard

Keep it beside:

Together they show what you expected, what arrived, who was there, and what the queue did about it.

FAQ

What is a good forecast accuracy target? For interval-level support forecasting, 80–90% accuracy (10–20% MAPE) is a realistic working range for most teams. Small teams with low volume per interval will always look worse in percentage terms because the denominator is tiny — judge them on absolute contacts, not percentages.

Why can’t I generate a forecast? Zendesk WFM requires at least one month of historical data for the selected date. It also caps the historical window at two years.

Does the forecast respect my business hours? Not for required staffing. Requirements are shown against the historical times volume arrived, so you adjust for opening hours when building the schedule.

How do I forecast a known one-off event? Adjust the forecast manually for that period, and record the adjustment. Statistical models handle recurring seasonality, not novel events.

Should forecast accuracy be a team KPI? Track it as a planning quality metric owned by whoever builds the forecast — never as a support team performance metric. Agents cannot influence it, and attaching it to them removes the only clean way to distinguish planning failures from delivery failures.

See forecast, coverage, and queue outcomes in one Zendesk view - start free