Every contact operation is sized on a number somebody estimated: how much work is going to arrive. Out of that number come the shift roster, the hiring plan, the training calendar and the service level promise. And it is, almost always, the least discussed item in an outsourcing negotiation. The rate gets reviewed, the SLA gets reviewed, the quality rubric gets reviewed. The forecast arrives as an annex in a spreadsheet nobody questions.
When it fails, the symptom does not look like a forecasting problem. It looks like a long queue on Tuesday afternoons, a missed SLA during billing week, or a group of new agents hitting the floor just after the peak has passed. The cause sits three steps back.
What exactly gets forecast
A monthly number schedules nobody. The useful unit is the interval: half an hour or an hour, by day, by channel and by queue. That is the granularity a shift is built on, and the only one that shows the problem is not the month's volume but its shape inside the day. The full logic is in how to size a support operation.
Beyond volume, handle time has to be forecast too. The same number of contacts with longer cases needs more people, and handle time moves when the product changes, when new agents come in, or when a flow is modified. Forecasting volume while treating handle time as a constant is a quiet mistake: the model looks right and the operation comes up short.
Back office works on a different unit. There is no real-time queue, there is inventory: what arrives, what is still pending and how old it is. A back office forecast that only looks at arrivals ignores half the problem.
The history that helps and the history that lies
You need at least one full seasonal cycle. If the business has a high season, that means a year; with three months of data you cannot tell a trend from an event.
But the most common trap is not the length of the history: it is confusing demand with what was served. Whatever was recorded as handled is capped by the capacity available that day. Abandoned calls, the same customer trying again, emails answered two days late and chats nobody picked up do not show up as unmet demand; they show up as if they never existed. A history built on an understaffed operation reproduces that scarcity going forward and turns it into the norm.
The history also needs annotations. An unexplained spike gets repeated by the model next year as if it were seasonality. It is worth having someone write down what happened on the strange days: a system outage, a campaign, a mass billing error, a press mention.
Three layers worth separating
- Trend. Where the business is going. The customer base grows, the product mix changes, a new channel opens.
- Seasonality. It repeats on three scales: the year, the week and the day. All three stack, and the intraday one drives scheduling.
- Events. What does not repeat and cannot be inferred from the data: a launch, a migration, a price change, a campaign.
The first two are estimated from history. The third is not: it is asked for. No model anticipates a campaign nobody mentioned, and that is the most common source of large misses.
The calendar almost nobody hands over
The cheapest thing a client can do to improve their provider's forecast is hand over a calendar of known events in advance. Billing dates, launches, platform migrations, policy changes, marketing campaigns, promotions. That calendar costs one meeting a month and removes most of the surprises.
Public holidays deserve separate attention in a nearshore operation. The Colombian calendar does not line up with the US or European one. A local holiday cuts available staff while client demand carries on untouched, and a holiday in the client's country does the opposite. Both are planned for; neither is improvised.
How to tell whether the forecast is any good
There are two different questions: how far off it was, and in which direction. Absolute error gives the distance. Bias tells you whether the model always misses the same way.
The second one matters more. A forecast with high error and no bias forces you to carry a buffer, and that costs money. A forecast with a systematic downward bias produces chronic misses, burnt-out agents and a monthly argument about penalties that is really an argument about a badly calibrated model.
Error has to be measured at the level it is used. A monthly forecast can look near perfect while every interval is wrong, because the morning misses cancel out the afternoon ones. And one thing is worth remembering before demanding precision: the smaller the volume, the larger the relative error. A small queue will always show a higher error percentage than a large one. That is arithmetic, not carelessness.
An SLA that does not say what happens when volume falls outside the forecast is not a service agreement: it is a bet on the forecast.
Who owns the forecast
There are three possible arrangements and none of them is wrong: the client supplies the forecast, the provider builds it, or both agree on it with a joint review. What is a problem is a contract that does not say which of the three applies.
If the client supplies the forecast, the provider answers for serving what was forecast and not for whatever turns up. If the provider builds it, the provider answers for the estimate as well. Either way it pays to write down how far in advance it is delivered, at what granularity, what tolerance band is accepted and what happens when actual volume leaves that band: whether the service level is renegotiated, whether a surge mechanism kicks in, or whether the cause is simply documented. That discussion belongs to contract governance and gets settled before you need it.
Three horizons, three decisions
The long forecast, several months out, exists for hiring and training. Its lead time is set by the ramp: recruitment has to start as far ahead as it takes a new agent to reach full productivity, which is covered in how long a new agent takes. The weekly forecast exists to build rosters and place holidays, training and meetings. The intraday one exists to react: move breaks, open or close queues, shift priorities. Confusing them leads to expensive decisions, like trying to hire your way out of a scheduling problem.
None of the three converts into headcount directly. Between the forecast and the payroll sits shrinkage, and a flawless forecast sized without it still comes up short.
What to do when it misses
A large miss deserves a short review with a single question: did the model get it wrong, was there an event nobody told us about, or did the business change? The three causes have different fixes. The first is corrected by recalibrating. The second is corrected with the event calendar. The third is not corrected at all: it is absorbed, because it means the baseline moved.
To tell them apart, look at what the extra volume is made of. If it is the usual reasons in greater quantity, the business probably grew. If a new reason appears concentrated in a few days, there was an event. That reading depends on having a clean catalogue, which is the argument in disposition codes. And if the deviation is seasonal and predictable, it is no longer a forecasting problem but a capacity one: that is handled in seasonal peaks.
How smartBPO works it
We ask for history by interval and by channel, not monthly totals, and we ask about the strange days before using them. We separate demand from what was served whenever the data allows, so we don't inherit the scarcity of an operation that was already short. We write into the contract who supplies the forecast, how far in advance and within what tolerance. We measure error at interval level and watch the bias, not just the distance. And we bring the client's event calendar into the monthly operations meeting, because most large deviations are not model errors: they are things somebody knew and nobody said in time.