A support operation rarely has a single channel. There's a phone line, a chat widget on the site, an email inbox and — in Colombia and across most of Latin America — a WhatsApp number somebody answers. The temptation is to treat all of it as the same work split across four doors.
It isn't. Each channel has its own physics: demand arrives differently, capacity per person is calculated differently, and the operation breaks differently when people are missing. Anyone about to outsource support needs to understand those differences before requesting a quote, because the hourly rate looks similar across channels and the outcome doesn't.
Voice: the channel that doesn't wait
A call is synchronous and can't be deferred. If no agent is free in the exact minute it rings, the customer waits in queue or hangs up. That forces capacity to be present by time slot rather than spread across the day, and it forces deliberate slack: a voice team running at maximum occupancy doesn't handle more, it handles worse, because any small variation turns into queue. The arithmetic behind that slack is in how to size a support operation and in shrinkage in BPO.
In voice, one conversation occupies one whole person, plus the after-call work of logging the case. It's also the channel least tolerant of slow lookups: an agent can't work through five screens while someone waits on the line. Which is why voice depends more on training and judgement than on available documentation.
Chat: concurrency isn't multiplication
Chat lets one agent handle several conversations at once, and that's its real advantage. It's also its most common trap: assuming three chats means triple the capacity. It doesn't. As concurrency rises, response times stretch, writing quality drops and context errors appear — sending one customer the answer being typed for another. Concurrency is a design decision with a practical ceiling, and that ceiling depends on case complexity, not on sales enthusiasm.
Chat rewards the opposite of what voice rewards: here documentation rules. Saved replies, written decision trees, well-indexed internal articles. A chat channel run without a knowledge base becomes slow and uneven. How that material gets prepared before launch is in knowledge base before day one.
Email and tickets: the only queue you can actually manage
Email is the most flexible channel because it's genuinely asynchronous: it can be prioritised, grouped by type and worked in batches. That allows load levelling — using the operation's quiet hours to bring the written queue down — and it's why a mixed team is often more stable than two separate ones.
Its risk is invisible backlog. The average indicator can be met while a minority of cases waits days, and that minority is what produces complaints, reopens and the calls that arrive later. A written queue is measured by age and percentile, not by average: how many cases are older than a day, than three days, than a week. A dashboard showing only average first response is hiding the problem, not measuring it.
Email also carries the longest cases. A single subject can involve several exchanges, attachments, checks with another department. Billing per "case" without having defined what counts as a case is one of the most frequent month-two arguments.
A channel isn't only a customer preference: it's a capacity constraint.
Messaging: WhatsApp breaks the clock
In messaging the customer replies whenever they feel like it. A conversation can open on Monday, continue Tuesday and close Thursday without anyone having done anything wrong. That dismantles metrics inherited from voice: end-to-end resolution time says nothing useful when most of the clock was consumed by the customer.
There's also a definition worth settling before signing: what is a contact. The whole conversation, the session inside a time window, or each message? Billing depends on that definition when the model is per transaction, and so does the shape of the indicators. The alternatives are described in BPO pricing models.
On top of that come the platform's own rules — approved templates, response windows, consent requirements — which shape how the channel can be run and are outside the control of both client and provider.
What breaks when you mix channels in one person
Blending channels in the same agent sounds efficient and sometimes is, but the mix has an unavoidable hierarchy: voice interrupts everything else. An agent typing two chats who receives a call abandons two contexts at once, and resumes both worse. The cost of context switching shows up in no report, but you see it in rework.
What does work:
- Channel blocks inside the shift instead of permanent blending: two hours of written queue, then voice, then written again.
- Explicit priority rules for which channel gives way when both spike at once. If it isn't written down, the busiest agent decides, and decides differently every day.
- Profiles assessed per channel. Writing clearly and correctly isn't the same skill as holding a difficult phone conversation. Assess them separately or you end up with a team that's good at one channel and weak at the other.
- One primary channel per person, with the second as trained backup. Everyone doing everything sounds flexible and produces mediocrity.
Metrics don't transfer
Each channel needs its own measurement frame. Voice: service level in seconds, abandonment, occupancy. Chat: first response, actual concurrency, same-session resolution. Email and tickets: queue age, reopens, exchanges per case. Messaging: response inside the operating window, not total thread time.
Quality changes shape too. The written channel leaves complete evidence: the whole text can be audited, against clear criteria, without depending on recordings. Voice requires listening, so the sample is usually smaller and feedback slower. The method we use for both is in quality control by audited sampling. And satisfaction is best read per channel: the aggregate hides precisely the channel that's failing.
Before deciding the mix, look at contact reasons
Many organisations open channels under commercial pressure rather than by design. It's worth remembering that a new channel doesn't only redistribute demand: it also generates its own, because it lowers the barrier to asking.
The useful conversation is by reason. Which reasons belong on voice — urgency, emotion, negotiation, closing; which are better in writing — administrative steps, status, sending documents, anything needing a record; and which reasons shouldn't reach any channel because the process or the product is causing them, which we covered in reducing contact volume. One more decision remains: when a case jumps from one channel to another, and what information travels with it. That gets designed alongside escalation, as we set out in support tiers.
What to ask a provider
- How they size each channel separately, and what slack they assume in voice.
- What chat concurrency they assume, for what kind of cases, and how they adjust it if quality drops.
- How they measure and report the age of the written queue, not just the average.
- How they audit the written channel versus voice, and at what sample size.
- If they intend to blend channels in the same person, under which priority rule.
- How they count a contact in messaging, with the definition in writing.
- What happens to the written channel when voice saturates, and who authorises that trade-off.
How smartBPO works it
When we build a multichannel operation, we size each channel separately and then decide what can be blended and what can't, rather than assuming every agent does everything. Chat concurrency is set by looking at real case complexity and reviewed against measured quality — not fixed in advance to make the quote look better. The written queue is reported by age, with the old cases visible, because a comfortable average is no basis for a decision. And before opening a new channel we'd rather review contact reasons with the client: sometimes the right answer is not to open it. We don't promise that a particular mix works in the abstract; we try to make sure each channel is measured for what it is, and that the capacity decisions are written down before day one.