Forecast volume and handle time
Build interval forecasts from historical demand, expected changes, and operational assumptions.
QueuePilot beta access
QueuePilot turns demand signals into staffing plans, forecast confidence, and operational recommendations.
Build interval forecasts from historical demand, expected changes, and operational assumptions.
Translate demand into agent needs while accounting for shrinkage, occupancy, and service goals.
Make every forecast easier to review, challenge, and defend with leadership.
In most contact centers the forecast lives in a workbook somebody built years ago. It has a tab per queue, formulas that reference formulas that reference a sheet named DO NOT TOUCH, and exactly one person who understands why week 27 is multiplied by 1.06. When volume misses, nobody can say whether the model was wrong, the inputs were stale, or someone fat-fingered a cell. When that one analyst resigns, the operation loses its forecasting capability with two weeks of notice.
The other common starting point is a black-box forecast inside a larger suite: a number appears, it is sometimes badly wrong, and nobody can explain why or adjust the assumptions behind it. Workforce communities are full of planners complaining that their tool’s staffing plan does not follow any recognizable Erlang logic and that they have quietly gone back to Excel to check it. Both failure modes share a root cause: the forecast is not explainable, so it is not trusted, so it is not really used.
A forecast you can defend in a leadership meeting has four properties. It is interval-level, because daily totals hide the 10:00 AM peak that actually breaks service level. It forecasts both volume and AHT, because handle time drifts with product changes and seasonality, and staffing requirements move with the product of the two. It carries confidence ranges, a forecast of 400 contacts plus or minus 30 is actionable in a way that a bare 400 is not, because the staffing plan can cover the realistic upside. And it is honest about data quality: a queue with six weeks of clean history deserves a different confidence than one with two years.
From there, the staffing translation has to be visible: traffic intensity from volume times AHT, an Erlang C or workload-based requirement to hit the service target, an occupancy cap so the plan does not assume superhuman agents, and a shrinkage gross-up to get from productive bodies to scheduled bodies. If you cannot trace the path from forecasted contacts to scheduled agents, you cannot defend the headcount it implies.
The Forecast Lab builds interval forecasts from your queue history using day-of-week and time-of-day patterns, flags the intervals where history is thin or contaminated, and shows confidence ranges on every number. Assumptions are first-class objects: shrinkage, occupancy targets, and service level goals are visible, editable, and versioned, so what happens at 25 percent shrinkage instead of 30 is a click, not a workbook rebuild. The output is a staffing requirement per interval that an analyst can trace, challenge, and re-run.
Because forecasting lives in the same product as coverage and intraday, the forecast is not a Monday artifact. Actuals stream in against it all day, accuracy is tracked over time per queue and interval, and the Intraday Copilot uses the variance to recommend corrections. The forecast becomes a living baseline rather than a weekly PDF.
Measure accuracy at the interval level with a metric like weighted absolute percentage error, and separate volume error from AHT error, they have different causes and different fixes. Investigate misses by category: marketing launches and billing cycles are forecastable if the business tells you about them, so the fix is a calendar feed, not a better algorithm. Outages and viral moments are not forecastable, so the fix is intraday response, not forecast flagellation.
Keep a clean event log: every promotion, price change, outage, and policy change, with dates. Most forecast accuracy gains come from labeling history correctly so the model stops learning from contaminated weeks. And re-forecast at a fixed cadence, weekly for the planning horizon, continuously intraday, rather than only when something breaks. If you want the math itself, our Erlang C explainer on the blog walks through the formula every requirement calculation rests on.
Most start from historical interval data and decompose it into day-of-week, time-of-day, and seasonal patterns, then adjust for known events like marketing campaigns and billing cycles. The forecast is produced per queue and per 15 or 30-minute interval, then converted into staffing requirements with Erlang C or workload math.
It depends on volume and interval size, but many teams aim for interval-level error inside 10 to 15 percent on established queues, with daily totals considerably tighter. The more useful habit is tracking your own error by queue and interval over time and separating volume error from AHT error, rather than chasing a universal benchmark.
Erlang C is the queueing formula that converts traffic intensity, volume times AHT, into the number of agents needed to hit a service level target like 80/20. You need it, or its workload-method approximation, any time you turn a volume forecast into a staffing requirement. Our free Erlang C calculator runs the formula for you.
Eight to twelve clean weeks per queue gives a workable day-of-week and time-of-day pattern; a full year captures seasonality. Less history means wider confidence ranges, not no forecast, which is why forecasts should carry data quality warnings instead of presenting thin-history numbers with false confidence.
Interval level, always, for staffing purposes. Two days with identical totals can need materially different schedules if one peaks hard at 10:00 AM. Daily forecasts are fine for capacity planning and budgets, but coverage decisions live and die in 15 and 30-minute intervals.
Built for WFM analysts, supervisors, operations managers, and contact center leaders who need to catch staffing issues before customers call in.
QueuePilot is in paid beta with NICE CXone as the first-class integration. Beta teams onboard directly with the people building the product, start in demo mode against realistic simulated data before connecting anything, and get a real vote on what ships next.