AI Forecasting for Support Volume and Staffing

By Linh Ngo · Updated Oct 11, 2026

Support volume forecasting is the practice of predicting how many customer contacts will arrive in each interval (usually 30 minutes or an hour), then converting that prediction into the number of agents you need on shift to hit a service level target. It's two jobs glued together: a forecast of demand, and a staffing calculation that turns demand into people. AI mostly improves the first job. The second one is still classic queueing math, and it's unforgiving when the forecast is off.

That's the part managers tend to miss. A forecast that's 5% too low doesn't produce a 5% service problem, it can produce a queue that runs away. This guide covers how the staffing math works (Erlang C and its limits), how to measure forecast accuracy honestly, when machine learning beats a simple baseline, and how AI deflection changes both the volume and the mix of what's left. It's part of the AI for Customer Service collection, so the overview of AI in customer service is the place to start for the wider picture.

Key Facts

• The Erlang C model assumes Poisson arrivals, exponential service times, a constant arrival rate within each interval, and that blocking, abandonment and retrials are ignored (Gans, Koole and Mandelbaum).
• The same paper's example: a center planned for 95% utilization whose arrival rate comes in 5% higher sees utilization climb to 99.75%, and waiting times explode or abandonment far exceeds the plan (Gans, Koole and Mandelbaum).
• Contact center shrinkage typically ranges from 25% to 40% of scheduled time, with averages around 30-35% (NICE).
• Forecasting textbook guidance: simple benchmarks such as seasonal naive should be beaten before a fancier method is worth considering (Hyndman and Athanasopoulos, FPP3).
• In a large comparison of statistical and machine learning methods, the machine learning methods were dominated across both accuracy measures and all forecasting horizons examined, and needed far more computation (Makridakis et al., PLOS ONE).

From Forecast to Headcount: What Erlang C Does

Erlang C is the workhorse of contact center staffing. You give it an arrival rate, an average handle time and a target, and it tells you how many agents you need in that interval. Gans, Koole and Mandelbaum's review of the field describes common practice: run the Erlang C model on each half-hour interval, treat each one as a steady state, and use the forecasted arrival rate and service time to get a target staffing level for the period. Those per-interval numbers then feed the scheduling model (Gans, Koole and Mandelbaum).

Four terms do most of the work:

• Traffic (in Erlangs) is the workload. Contacts in the interval times average handle time, divided by the interval length. 120 contacts at 300 seconds each in a 1,800-second half-hour is 120 x 300 / 1,800 = 20 Erlangs. In plain terms, you need 20 agents just to keep pace.
• Service level is the share of contacts answered within a threshold, such as 80% in 20 seconds.
• Occupancy is the share of agent time spent handling contacts. At 25 agents carrying 20 Erlangs, occupancy is 20 / 25 = 80%.
• Shrinkage is the share of paid time agents aren't available: breaks, training, meetings, absence. NICE defines it as hours lost to non-productive activities divided by total scheduled hours, and splits it into internal (planned) and external (unplanned) shrinkage (NICE).

A worked example

Say a queue expects 120 contacts in a half-hour, with a 300-second average handle time, and you want 80% answered within 20 seconds. Using the standard Erlang C formulas, the numbers come out like this:

Twenty-four agents miss the target, twenty-five clear it. Now add shrinkage. With 30% shrinkage, 25 productive agents means 25 / (1 - 0.30) = 35.7, so you'd schedule 36 people for that half-hour.

And here's the forecast risk in the same example. If volume lands 5% higher than planned (126 contacts instead of 120) and you staffed 25, service level drops from 85.0% to about 76.5%. A 5% miss on volume took you below target. At 24 agents, the same 5% miss pushes service level to about 65%. The curve is steep, which is exactly what the Gans paper warns about: because performance is a convex function of the arrival rate, actual performance under an uncertain forecast will typically be worse than the plan, not equal to it (Gans, Koole and Mandelbaum).

Where Erlang C Breaks

Erlang C is a model, and the model has known limits. The review's own list is the one to keep handy: constant rates inside an interval, Poisson arrivals, exponential service times, and blocking, abandonment and retrials ignored (Gans, Koole and Mandelbaum). In practice that means:

• No abandonment. Erlang C pretends every customer waits as long as it takes. Real customers hang up or close the chat. The same review notes that without abandonment, an arrival rate above capacity makes the queue grow without bound, while models that include abandonment stay stable and let you trade capacity against abandonment and delay.
• Known arrival rates. It treats the forecast as the truth. As the paper puts it, the arrival rate is predicted from historical data and isn't known with certainty, and ignoring that can be risky.
• One contact at a time. The classic formula fits single-contact channels like phone. Chat and messaging agents juggle several conversations, and email is asynchronous, so teams usually adjust with a concurrency factor or use different models. Treat the table above as the voice case.
• Identical agents. New hires and veterans don't handle contacts at the same speed, and handle time shifts with the mix of topics.

None of this makes Erlang C useless. It makes it a good first estimate that needs a buffer and a feedback loop. Many teams add a safety margin above the Erlang number, and the best forecasting work focuses on shrinking the uncertainty that margin has to cover.

Measuring Forecast Accuracy

Before comparing any forecast method, agree on the yardstick. Hyndman and Athanasopoulos define the standard measures in Forecasting: Principles and Practice (FPP3):

Two practical consequences. First, MAPE misbehaves on the exact intervals support teams have plenty of: quiet overnight slots with a handful of contacts. Report MAPE on daily or hourly totals, and use MAE or MASE at the half-hour level. Second, FPP3 defines MASE so that a value below 1 means you're beating the benchmark on the training data, and for seasonal series that benchmark is the seasonal naive method (FPP3). That's the number to put in front of your WFM lead: "are we better than last week's pattern repeated?"

Also measure bias, not just error. A forecast that's 8% high one day and 8% low the next has the same MAE as one that's always 8% high, but the second one is a systematic overstaffing problem. Track the signed error as well.

When Machine Learning Beats a Simple Baseline

Start with the baseline. FPP3's seasonal naive method sets each forecast to the last observed value from the same season (this Tuesday at 10:00 looks like last Tuesday at 10:00), and the book's position is that such methods serve as benchmarks, and a new method that can't beat them isn't worth considering (FPP3). For a stable queue with strong weekly rhythm, a seasonal naive or a classical statistical model is often hard to beat. A large study of statistical and machine learning methods found the ML methods dominated on accuracy across horizons, while needing far more computing (Makridakis et al., PLOS ONE). Treat vendor claims of "AI-powered forecasting" with that result in mind.

So where does ML earn its keep? Where the history alone isn't enough, and outside signals explain the swings:

• Known drivers. Product releases, billing runs, marketing sends, outages and price changes create volume that last week's pattern can't predict. ML models can take these as inputs (a calendar of planned events, an incident flag, the number of customers just invoiced).
• Many queues at once. If you forecast by language, tier and channel, a model that learns shared patterns across series can help the thin ones where each series has little history.
• Intraday correction. A model that watches the first hours of today and re-forecasts the rest can catch a spike early. It's an anomaly-detection pattern: ingest a live stream, compare it to a baseline, flag the outlier, and alert a planner.
• Contact reasons. If intent detection tags every contact by reason, you can forecast "invoice dispute" and "password reset" separately, which is far more useful than one total.

A sound way to decide: run the baseline and the ML model side by side on at least a few weeks of held-out data, compare on MASE, and adopt ML only where it wins consistently, not on average. A model that wins on ordinary weeks and loses on the weeks that matter (launches, outages) isn't helping.

How AI Deflection Changes Volume and Mix

Once an AI agent resolves part of your inbound traffic, your history stops describing your future. Two things change.

Volume drops, but not one-for-one. If the AI handles a share of conversations, the human queue sees fewer contacts. But that depends on how you count resolution. Contained isn't the same as resolved, and customers who weren't helped come back through another channel, often as a repeat contact.

The mix gets harder. The easy contacts leave first: password resets, order status, simple how-to questions. What remains is longer, more complex, and more emotional, so average handle time rises. Take the worked example again and suppose AI removes 30% of volume (120 contacts becomes 84) while the remaining contacts take 30% longer (390 seconds instead of 300). Workload is 84 x 390 / 1,800 = 18.2 Erlangs, and the 80/20 target needs 23 agents. That's two fewer than 25, an 8% reduction in agents for a 30% reduction in contacts. With 30% shrinkage that's about 33 scheduled instead of 36.

The takeaway: forecast volume and handle time separately, by contact reason. Retrain or re-baseline after any launch of or change to the AI agent, because the pre-launch history is now a different system. And when agents get tools like AI agent assist that shorten handle time on the contacts that remain, that shows up in AHT, not in volume, so keep tracking it as its own input.

How to Build This, Step by Step

1. Pull clean history. At least a year of contact counts by interval, channel and contact reason, plus handle times. Mark outages, launches and holidays so the model can learn from them. Preparing support data for AI covers the cleanup work.
2. Decide the forecast grain. Daily totals for monthly hiring, hourly or half-hourly for scheduling. Don't use one model for both.
3. Set a baseline. Seasonal naive on each queue. Record its MAE and MASE. That's the number to beat.
4. Add drivers. Introduce planned events, billing calendars and incident flags. Try a statistical model with external regressors before a heavier ML model.
5. Backtest. Compare methods on held-out weeks, including at least one launch or outage week. Choose per queue, not globally.
6. Convert to staffing. Run Erlang C (or a simulation tool if you need abandonment and multi-contact handling) per interval, then divide by (1 - shrinkage) for scheduled headcount.
7. Add a buffer and an intraday loop. Staff slightly above the Erlang number at peaks, and give planners an alert when actual volume runs well above forecast so they can move people, offer overtime, or shift work to async channels.
8. Review monthly. Track MASE, bias, and service level hit rate by queue. Re-baseline whenever the AI agent's scope changes.

Pitfalls to Avoid

Using MAPE alone. It hides bias and breaks on low-volume intervals. Pair it with MAE, MASE and signed error.

Forecasting total contacts only. A flat total hides the mix shift. Forecast by contact reason and channel.

Trusting the Erlang number as exact. It's an estimate built on assumptions that real queues violate. Keep a buffer and watch abandonment.

Staffing to the daily average. Service level is made or lost in the peak intervals. Plan interval by interval.

Ignoring shrinkage drift. Training weeks, flu season and new-hire ramps change shrinkage. A fixed 30% in the model is a guess.

Skipping the baseline. If you can't show that the AI forecast beats seasonal naive, you're paying for complexity. Use the automate or assist decision to scope where AI deflection applies before you cut headcount plans around it.