BPO Call Centers in 2026: How Outbound Compliance Rules Differ When You’re Dialing on Behalf of Clients

BPO call center compliance is the set of TCPA, DNC, and consent obligations that apply when a call center dials on behalf of a client brand instead of for itself. It works differently because two separate parties — the client (legally called the “seller”) and the BPO (the “telemarketer”) — can each be held liable for the same call, sometimes at the same time.

That distinction matters more in 2026 than it used to. The FCC’s May 2013 declaratory ruling settled a question that had been fought over in courts for years: a seller can be held vicariously liable for a third-party telemarketer’s TCPA violations, even though the seller never dialed the phone. Since then, BPOs have had to think about compliance as a shared risk, not a single-party checklist. This post breaks down exactly how that liability splits, what an indemnification clause actually protects (and doesn’t), and how to structurally separate client campaigns so one account’s mistake doesn’t become the whole operation’s problem. For the compliance tooling referenced throughout this post, see Belsmart’s outbound compliance tooling.

What Makes BPO Outbound Compliance Different From In-House Compliance?

In-house compliance has one company on the hook for one calling program. BPO compliance has two companies — the client and the agency — potentially on the hook for the same program, running on shared dialer infrastructure, shared agents, and sometimes a shared caller ID pool across several unrelated client accounts.

That shared infrastructure is exactly where BPO-specific risk shows up. A DNC scrub that’s technically complete for one client’s list doesn’t automatically apply to another client’s list, because each seller relationship carries its own consent history and its own do-not-call obligations. Treating five client accounts as one combined compliance program, rather than five separate ones, is the most common structural mistake BPOs make.

Who Is Liable When a BPO Violates TCPA Rules on a Client’s Behalf?

Both parties can be liable, but not automatically and not equally. The BPO that physically placed the call is directly liable under the TCPA regardless of what the client did or didn’t authorize. The client can also be held vicariously liable, but only if the relationship meets the federal common law agency test the FCC laid out in 2013: actual authority, apparent authority, or ratification.

Ratification means the client knew, or reasonably should have known, that the BPO was violating the TCPA and failed to step in. Apparent authority looks at how the relationship actually functions — whether the BPO has access to the client’s internal systems, can enter data directly into the client’s CRM, uses the client’s trade name or trademark in calls, or has scripts that the client reviewed and approved. The more a BPO looks and acts like an extension of the client’s own sales team, the stronger the case for vicarious liability becomes.

Takeaway: a client isn’t automatically liable for its BPO’s violations, and a BPO isn’t automatically shielded by a contract — liability depends on the actual working relationship, not just who signed what.

Does an Indemnification Clause Protect a BPO From Liability?

No — an indemnification clause only allocates cost between the client and the BPO privately; it doesn’t change who a regulator or consumer can sue. If a plaintiff files a TCPA claim, they can name the BPO, the client, or both, regardless of what the contract between those two parties says about who ultimately pays.

This is a common point of confusion. A BPO with a strong indemnification clause might still get named in a lawsuit and have to defend itself before any reimbursement from the client kicks in. Similarly, a client can’t point to an indemnification clause as a reason it wasn’t liable in the first place — that clause only determines who pays afterward, between the two contracting parties, not whether either one was legally exposed to begin with.

How Should DNC Scrubbing and Consent Records Work Across Multiple Client Campaigns?

DNC scrubbing and consent records need to be maintained separately per client, not pooled into one company-wide list. The mechanics of a scrub itself — which lists to check and how often — are covered in depth in DNC List Scrubbing 101; the BPO-specific issue is that each client relationship carries its own consent history, and a number that’s clear to call for one client’s product may not be clear to call for another.

A consumer who consented to hear from Client A about auto insurance hasn’t consented to hear from Client B about home warranties, even if the same BPO agent is dialing both lists from the same seat. Consent doesn’t transfer between client relationships, and neither does an opt-out — if someone asks to stop hearing from one client, that request applies to that client’s list specifically, not to every campaign the BPO runs.

Compliance Responsibility Table

Use this table to see, at a glance, which side of the client-BPO relationship typically owns each compliance item — and where the line is contractually negotiable versus fixed by law.

Why Shared Caller ID Infrastructure Is a Unique BPO Risk

A caller ID pool shared across multiple client campaigns creates a reputation risk that doesn’t exist in a single-client program. If one client’s campaign generates enough spam complaints to get a number flagged, every other client dialing from that same number block inherits the reputation hit — even though their own campaign did nothing wrong.

This is why caller ID management matters as much as consent and scrubbing in a multi-client BPO operation. Assigning distinct number pools per client, rather than rotating through one shared set, contains a reputation problem to the account that caused it instead of letting it spread across the whole operation.

A Campaign-Separation Checklist for Multi-Client BPOs

Use this sequence to keep client accounts compliant and structurally separated on shared infrastructure:

1. Assign a distinct caller ID pool per client account, so a spam-flagging event on one client’s numbers doesn’t affect another client’s connect rates.
2. Tag every DNC and consent record by client, not just by campaign, so a scrub or opt-out request is applied to the correct seller relationship.
3. Version-control scripts and disclosures per client, with a documented approval trail showing the client reviewed and signed off on the language actually being used.
4. Apply the calling-hour rule that matches each client’s actual customer base — a client selling into Florida or Oklahoma needs the stricter state rule applied, as covered in Insurance Sales Dialing, even if your other clients only need the federal baseline.
5. Segregate compliance evidence in the CRM by client account, so an audit or complaint can be resolved by pulling one client’s records, not sorting through a mixed pipeline. See CRM integration for how that segregation should sync in practice.
6. Put a defined incident-notification clause in every client contract, separate from the indemnification clause, so both parties know exactly when and how a compliance issue gets escalated.
7. Audit each client program independently, rather than running one company-wide compliance check — a passing audit for four clients doesn’t tell you anything about the fifth.

Dialer pacing is a related but separate exposure worth managing alongside campaign separation — see Dialer Ratios Explained for how call pacing affects abandoned-call risk independently of client-account structure.

Takeaway: the safest BPO operating model treats every client account as its own compliance program — sharing infrastructure for efficiency, but never sharing consent records, scrub logs, or caller ID reputation across accounts.

Frequently Asked Questions