Voice AI for BPOs and contact centers: sell outcomes, not seats

For a BPO, voice AI is a commercial decision before it's a technology one. Put the AI tier where clients get nothing today (overflow, after-hours, callbacks, quality review), run it as a separate service line per client, and price it on resolved outcomes while your people take the exceptions. Bolt it onto a seat-hour contract instead, and every call it resolves is an hour you stop billing.

Sequencing matters more than model choice. Below: where the AI tier goes first, the containment break-even to work out before you quote, the handoff details clients judge you on, and how to run many clients on one platform without mixing their data. For the basics of how the agents work, see our complete guide to AI voice agents.

Why seat-hour contracts and voice AI pull in opposite directions

Most contact-center outsourcing is still bought as capacity: FTEs, productive hours, sometimes handled minutes. Under that model your revenue grows with handle time, so anything that shortens or removes a conversation shrinks the invoice. An AI tier that resolves a third of a client's tier-1 calls is excellent news for the client and, on an FTE contract, a revenue cut for you.

Buyers know this, and contracts are moving. An HFS Research report produced with Firstsource projects reliance on FTE-based models dropping from 42% to 28% over the next three years, while outcome-based models nearly double from 20% to 39%. Expect your next renewal to arrive with an outcome-priced option on the table whether you offered one or not.

So sequence the rollout to add billable work before the AI replaces any.

Where the AI tier goes first

Rank the layers by how much new value they create for the client against how much of your current billing they cannibalise. Four layers, in this order.

1. Overflow and after-hours

Calls that ring out, abandon in queue or land in a voicemail nobody clears earn nobody anything. An AI tier that answers them on the first ring gives the client a service level it wasn't getting, and adds a line to your invoice instead of removing one.

The design of that inbound layer (first-ring answer, tier-1 resolution, a transfer that carries context) is covered in our guide to 24/7 AI phone support, so we won't repeat it here.

2. Outbound follow-through

Callbacks, appointment and payment reminders, survey calls, and the fourth and fifth attempts on a contact list are work most clients under-fund, because human dialling time is expensive. This is where a platform's campaign logic carries the load.

In Callaro, retry gaps widen as attempts pile up and stay inside each contact's calling window, evaluated in the contact's own time zone if you choose. Voicemail and live call-screening are detected separately and handled differently. A contact who calls back mid-campaign can be routed to that context with their queued retry cancelled, so nobody rings them again three hours later.

3. Quality review of every AI-handled conversation

Human QA teams typically score a small sample of calls. For the AI tier you can score all of them. Operators attach their own analysis prompts with a typed output schema to an agent ("was the issue resolved?", "did the caller ask for a person?", "was the required disclosure read?"), and every completed call runs through them.

For a whole campaign there are batch runs that start from templates such as Compliance & QA Audit, Support Triage or NPS. Each run snapshots the prompt, schema and model, so this month's scores compare cleanly with last month's.

Be precise with clients about scope: this covers the conversations the AI tier handles. Your human floor's calls stay on the QA tooling you already run.

4. Tier-1 in the core queues, last

Move AI into the billed core only when you have per-intent containment data from the first three layers and a contract that pays for resolutions. Doing it first is how a BPO ends up funding its client's savings out of its own margin.

The number to know before you quote: your containment floor

A transferred call costs more than one a person handled from the start. The caller spent AI minutes before reaching a person, and the person still handled the hard part. So an AI tier lowers your cost per contact only above a minimum containment rate, and that floor sits higher than most teams assume.

Work it out per client programme with four inputs:

• H: your loaded cost for a person to handle a contact end to end (average handle minutes × your loaded per-minute cost).
• A: the AI cost per contact the tier touches (AI minutes × the sum of the metered components: speech recognition, the language model, speech synthesis and telephony; this breakdown explains each one).
• c: containment, the share of AI-handled contacts resolved with no person involved.
• Ht: the human cost of a contact that arrives by transfer.

Blended cost per contact = A + (1 − c) × Ht

The AI tier pays when that is lower than H, which rearranges to:

c > 1 − (H − A) ÷ Ht

If transferred contacts cost the same as an average one (Ht = H), the floor is simply A ÷ H. Your containment has to beat the ratio of AI cost to human cost.

Transfers are rarely average, though. The contacts the AI hands over are the awkward ones. Take an illustrative programme where the AI costs one fifth of a person per contact:

1. Transferred contacts take average human effort: the floor is 20% containment.
2. They take 1.2 times average effort: the floor rises to about 33%.
3. They take 1.5 times average effort: the floor is about 47%.

Same AI, same client, more than double the break-even, driven entirely by what the transfers look like. Run the model per intent, not per programme. A password reset and a billing dispute belong in different rows.

Three levers move the floor, and each maps to a design decision:

• Raise c per intent by routing only intents where the agent can act. If the client's systems have no API for the task, the agent can explain but not finish, and containment collapses.
• Cut the AI minutes on transferred calls. Minutes spent before a transfer are pure overhead, so the agent should establish in its first exchange or two whether it can finish the job.
• Cut Ht by passing context with the transfer so your agent doesn't re-ask everything. That's the next section.

Under an outcome-priced contract, your margin per resolved contact is the agreed outcome price minus this blended cost. Plug in your own rates; current platform rates are on our pricing page.

The handoff decides whether clients trust the AI tier

A client forgives an AI that says "let me get you a colleague". It does not forgive a transfer into dead air, or an agent who asks the caller to repeat everything. Four things to get right:

• Control where calls can go. Callaro's transfer tool dials only allowlisted numbers, or a number your routing endpoint returns at the moment of transfer. The endpoint receives the fields captured so far, the call's variables and both phone numbers, so it can pick the right client queue, language skill or territory. Callers can't talk the agent into dialling an arbitrary number.
• Don't transfer on reflex. A confirmation gate in the runtime holds a transfer the model attempts on the caller's first turn, or without a request, and has the agent ask one short yes-or-no question first.
• Screen-pop the person who picks up. Subscribe your desktop or helpdesk to per-turn transcript updates and the transfer-started event, and the ticket opens with the conversation so far. That's how you cut Ht.
• Reconcile, because "started" isn't "answered". The platform records that a transfer started (destination, reason, time), not whether someone answered. Transfer into something that always answers, such as an ACD queue or hunt group, and reconcile transfers started against your ACD's answered calls every week. If you bring your own telephony, confirm your carrier connection supports transfer and test it on your own lines.

Running many clients without mixing them

A BPO's platform problem is separation. Every client needs its own agents, numbers, data and reporting, and nothing should leak between them.

In Callaro a partner account sits above any number of client workspaces. Each workspace has its own agents, phone numbers and telephony connections, contacts, Do-Not-Call list, outcome codes, analysis prompts, API keys and billing. In practice:

• Consent stays with the brand it was given to. An opt-out captured on one client's campaign becomes a Do-Not-Call entry in that client's workspace and cancels the person's pending follow-ups there. It doesn't silence a different brand they never opted out of.
• Client rules reach every agent. A workspace-wide rules pack (required disclosures, brand language) is applied ahead of each agent's own prompt, so a new agent can't ship without them.
• Branding per client. Brand profiles and custom domains can sit at partner level or on each client workspace, and workspaces and their agents can be created through the partner API.
• Your margin is visible per component. You set your own markup on each metered component (speech recognition, speech synthesis, the language model, call analysis) per client workspace, and the partner usage view shows, component by component, the client's charge, your cost and the margin. With your own telephony, the carrier bills you directly and stays out of those figures.

The same agent can also take a client's chat, WhatsApp and email tiers with one memory per customer, which matters once a client wants one vendor across channels.

Blended floors: inbound and outbound share the lines

One operational trap catches blended programmes. Within a client workspace, a campaign's dial rate is capped by the smallest of three limits: the calls per second the connected number pool allows, the workspace's concurrency cap, and the campaign's own limit. When two campaigns share a pool, a priority setting decides which one gets free lines first.

Inbound and outbound calls draw on the same line capacity, though, and nothing holds lines back for inbound calls that haven't arrived yet. On a day you expect an inbound surge (a billing run, an outage, a results day), set the campaign's concurrency limit below your line capacity, so outbound work can't crowd out the inbound queue the client measures you on.

Reporting a client will sign off on

Outcome pricing only works if both sides agree what "resolved" means before go-live. Write it down per intent, as evidence the platform actually records:

1. An outcome code. Every AI call ends with a reason code. "Completed" is reserved for a normal ending where the request was handled, and you define codes for the unproductive endings. The agent can't end a call on an "okay" or "hmm": it needs a goodbye or an explicit "that's all".
2. A captured field. The agent's extraction schema records typed values in the turn the caller gives them (a booking reference, a confirmed date, a promised payment date), so a call that drops midway still keeps what was said.
3. No repeat contact from the same customer on the same intent within a window you agree, measured in the client's own systems.

Then report per client from the campaign analytics: answer rate, outcome by attempt number, first-attempt completion, cost per outcome, reachability by hour and carrier error codes. Push results into each client's CRM through webhooks. Each delivery carries an idempotency key that stays stable across retries, so the client's system can drop duplicates.

When voice AI is the wrong move for a programme

Some programmes should stay human, at least for now:

• A pure FTE contract with no unbilled volume and no renewal in sight. Automation would only move your margin to the client.
• Client systems with no API. The agent can talk but not act, so it becomes an expensive FAQ.
• Low-volume, high-judgement queues. Escalations, complaints, tier-2 technical support, fraud victims and bereavement calls need people.
• Languages and accents you haven't tested on real calls. Listen to recordings in each language before you commit to a service level.
• Processes the client's regulator or legal team won't let you automate. Respect that even when it is technically easy.

A 90-day plan for your first client

1. Weeks 1–2: pick the programme. One client, one programme with unbilled overflow or after-hours volume, and API access to the systems behind its top intents.
2. Weeks 3–4: define the evidence. Intents, outcome codes, the extraction schema and a written definition of "resolved", including the repeat-contact window.
3. Weeks 5–8: run overflow and after-hours only. Score every AI call with analysis prompts, listen to a sample yourself, and reconcile every transfer against the ACD.
4. Weeks 9–10: run the containment-floor model per intent with your real H, A and Ht. Drop the intents that fall below the floor.
5. Weeks 11–13: propose the AI tier as a priced service line for the next contract cycle, outcome-based for the intents that clear the floor, with your people on the exceptions.

The BPOs that do well out of this contract cycle will walk into renewals holding their own containment data, not a vendor's demo. If you run programmes for several clients, see how the BPO and contact-center setup works, or look at the partner programme for white-label workspaces.