A working playbook for outsourcers running several clients on one Five9 estate: how to partition it, name it, report on it, bill it and cover it, from a team that runs these floors daily.
Should a BPO run multiple clients in one Five9 domain or in separate domains?
Most BPOs run one shared domain, partitioned by strict naming, scoped roles and per-client report folders, because it keeps admin overhead and cost down and lets agents blend across clients. Separate domains make sense when a client contractually requires isolation, holds regulated data, or may take the estate in-house later. Verify seat minimums and usage attribution with Five9 before promising either model.
The first architecture decision shapes admin, reporting and every client conversation after it.
Somewhere around client number four, the architecture question stops being theoretical. The single-domain model puts every client inside one Five9 domain, separated by naming discipline, skills and permissions. The multi-domain model gives each client, or each sensitive client, a domain of their own. Both work. The trade-offs are not symmetrical, though, and the right answer depends on what your contracts actually promise.
A partitioned single domain is the default for a reason. One admin surface, one integration estate, one place to build and audit. Agents can hold skills across clients, which is where a blended floor makes its margin: an agent finishing a quiet morning on one client's campaign can carry an afternoon spike on another's without a licence change or a second login. Costs concentrate rather than multiply.
The weakness is that the walls are procedural, not structural. Nothing in the platform stops a supervisor with over-broad permissions pulling a report that lists every campaign in the domain, including the campaign names of a client's direct competitor. The setups we audit usually fail here, not in telephony: reporting hygiene and role scoping get treated as a nice-to-have until the day an account manager forwards the wrong attachment.
Separate domains buy hard isolation. Reporting cannot leak across a domain boundary, credentials are distinct, and if the client leaves or takes the operation in-house the handover is clean: their domain, their history, their numbers. What you pay is admin multiplication. Every disposition change, every connector update, every release check happens once per domain, and agents cannot blend across domains without separate seats and logins. Commercially, assume nothing: ask Five9 whether each domain carries its own minimum commitment or whether a pooled arrangement is available, because that answer shapes the unit economics of your smaller clients.
| Factor | One partitioned domain | Separate domains |
|---|---|---|
| Isolation | Procedural (naming, roles, folders) | Structural (hard boundary) |
| Reporting cleanliness | Good if disciplined, fragile if not | Clean by default |
| Admin overhead | One estate to maintain | Multiplies per domain |
| Agent blending | Across clients, contract permitting | Not across domains |
| Client exit | Untangling required | Hand over the domain |
| Commercials | One pool, one negotiation | Verify per-domain minimums |
Our steer, from the BPO floors we support: run one domain, partition it properly, and reserve separate domains for the exceptions, meaning contractual isolation, regulated data, or a client likely to want the keys one day. Mixed estates are common and nothing to apologise for.
Seat licensing and usage attribution are contract questions, and they come before the sales deck.
The mistake is sequencing. A BPO wins a deal, promises the client a dedicated environment with pass-through telephony billing, and only then checks whether its licence agreement supports any of it. Ask first. Five9's published list pricing is per concurrent user, with usage-based charges where they apply and a stated minimum of 50 seats (per Five9's public pricing page as of mid-2026). Everything beyond that structure, and often the structure itself, is negotiated in BPO agreements, so treat the published list as the shape of the conversation rather than the outcome.
Concurrent versus named matters more on an outsourced floor than anywhere else. Concurrent seats suit shift patterns: two hundred named agents across three shifts may need far fewer concurrent licences. But read the small print on adjacent products. Five9's own pricing notes state that workforce engagement management is licensed on a named basis, with add-ons where named seats exceed the concurrent seats sold. A 24/7 floor that assumed everything scaled concurrently has bought itself a surprise.
Questions we put to Five9, or help clients put, before any multi-client model is promised to anyone:
None of these have a single published answer, which is precisely the point. Get the answers in writing before the client's lawyers draft anything that mentions them.
Our free 17-question Five9 Health Check covers the partitioning, reporting and continuity checks in this playbook, scored the way we build multi-client estates.
Fifteen clients stay untangled because every object announces who owns it.
Pick a short client code, three or four characters, and put it at the front of everything: campaigns, skills, dispositions, lists, IVR scripts, agent groups, report folders. At the front, not the end, because every picker and report filter sorts and searches from the left. The scheme we deploy looks like this:
| Object | Pattern | Example |
|---|---|---|
| Campaign | CODE-Direction-Purpose-Geo | ACM-OB-NewLeads-UK |
| Skill | CODE-Function | ACM-CS-Billing |
| List | CODE-L-Date-Source | ACM-L-2607-Web |
| Disposition | CODE-Outcome (client-specific only) | ACM-Booked-Survey |
| IVR script | CODE-Flow | ACM-IVR-Main |
| Report folder | CODE-Reports | ACM-Reports |
Dispositions deserve a decision, not a habit. Keep one shared core set for outcomes every client needs (no answer, busy, voicemail, wrong number) so cross-client reporting stays comparable, and prefix anything client-specific. A domain where every client invented its own version of "not interested" is a domain where nobody can compare campaigns, and we see plenty of those.
Three rules keep the scheme alive over years rather than months. Never reuse a code, even long after a client leaves, because historical reporting keeps the old rows and a recycled code quietly merges two clients' history. Never rename mid-flight, because reporting follows the name in most setups and a renamed campaign can orphan months of trend data. And keep a register, a spreadsheet is fine, recording each code, the client, the owner and the go-live date, because the scheme only protects you while it is the only scheme in use.
Build per-client packs that cannot show anyone else's data, then verify that they do not.
The monthly client pack is where partitioning earns its keep or fails in public. Build one custom report set per client, filtered hard on the client code, and file it in that client's folder. Five9 supports scheduling reports for automatic email delivery or drop to FTP (its own BPO material describes exactly this pattern), which is how the pack should move: on a schedule, to a distribution list, not hand-exported by whoever remembered.
What goes in ours: volumes and connects, contact rate, abandon rate, average handle time, disposition breakdown, list penetration and per-campaign detail. On abandon rate, use the regulatory definition: abandoned calls divided by calls answered by a live person. Ofcom's policy and the US TCPA rules both measure it against live answers, and a dialler set up to report abandons against total dials will flatter the number and mislead the client who carries the exposure.
The leak vectors are boring, which is why they get missed. A summary row left in a template that covers "all campaigns". A dashboard shared with a client supervisor "temporarily" and never revoked. Agent-level tabs on a blended team, where one agent's day includes three other clients' campaign names. Role scoping closes most of this: client-facing users get roles restricted to their own campaigns, skills and folder, nothing inherited, and the restriction gets tested by logging in as that user rather than assumed from the config screen.
The habit that catches the rest: subscribe an internal address to every client pack for its first two cycles and read what actually arrives. That is far cheaper than the conversation that follows a bad attachment.
Campaign-level call detail turns invoicing from an argument into a filter.
Campaign-level reporting is the source of truth for attribution, and the prefix scheme makes per-client rollup a single filter. From there, attribution is a choice of rule rather than a technical problem, and the rule belongs in the client contract, not in a spreadsheet argument eight months in.
For dedicated teams, seat-day allocation is simplest: the client pays for seats staffed against their code, verified from agent group membership and login reports. Blended floors need a usage rule instead, and the two we see hold up are talk-time share and handle-time share by campaign code. Handle time is fairer where wrap dominates; talk time is harder to dispute. Either way the number comes from call detail the client could inspect line by line, which is the property that ends arguments before they start.
Usage pass-through, meaning telephony, numbers and SMS, is only as clean as the invoice's granularity, which is why the invoice question sits in the commercial checklist above. Reconcile the Five9 invoice's usage lines against your own campaign-level detail monthly, and expect a small unattributable remainder: shared IVR time, test calls, admin activity. Decide in advance whether that remainder spreads pro rata or gets absorbed as overhead, and write the decision down. The honest answer on blended idle time is that any allocation is a judgement call. Pick one, disclose it to every client, and apply it the same way every month.
The tenth client should cost a fraction of the first.
By the third or fourth client, onboarding should stop being a project and become a runbook: a template campaign set cloned under a new code, with a checklist that does not depend on anyone's memory. Ours runs to six stages:
The compliance profile is per client geography, and it is configuration, not paperwork. For UK calling, PECR regulation 21 requires screening against the TPS register and honouring prior objections, and the regulations also require callers not to withhold CLI and to present a number on which they can be contacted. Ofcom's persistent misuse policy is the other UK pillar: the long-standing benchmark treated abandoned calls above three per cent of live calls, per campaign per 24 hours, as the enforcement trigger, and since Ofcom's revised statement took effect on 1 March 2017 there is no safe harbour at all, so operators typically configure well inside the old line. For US calling, the TCPA rules cap abandons at three per cent of calls answered live by a person, measured over 30 days per campaign, with a two-second connection requirement and a prescribed identification message on abandoned calls. Our detailed walk-throughs are at Ofcom dialler rules and TCPA abandonment rules. These regimes move, and enforcement practice moves faster than the text, so check the current versions before a new geography goes live and put qualified counsel across anything with real exposure.
One nuance multi-client floors miss: the tightest applicable rule wins at every point of shared infrastructure. If a blended team dials two geographies in one shift, the pacing and messaging configuration on each campaign needs to match that campaign's geography, not the floor's habit.
One admin's notice period should not become a client-continuity incident.
Here is the failure mode nobody prices in. A fifteen-client domain, built over four years by one very good administrator, who resigns with four weeks' notice. Nothing is wrong with the platform. Everything is wrong with the situation: the naming logic is in their head, the campaign quirks are in their head, and the client who needs a list loaded at eight on Saturday morning is now everyone's problem. We have been called into exactly this, more than once, and on arrival the only documentation was the departed admin's inbox.
The cover models that work are cumulative, not alternatives. Standards come first: if the naming register and per-client runbooks from earlier in this piece exist, most of the operational knowledge already lives outside anyone's head, which is the real argument for building them. A second person comes next: a deputy admin who has run at least one full client onboarding solo, not shadowed one, because shadowing tests nothing and the solo run is the test. Then access hygiene: named admin accounts with a documented role model, no shared logins, credentials in a managed vault, so that revoking one leaver neither locks the estate nor leaves a ghost holding the keys.
The external option is a retainer with a partner who already knows your estate, which is candidly a service we sell, so weigh the source of the advice accordingly. The argument for it is arithmetic rather than sentiment: a second full-time admin costs more than external cover, and cover that already runs your changes and releases works from day one of a notice period instead of spending it learning your prefixes.
Two surfaces to manage: what the client's customer sees, and what the client's own staff see.
Running as the client's brand is really two jobs. The first is what the client's customer experiences: CLI, greeting, scripts, voicemail drops, hold audio, SMS sender IDs. Presented numbers should answer as the client if called back, and for UK traffic the PECR rules require presenting a contactable number rather than withholding CLI. On US traffic, number ownership drives STIR/SHAKEN attestation and number reputation: numbers registered and monitored properly are the difference between the client's brand on the handset and "Spam Likely", and we cover the mechanics in fixing spam-likely caller ID. Agree in the contract whose numbers these are and who takes them on exit, because porting arguments are slow exactly when the relationship is at its worst.
The second surface is what the client's own staff see. Report exports look like platform reports, not like your agency, so if branding matters the pack gets wrapped before it ships. Disposition labels appear verbatim in client-facing detail, so name them in language the client would happily show their own board. And if the client gets a login, it is read-only, scoped to their code, and reviewed whenever their staff change, because a client-side leaver with a live login is the same continuity problem as your own leaver, in someone else's building.
None of this is exotic. It is the same discipline as the rest of the playbook applied one layer out, and it is the layer prospective clients ask to see during due diligence, so a tidy estate wins deals as well as running them.
Yes, and it is the main economic argument for the single-domain model. Agents hold skills across clients and blend between campaigns within one login and one seat, where contracts permit it. Across separate domains they cannot: each domain means its own login and its own licensing, so a floor that relies on blending to absorb volume spikes usually belongs in one partitioned domain rather than several isolated ones.
The ceiling we run into is administrative rather than technical. With a disciplined prefix scheme, scoped roles and per-client report folders, fifteen or more clients in one domain stays manageable; without them, five clients is already chaotic. The better question is not how many the platform can hold but how many your naming register, runbooks and admin cover can genuinely support at once.
Five9's published list pricing is per concurrent user, with a stated minimum of 50 seats and usage-based charges where they apply. Some products behave differently: the same pricing notes state that workforce engagement management is licensed on a named basis. BPO agreements are negotiated, so confirm in writing how concurrency is measured, how burst months are handled and which add-ons are named before promising any client a commercial model.
Scope roles so client-facing users only see their own campaigns, skills and report folder, build each client's reports filtered on their prefix, and keep them in dedicated per-client folders. Then test it by logging in as the restricted user and pulling the reports. The leaks we find in audits are rarely dramatic: usually a template summary row covering all campaigns, or a dashboard shared temporarily and never revoked.
Abandoned calls divided by calls answered by a live person. Ofcom's policy in the UK and the TCPA rules in the US both measure against live answers, with the US rule set at three per cent over 30 days per campaign. Reporting abandons against total dials produces a much smaller, wrong number, and a client pack built on it misleads everyone, including the client who carries the regulatory exposure.
Whatever your agreement says, which is why it needs settling before signature rather than at exit. Ask whether committed seats shrink, transfer to other clients or persist to end of term, and, if the client had a separate domain, whether it can be handed over with its history and numbers. A domain handover is one of the cleaner exits in this industry when it was planned for on day one.
Hybrid. Keep one shared core set for universal outcomes such as no answer, busy and voicemail, so campaigns stay comparable across clients, and prefix anything client-specific with the client code. Fully per-client disposition sets destroy cross-client benchmarking, while a fully shared set forces one client's vocabulary onto another's reporting. The hybrid costs you a naming rule and buys you both.
In our experience the platform build is the fast part: cloning a template campaign set under a new client code is measured in days once the runbook exists. Discovery and compliance set the real pace, particularly consent review, suppression files and the per-geography dialler profile. First clients take the longest, and the point of the runbook is that the tenth costs a fraction of the first.
We design, run and cover multi-client Five9 estates for BPOs in the UK and US: a dedicated pod, named people, and admin cover that has done this before. Tell us what you run and we will tell you what we would check first.
Talk to us