The question almost always shows up in the second meeting: will the team work only for us? It's a good question and it rarely gets a good answer, because it gets framed as a matter of status — who deserves people of their own — when it's actually an operational design decision with measurable consequences.
Dedicated means the assigned people work on one account only. Shared means a group covers several accounts and splits its time according to the day's demand. Both models are legitimate. Getting it wrong costs money on one side or costs quality on the other.
What a dedicated team buys
First and most important: depth of judgment. Someone who sees the same process every day accumulates it — they recognize the rare exception, they know when the manual doesn't apply, they understand the business behind the case. That judgment doesn't transfer in a training session; it gets built through repetition.
Second: predictable capacity. If the operation has four dedicated people, four people are available at the agreed hour, without another account's priority getting in the way. When response-time commitments are tight, that matters more than it looks.
Third, and less discussed: access control. If the process touches sensitive data, a closed, named group is far easier to audit than a rotating pool. Reducing the number of people with access is a control measure, not a preference.
The cost of all that is simple: you pay for the full capacity whether it's busy or not. A dedicated team running at low occupancy is the quietest way to overpay.
What a shared team buys
Variable cost. If the volume doesn't fill a shift, sharing is the only way to avoid paying for empty hours. It's the reason many small operations are only viable in this model.
Absorption of small peaks. A Tuesday with double the cases doesn't break anything, because more people are trained on the same kind of work. In a small dedicated team, one absence or one peak already hurts.
Hour coverage at low volume. Covering a night shift or a Saturday with thin volume is economically absurd with exclusive staff and reasonable if the shift serves several accounts.
The cost is equally simple: judgment stays shallower, and the client doesn't control prioritization. When two accounts ask at the same time, someone decides, and that someone isn't you.
The two variables that decide it
Most of the discussion resolves by crossing two things: how long it takes a person to become productive in the process, and whether the volume fills a full shift.
- Short curve, low volume. Shared, no argument. Paying for exclusivity on a process learned in a week and occupying two hours a day is throwing money away.
- Short curve, high volume. Dedicated, for management efficiency rather than judgment. A stable group is easier to supervise and measure than a pool.
- Long curve, high volume. Dedicated, clearly. Training cost only amortizes if the person stays on the process.
- Long curve, low volume. The awkward case. Sharing forces you to train many people for little work; dedicating leaves people underused. A partial dedication usually works here: one or two people with the account as their primary responsibility plus a defined, lower-judgment filler task.
There's a third variable that changes the answer: how costly an error is. A process where a mistake carries regulatory, financial or reputational consequences leans dedicated even at mediocre volume, because the cost of one error exceeds the saving from sharing.
The mixed model is usually what works
In practice the best answer isn't either one. It's a dedicated core that holds the judgment and the process knowledge, plus a shared layer trained on the basics that absorbs the overflow. The core handles what requires judgment; the shared layer handles repetitive volume and peaks.
A small dedicated core that knows the process well outperforms a large dedicated team with half its people still learning.
That design has one requirement: documentation has to be in good enough shape for someone in the shared layer to resolve a case without asking permission. If the knowledge lives only in the core's heads, the overflow doesn't help, it gets in the way. We wrote separately about that in how a knowledge base gets prepared before day one.
What to ask when the provider offers shared
Shared isn't a problem; shared without rules is. Four things worth getting in writing:
- How many accounts one person covers. Two is not six. Past a certain point, nobody accumulates judgment in any of them.
- How prioritization works when two accounts collide. And who makes the call. If the answer is "we sort it out in the moment", the client with less volume loses.
- Which capacity is committed and which is discretionary. "There's a team available" and "eight person-hours guaranteed per day" are different promises.
- How dedicated time gets reported. If it can't be seen, it can't be raised.
The answers show up directly on the invoice, and they're worth reviewing alongside the pricing model: a shared team billed per FTE has a structural problem no review meeting fixes.
Three common mistakes
Asking for dedicated out of distrust. If the problem is that the provider isn't trusted, exclusivity doesn't solve it — it just makes it more expensive. That gets fixed with quality rules and visibility, not with exclusive headcount.
Accepting shared with no committed capacity. It works fine while the other account is calm. The day both peak, the promise gets tested and usually doesn't hold.
Sizing the dedicated team off the average. The average always understates. Staffing comes from the demand curve by time band, not from the monthly total divided by days; we explain it in how to size a support operation.
The model changes over time
Almost no account should stay in the same model forever. The usual path is starting shared while the process is being learned and real volume becomes known, then moving to a dedicated core once the work stabilizes and judgment starts to matter more than hourly cost. It runs the other way too: processes that get partially automated drop in volume and stop justifying exclusive staff.
What shouldn't change quietly is the commitment. If the model gets adjusted, the committed capacity gets adjusted and the price gets adjusted, in writing.
Where smartBPO fits
We propose the model after looking at the process, not before. When the work is repetitive and the volume doesn't fill a shift, we say shared is better and spell out what capacity is committed. When the training curve is long or errors are costly, we recommend a dedicated core even at a higher rate, because the saving from sharing gets lost in rework. In both cases we put in writing who covers the account, how much capacity is reserved and how it's reported, so the month-six conversation is about results and not about what was promised.