Almost every outsourcing conversation starts with the rate and ends with the SLA. In between sits the decision that holds both up: how many people the operation needs, and when. Bad sizing is the silent cause of a good share of the problems later blamed on "bad attitude" or "lack of commitment". It rarely is that. It is usually arithmetic done by gut instead of by data.
Sizing is not setting a headcount for the month. It is estimating how many agents are needed in each slot of the day to handle demand at the promised quality, without paying for hours nobody uses. It is the hinge between cost and service: tighten one side and the other loosens.
The daily average is the worst starting point
The most common mistake is to take the month's total volume, divide it by the days and by the working hours, and staff for that average. The problem is that nobody writes in or calls "on average". Demand arrives in waves: a mid-morning peak, a lunchtime lull, another peak at the end of the afternoon. An operation sized for the average is overstaffed in the lulls and overwhelmed in the peaks, which is exactly when the client is watching.
The right starting point is not a number, it is a curve: how much volume comes in during each slot —half-hour or hour— across the week. That curve rules. Everything else is an assumption built on top of it.
The four things you need before calculating anything
Without these four inputs, any agent count is a guess in spreadsheet clothing.
1. Volume by slot
Not the monthly total: the distribution. How many contacts arrive in each time block, and how that shape changes between a Monday and a Saturday. Two operations with the same monthly volume can need very different staffing if one spreads it evenly and the other packs it into three hours.
2. Handle time
How long it takes on average to resolve a contact, including the work after it closes. It is the multiplier that turns volume into workload. A thirty-second error in the handle-time estimate, multiplied across thousands of contacts, changes the agent count entirely.
3. Target service level
How fast you promise to respond. This is not something you calculate: it is a business decision, and an expensive one. Answering 90% of contacts in twenty seconds costs considerably more than answering them in forty, and that difference is not linear. The service level has to be set before sizing, because it defines how much reserve capacity you pay for.
4. Real unproductive time (shrinkage)
A full-time agent is not available for every one of their hours. There is training, breaks, meetings, absences, systems going down. That unproductive time —shrinkage— is real and has to be measured, not assumed. Sizing on theoretical hours instead of effective hours is the fastest way to fall short every day without understanding why.
Volume to agents is not a simple ratio
Intuitively you think twice the volume needs twice the agents. It does not, and that is the part that breaks the most budgets. The relationship between volume, handle time and agents is not linear: it is described by queueing formulas like Erlang C, precisely because waiting time spikes disproportionately as occupancy approaches its limit.
The practical consequence is counterintuitive: a small operation suffers peaks more than a large one. Five agents cannot absorb a wave that fifty barely notice, because the buffer to cushion it is proportionally smaller. That is why "add two people" does not always cut it, and "drop one to save money" sometimes breaks the whole service. The size of the operation changes the rules.
Occupancy: the number nobody wants to look at
Occupancy is the percentage of time an agent is actually handling work. It sounds reasonable to push it as high as possible —that is what you are paying for— but occupancy that is too high is a trap. A team working at the limit all day has no slack to absorb a peak, burns out and turns over, and turnover resets the whole learning curve. Sizing for maximum occupancy saves money on paper and costs a lot in practice. Reserve capacity is not fat: it is what lets you meet the service level on the day demand misbehaves.
Chat and asynchronous channels change the formula
Everything above assumes one contact per agent at a time, like a phone call. Chat breaks that assumption: an agent handles several conversations in parallel, and the calculation has to build in that concurrency, which is not infinite, because quality drops when someone is carrying too many chats at once. Email and tickets are another story: they are asynchronous, they can be deferred and batched, so they are sized more like a workload per shift than a real-time queue. Putting all three channels into the same formula is a common error that inflates or deflates staffing depending on which one dominates.
Sizing is a hypothesis, not a constant
The best sizing model is a hypothesis with an expiry date. Demand changes: there is seasonality, campaigns, launches, odd months. A number calculated once and never revisited stops describing the operation within a few months. That is why sizing gets measured again against what actually happened, and that comparison is part of what to measure in a BPO operation from month one.
It is also why a serious SLA is agreed after sizing and not before: the committed number has to come from a staffing plan that exists, not from a wish. Promising a service level without having sized the operation is signing a cheque without looking at the account (how to write an SLA you can meet).
Where smartBPO fits
We start from the real demand curve before proposing any staffing, not from an average or from the headcount usually put on similar operations. We measure handle time and unproductive time with data, we leave reserve capacity so the service level holds through the peaks, and we treat sizing as something adjusted when demand changes, not as a fixed number in the contract. We do not promise the cheapest possible staffing; we propose the one that sustains the service that was agreed, which is almost never the same thing.