Call center workforce management is the cycle that turns a volume forecast into a roster: predict how many contacts arrive in each interval, calculate how many people have to be available to answer them at your service level, build schedules that put those people in those intervals, then correct the plan during the day as reality diverges from the forecast. Those four steps repeat every week.
The cycle holds up until something changes the call mix. Then the arithmetic quietly breaks, because the obvious move is to scale the plan down by the share of calls that went away, and that is the wrong operation. The staffing math below shows what a call type really costs you, and the worksheet at the end rebuilds the forecast properly when an AI agent takes that call type off the queue.
What is call center workforce management?
Call center workforce management is the planning process that decides how many agents are on the phones in each interval. It forecasts contact volume and handle time, converts that into a required agent count with a queueing model, turns the requirement into shifts, and adjusts in real time. Vendors sell software for it; the arithmetic is the same either way.
The process is a hierarchy, and it runs from the bottom up. Queueing models decide how many agents must be available in a given half hour or hour, scheduling models decide when during the week or month each agent works, and hiring models decide how many people to recruit and train each month or quarter (Gans, Koole and Mandelbaum, Telephone Call Centers: Tutorial, Review, and Research Prospects, Manufacturing and Service Operations Management 5(2), 2003).
The four steps and what each one decides
| Step | Horizon | The question it answers | What it produces |
|---|---|---|---|
| Forecast | Months down to 30-minute intervals | How many contacts arrive, and how long will each take | A volume and handle time number per interval |
| Staffing | One interval at a time | How many agents must be available to hit the service level | Agents on the phones, then agents on the schedule after shrinkage |
| Scheduling | A week or two | Who works which shift, with breaks, training and time off | A roster |
| Intraday | The day itself | Is the forecast holding, and where do people move | Redeployments, overtime, voluntary time off |
The cycle is continuous rather than a once-a-quarter exercise. A planner prepares a forecast every week or few weeks, determines the required agent count, and builds a roster with input on days off and meetings. Forecasts keep getting updated and the roster keeps changing until the scheduled day itself, when a supervisor watches abandonment and waiting times and redeploys people in real time, feeding the day's data back into the next forecast (Gans, Koole and Mandelbaum, 2003).
Step two is where a change in the call mix does its damage, so that is where the rest of the arithmetic goes.
Why the roster does not shrink as fast as the call volume
Staffing is not proportional to volume. The required agent count is the offered load plus a buffer, and the buffer grows with the square root of the load rather than with the load itself. The standard form is N = R + β√R, where R is the offered load in erlangs and β sets how much protection you are buying against random arrivals (Gans, Koole and Mandelbaum, 2003).
This is not a recent finding. Erlang described the square root relationship in 1924 and reported that square root rules had been in use at the Copenhagen Telephone Company since 1913. Borst, Mandelbaum and Reiman later proved the principle is asymptotically optimal for large loaded systems, and testing across traffic regimes found it rarely deviates by more than a single agent from the exactly optimal staffing level (Gans, Koole and Mandelbaum, 2003).
Work through one interval. The figures below are inputs chosen to show the arithmetic, not benchmarks and not Telvana results. You can change any of them in the Erlang C calculator for call center staffing, which runs the same math.
A queue takes 200 calls in its busiest hour at an average handle time of 240 seconds, and the target is answering 80 percent of calls within 20 seconds. Offered load is 200 times 240 divided by 3600, or 13.3 erlangs. Meeting the target takes 17 agents on the phones. The buffer is 17 minus 13.3, which is 3.7, and the square root of 13.3 is 3.65. The rule holds almost exactly.
Now drop the volume to 160 calls an hour and hold handle time. Offered load falls to 10.7 erlangs, a drop of 20 percent. Required agents fall to 14, a drop of 18 percent. The buffer barely moves, from 3.7 to 3.3, because the square root of a smaller number is not much smaller.
That gap is why a plan scaled down by a flat percentage is always optimistic. It is also the smaller of the two errors.
What automating a call type does to the plan
The bigger error is the call mix. When a specific call type stops arriving, two things change at once: fewer calls arrive, and the calls that remain are no longer the same calls.
This was described precisely in the context of phone-menu self-service, and it applies identically to an AI agent that resolves a call type end to end. The fraction of customers who self-serve causes arrival rates to decline, and "the elimination of these calls from the original mix causes the average service time to change as well." Both changes then flow through the staffing models before any headcount reduction can be estimated (Gans, Koole and Mandelbaum, 2003).
In practice the second change gets skipped, for a mundane reason. Half-hourly records of average service time could be used to forecast handle time in detail, but "many call centers do not forecast service times or other parameters in detail. Instead, grand averages for historical service rates, productivity rates, and turnover rates are calculated" (Gans, Koole and Mandelbaum, 2003). A planner working from a grand average has no way to see that the average just moved, because the call type that left is invisible inside it.
Take the same hour as before: 200 calls at a 240 second blended average. An AI agent takes a short call type end to end: 20 percent of the calls, each averaging 120 seconds. Total handle work in the hour is 48,000 seconds. The automated calls were 40 times 120, or 4,800 seconds. The 160 calls left therefore carry 43,200 seconds between them, which is an average of 270 seconds each, not 240.
| Share of calls automated | Calls left | Handle time of what is left | Roster if handle time is held flat | Roster after the mix correction | Agents short |
|---|---|---|---|---|---|
| 10 percent | 180 | 253 seconds | 23 | 25 | 2 |
| 20 percent | 160 | 270 seconds | 20 | 23 | 3 |
| 30 percent | 140 | 291 seconds | 19 | 22 | 3 |
| 40 percent | 120 | 320 seconds | 16 | 22 | 6 |
Rosters include 30 percent shrinkage at a maximum occupancy of 85 percent. The baseline roster before any automation is 25.
Read the 20 percent row. A planner who removes a fifth of the calls and leaves handle time alone schedules 20 agents. The hour actually needs 23. Three agents short on a roster of 23 is a 13 percent staffing miss, and it lands on exactly the intervals the automation was supposed to relieve.
The 10 percent row is the uncomfortable one. Automating a tenth of the calls, when those are the shortest calls, reduces the roster by nothing at all. The work that left was 5 percent of the load, and the square root buffer absorbed the rest.
Pick the call type by load, not by call count
A call type's claim on your staffing is its share of handle time, not its share of calls. Multiply volume by average handle time and divide by the total, and you get the share of offered load that call type represents. That is the number automation removes.
Same hour, same 20 percent of calls automated, three different call types:
| Call type automated | Its handle time | Share of calls | Share of load | Handle time of what is left | Roster after | Roster cut |
|---|---|---|---|---|---|---|
| Short | 120 seconds | 20 percent | 10 percent | 270 seconds | 23 | 2 of 25 |
| Average | 240 seconds | 20 percent | 20 percent | 240 seconds | 20 | 5 of 25 |
| Long | 400 seconds | 20 percent | 33 percent | 200 seconds | 18 | 7 of 25 |
The call counts are identical and the roster cuts are two, five and seven. The difference is entirely handle time, which a plan built on call counts cannot see.
This cuts against how most programs get sequenced. The shortest, most repetitive call types are usually the easiest to automate well and the safest to start with, which is the right call for a first deployment even though the staffing payoff is small. The payoff arrives when you work up to call types that carry real load. Sequence the program that way deliberately instead of being surprised by a flat roster after the first launch.
Two cautions before you treat any of this as a budget. The handle time of an automated call type is rarely a clean average, because an AI agent that transfers a caller to your team has still spent some of your agents' time on the back end of that call, and a cold transfer hands the caller to a person who starts the conversation over. Count partially handled calls at their human handle time, not at zero. And occupancy ceilings bind: when offered load drops far enough, the binding constraint on the agent count stops being the service level and becomes the maximum occupancy you are willing to run, which is why the roster in the table above stops falling between 30 and 40 percent.
Choosing the occupancy ceiling the worksheet needs
The occupancy ceiling is the highest share of time you will let an agent spend on calls, and it caps the agent count independently of the service level. Pick it from the regime you are actually running rather than from a default, because the operating regimes described in the literature sit a long way apart.
A quality-driven center runs around 65 percent utilization and answers almost everyone immediately. An efficiency-driven center with similar offered work runs close to 100 percent utilization, and essentially every caller is delayed. Large well-run centers sit in neither: in a set of 12 call centers at a United States health insurer, agents were 91 percent utilized while only about 40 percent of callers were delayed at all (Koole and Mandelbaum, Queueing Models of Call Centers: An Introduction, Annals of Operations Research 113, 2002).
Scale is what makes that middle position possible, so a small queue cannot borrow a large center's ceiling. If you run one queue of a dozen people, the ceiling that protects your service level in a bad interval is lower than the one a 300 seat operation can hold. Set it once from your own worst intervals, write down why, and keep it fixed while you evaluate automation, otherwise you cannot tell a staffing change from a policy change. The occupancy entry in our metrics guide covers how the number misleads when it is read across a whole shift instead of per interval.
The deflection-adjusted staffing worksheet
Run this per interval, per queue, before a program launches and again 30 days after it is live. It replaces the one-step shortcut of multiplying the roster by one minus the automation rate.
- Pull volume and handle time by call reason rather than in aggregate. You need calls offered and average handle time for each reason code in each 30-minute interval. If your reporting only produces a center-wide average, this worksheet cannot run, and fixing the reporting is the first task.
- Calculate load per call reason. Calls offered times average handle time, divided by 3600, gives erlangs. Rank the reasons by load rather than by volume. The ranking usually differs.
- Name the call reasons the agent will resolve end to end. Only the reasons it finishes count here. A reason it partly handles before transferring goes in step 4 instead.
- Split the partly handled reasons. Estimate the share that transfers and keep that share at its full human handle time. Treat the estimate as provisional until you have 30 days of real outcomes.
- Recalculate the remaining volume and the remaining blended handle time. Subtract the automated calls from the call count, subtract their handle seconds from the total handle seconds, then divide what is left by what is left. This is the step that gets skipped.
- Rerun the staffing model with both new numbers, not the volume alone. Apply your shrinkage and occupancy ceiling to get the scheduled count, and check whether occupancy has become the binding constraint.
- Rebuild the schedule from the new interval requirements, then compare. The honest saving is the difference in scheduled agent hours across the week, not the difference in a single peak hour. Automation tends to flatten the peak, which changes shift shapes more than it changes totals.
The output is a per-interval requirement you can defend line by line. Keep the pre-launch version; 30 days of real outcome data will contradict part of your step 4 estimate, and you will want the baseline to compare against.
What to recheck, and how often
| What | How often | What triggers an off-cycle review |
|---|---|---|
| Volume forecast by interval | Weekly | A marketing campaign, an outage, a billing cycle change |
| Handle time by call reason | Monthly | Any automation launch, a script change, a new product |
| Shrinkage | Quarterly | A training push, a seasonal absence pattern, attrition |
| Service level target and the interval it is measured over | Twice a year | A contract change, a client SLA |
| Automation resolution rates by call reason | Monthly for the first quarter, then quarterly | A knowledge base update, a transfer rate that moves |
Handle time is the row that moves most, and the easiest one to leave untouched for a quarter. Read it per call reason rather than center-wide, because a center-wide average that holds steady can hide two call reasons moving in opposite directions.
Where the plan breaks after it is built
Everything above treats the forecast as a number. It is a distribution, and a staffing model fed the average of a distribution does not deliver the average of the performance.
The relationship between arrival rate and service is convex, so the plan's predicted performance is systematically better than what the center will actually experience. The standard approach staffs for the expected arrival rate, but because performance is a nonlinear function of that rate, "actual performance will not match that of the plan and typically will be worse" (Gans, Koole and Mandelbaum, 2003).
The same trap catches anyone who collapses a day into one average. Feeding a model the average arrival rate instead of interval by interval figures "can give extremely bad results, even if the occupancy is constant" (Koole and Mandelbaum, 2002). Run the arithmetic per interval or it will quietly flatter every peak you have.
The failure gets sharper the leaner you run. A center planned at 95 percent utilization that receives 5 percent more calls than forecast either climbs to 99.75 percent utilization, where waiting times explode, or sheds the difference through abandonment far above what anyone planned for (Gans, Koole and Mandelbaum, 2003). That is the real argument for carrying an occupancy ceiling in the model. Whatever it does for agent welfare, it is buying you insurance against a forecast that comes in high.
This is also where automation genuinely helps in a way the roster arithmetic understates. An AI agent that answers immediately has no queue to overflow, so the call types it covers stop contributing to the convexity. The buffer you need is protection against variability in the volume that still reaches people, and a smaller pool of call reasons is a less volatile one. Measure that effect with the share of callers who waited at all and the abandonment rate rather than with service level, which compresses the distribution you are trying to watch.
Frequently asked questions
What is the difference between workforce management and workforce optimization?
Workforce management is forecasting, staffing, scheduling and intraday management: getting the right number of people in the right intervals. Workforce optimization is the broader bundle vendors sell around it, usually adding quality monitoring, recording, coaching and analytics. The planning math discussed here sits in the workforce management half.
Do we need workforce management software?
Below roughly 20 agents on a single queue, a spreadsheet running Erlang C and a shrinkage factor covers the arithmetic. Software earns its cost when you have multiple skills, several sites or clients, shift bidding, or enough intervals that manual scheduling takes a person a full day a week. The output is the same; what you are buying is the time.
How do you calculate shrinkage?
Divide paid hours when agents could not take contacts by total paid hours, counting breaks, training, meetings, coaching, system downtime and absence. Then scheduled agents equals required agents on the phones divided by one minus shrinkage. At 30 percent shrinkage, 17 agents on the phones needs 25 on the schedule. Shrinkage is not changed by automating call types, so it applies to the corrected requirement, not the original one.
Does automation change our shrinkage or our occupancy ceiling?
Shrinkage does not change, but the occupancy ceiling effectively does. Removing a call type lowers offered load, and at low enough load the service level is satisfied by so few agents that the occupancy ceiling becomes the binding constraint instead. When that happens, further automation stops reducing the roster until you change the ceiling or consolidate queues.
How far ahead should the forecast go?
The forecast has to reach far enough ahead to hire against. Recruiting and training lead time sets the horizon for the hiring layer, usually a quarter or more, while the scheduling layer works a week or two out and the intraday layer works in half-hour intervals. Teams that forecast only to the schedule horizon find themselves solving a hiring problem with overtime.
Where to start
Pick your highest-load call reason, not your highest-volume one, and run the worksheet above on it. If the answer is that the reason is worth automating, the next question is who takes it, which comes down to cost and control between outsourcing and AI agents, and then to which calls an AI agent can actually finish. For the numbers you will be measuring the change against, our metrics and operations guides cover the rest of the dashboard.
Telvana builds AI agents that answer calls, texts and web chats for contact centers, and transfers to your team under rules you set. Plans start from $399 a month based on call volume, plus a one-time setup fee. Book a demo with your top call reasons and their handle times, and you will see which ones an agent can take and hear it handle one.