The price of an outsourced operation almost never comes down to a single figure. It comes down to a model: the rule that defines what you pay for, when it goes up, and who carries the risk when volume doesn't turn out as expected. Two providers can land at a similar monthly cost with different models, and that difference —not the rate— is what you feel the day the business changes.
Comparing only the big number is the most common mistake when evaluating a quote. The pricing model decides things the number doesn't show: what happens in a demand spike, who pays for idle time in a slow season, whether the provider earns more by working more or by resolving better. Understanding the models before signing keeps you from discovering those answers when they already cost dearly.
Three ways to charge, three ways to split the risk
Almost every BPO pricing scheme is a variant of three ideas. You pay for what goes in —the team's time—, for what comes out —resolved transactions—, or for what gets achieved —a business outcome. Each one moves the risk to a different side of the table. None is better in the abstract; one fits how predictable your volume is and how well you can measure the work.
Per hour or per FTE: you pay for capacity
This is the most common model and the easiest to understand. You pay for an agent's time —per hour worked or per full-time equivalent per month, the FTE— regardless of how many cases they resolve. You buy capacity, not output.
It fits when the work is variable, hard to standardize, or not yet well measured. If every case is different and there's no clear unit to count, paying for time is honest for both sides. It also works at the launch of a new operation, when nobody yet knows how many transactions fit into an hour.
You carry the risk. If the team works slowly, you pay all the same. If there are extra people in a slow season, you pay all the same. That's why this model demands measuring productivity from day one: without occupancy and cases-per-hour metrics, paying for time turns into paying for presence. It helps to be clear on what to measure in the first month so the capacity you buy translates into real work.
Per transaction: you pay for output
Here you pay per resolved unit: a closed ticket, a processed invoice, a handled call, a managed case. The provider takes on the productivity risk: if its team is slow, it earns less; if it's efficient, it earns more. For you, the cost becomes predictable per unit and scales with real volume.
It works when the work is repeatable and the unit can be defined without argument. That's the delicate point: a poorly defined transaction becomes a monthly fight. You have to agree what counts as a unit, what happens with rework, and how you pay for a case that comes in but can't be resolved for reasons outside the provider. If the definition isn't clean, the per-transaction model ends up costing more in friction than it saves in rate.
Quality also needs watching. When you pay for resolved volume, the incentive pushes toward closing fast. Without an independent check, the model can reward closing over resolving. That's why per-transaction pricing almost always comes paired with quality control by audited sampling to balance the incentive.
Per outcome: you pay for the result
This is the most ambitious model and the least common. Payment is tied to a business result: a resolution rate, a satisfaction level, a recovery target in collections. In theory it aligns the provider with what actually matters. In practice, it only works when the result clearly depends on the provider's work and not on factors it doesn't control.
That's the limit. Tying payment to a result the provider doesn't fully govern —because it depends on the product, the price, the market, or a team on the client's side— creates disputes over what caused what. The outcome model demands clean data, an agreed baseline, and maturity on both sides. It usually comes later, when the relationship already has history and trust, not in the first contract.
What slips in between the lines
Any of the three models carries components that don't appear in the headline rate and are worth facing head-on:
- Transition or setup cost. Standing the operation up —training, documentation, ramp— is often billed separately. That's legitimate; what isn't ideal is having it arrive as a surprise.
- Peaks and seasonality. Ask how extra capacity is paid for in high season and what happens to idle time in the low one. An hourly model with no peak rules gets expensive right when you need it most.
- Minimums and lock-in. Guaranteed minimum volumes, tenure clauses, and exit penalties change the real cost more than the unit rate does.
- What it doesn't include. Overtime, holidays, rework, custom reporting. What isn't listed tends to get billed later.
How to choose
The question isn't which model is cheaper, but how predictable and measurable your work is. If volume is stable and the unit is clear, per-transaction pricing aligns incentives. If the work is variable or new, paying for time is more honest while it stabilizes. Outcome pricing is earned over time, not signed up front.
Whatever the model, price and service level have to move together. A low rate with an SLA you can't meet isn't a saving, it's a deferred problem. And a good pricing model reads better with the rest of the quote in front of you: that's why it helps to know how to read a BPO quote before comparing numbers.
Where smartBPO fits
When we put a proposal together, we first look at how predictable and measurable the work is, and the model follows from that, not the other way around. We explain what each side carries under each scheme, what the rate includes, and what's billed separately, leaving no surprises for month three. If volume isn't clear yet, we'd rather start on time and move to per transaction once the unit can be counted without argument. We don't promise the lowest number on the table; we prefer the model that holds when your operation changes, which is when a model really gets tested.