Ask a vendor whether their platform is multi-tenant and you’ll get a confident yes. Ask what that means for an outsourcer running fourteen client campaigns that must never see each other’s data, and the conversation gets considerably less confident.
That gap is where most bad procurement decisions in this category start.
What Multi-Tenancy Actually Means
The term describes an architecture where one software instance serves several customers, with their data and configuration kept apart by logical controls rather than by separate infrastructure. Single-tenant flips that: one instance, one customer, dedicated resources.
Straightforward enough as a definition. The trouble is that the word “customer” means two entirely different things depending on who’s speaking.
Vendor-Level Tenancy vs Client-Level Tenancy
Vendor-level tenancy describes the platform provider serving many businesses on shared infrastructure. You are one tenant among hundreds. This is what almost every cloud vendor means when they describe their architecture, and it mostly determines their economics rather than yours.
Client-level tenancy describes what an outsourcing provider needs inside their own account: the ability to run separate client campaigns with genuine isolation between them. Different data, different users, different reporting, different recordings, different numbers, and administrators who can see across all of it while agents see only their assigned account.
These are not the same requirement, and a platform can satisfy the first while failing the second completely.
I’ve watched procurement processes run for months on the wrong question. A team asks “is it multi-tenant?”, receives an accurate yes, signs, then finds during implementation that everything below the account level is flat: one shared user directory, one reporting scope, recordings visible to anyone with supervisor rights. The architecture was multi-tenant. It just wasn’t multi-tenant in the layer that mattered to them.
TabaTalk recommends asking a different question entirely: can you demonstrate hierarchical tenancy, where each client sits in an isolated sub-account with its own users, data scope, numbering and reporting, administered from a parent account you control?
Ask for the demonstration rather than the answer. Two live sub-accounts, an agent logged into one, an attempt to reach the other’s data. Five minutes of screen sharing settles what a fortnight of documentation review will not, and any vendor genuinely built for outsourcers will have that demonstration ready because they field the request constantly.
What Single-Tenant Really Buys You
Dedicated infrastructure delivers four things reliably:
- Isolation by physical separation rather than by configuration, which is easier to prove to a nervous client
- Upgrade timing control, useful when a client operates change freezes around peak trading
- Performance predictability, with no shared resource contention
- Simpler regulatory answers in some jurisdictions and industries
What it costs is equally predictable: per-instance licensing, per-instance patching, per-instance administration, and a provisioning timeline measured in weeks rather than hours. For an outsourcer whose commercial model depends on onboarding a client quickly and running many accounts at once, those costs compound in a way that reaches the margin directly.
There’s a less obvious cost too. Dedicated deployments drift. Each instance gets configured slightly differently over time, patched on its own schedule, and customized by whoever handled that particular client onboarding. Two years in, an operations team supporting eleven instances is really supporting eleven variants, and the institutional knowledge required to run them stops being transferable between staff. That drift rarely appears in the business case, yet it’s frequently what makes outsourcers regret the model.
The Comparison That Matters for Outsourcing Providers
| Consideration | Multi-tenant with sub-accounts | Single-tenant per client |
| New client provisioning | Hours, within existing account | Weeks, new instance required |
| Isolation mechanism | Logical controls and permissions | Dedicated infrastructure |
| Upgrade control | Vendor schedule, applies to all | Per client, you decide timing |
| Cost per additional client | Marginal | Close to linear |
| Cross-client reporting | Native, single administrative view | Manual consolidation |
| Agent sharing across clients | Possible with permission scoping | Difficult, separate logins |
| Proving isolation to a client | Requires documentation and testing | Self-evident |
| Regulatory scope | Additional standards may apply | Some requirements fall away |
That last row deserves its own section, because it carries genuine compliance weight rather than being a talking point.
What PCI DSS Says About Multi-Tenant Environments
Any outsourcer handling payment data on behalf of clients runs into this directly, and the standard is unusually specific.
The PCI Security Standards Council states that Appendix A1, titled Additional PCI DSS Requirements for Multi-Tenant Service Providers, applies to multi-tenant service providers, described as a type of third-party service provider offering shared services to merchants and other service providers. Their guidance also notes that the appendix was retitled from its earlier “Shared Hosting Providers” framing in version 3.2.1 to cover the broader range of technologies now used to deliver shared services (PCI Security Standards Council).
The requirements themselves centre on separation and proof of it. Summarizing the version 4.0 changes, law firm Davis Wright Tremaine notes that multi-tenant service providers must implement logical separation so the provider cannot access customer environments without authorization and customers cannot access the provider’s environment without authorization; that each customer may access only its own cardholder data and allocated resources; that the effectiveness of those separation controls must be confirmed every six months through penetration testing; and that providers must supply audit logging capabilities to customers and maintain processes for handling customer-reported security incidents (Davis Wright Tremaine).
Read that list as an outsourcer rather than as a vendor. Six-monthly penetration testing of separation controls is an operating cost with a recurring schedule attached, not a one-off procurement question.
Worth clarifying who carries which obligation, because the answer depends on where you sit in the chain. Where you take payment details on behalf of clients, you are a service provider to them, and they will ask for evidence. Where your platform vendor supplies the shared environment underneath you, they hold obligations toward you. Neither position absolves the other, and shared responsibility documentation exists precisely because the boundary is easy to misread in both directions.
Where Single-Tenant Removes Requirements From Scope
Here’s the fact most comparison articles miss entirely. The PCI Security Standards Council states that these multi-tenant requirements are not applicable where servers are dedicated to a single customer, while all other applicable requirements still apply.
So choosing dedicated infrastructure per client genuinely narrows your compliance surface. Not to zero, and the rest of the standard remains in force, but Appendix A1 falls away.
Whether that trade is worth the cost depends on your client mix. An outsourcer running two regulated financial accounts and twelve general customer service campaigns probably wants dedicated infrastructure for the two and shared infrastructure for the twelve, which is a perfectly reasonable answer that vendors selling one architecture rarely propose. TabaTalk’s guidance on contact centre security practices covers the surrounding controls.
What Client Contracts Force You Into
Architecture decisions in this market are usually driven by commercial requirements rather than technical preference. The questions that appear in outsourcing RFPs cluster tightly:
- Can our data be accessed by staff working on another client’s account? The honest answer under shared infrastructure is that permission configuration prevents it, which is a weaker sentence than a client hoped to hear.
- Where is our data stored, and can it leave the country? Residency commitments are increasingly common in Gulf financial services and government work.
- Who holds the call recordings, and for how long? Retention periods differ by client and sometimes by regulator, which shared systems handle badly unless retention is configurable per sub-account.
- Can we audit your environment? Some clients want their own assessors to test, which is complicated when the environment is shared with their competitor.
- What happens at contract end? Data extraction and deletion for one client without disturbing the others.
That fifth point is worth planning for at selection rather than at termination. An outsourcer who cannot cleanly delete one client’s data on request has a contractual problem waiting eighteen months out.
Notice how few of these are technology questions. They’re commercial commitments that happen to have technical prerequisites, which is why the architecture decision belongs with whoever negotiates client contracts rather than solely with whoever runs the platform. In my experience the two functions talk to each other far too late, usually after a proposal has already promised something the current setup cannot evidence.
Gulf-Specific Considerations
Regional operations face two constraints that reshape the decision, and neither appears in the American comparison articles that dominate search results for this topic.
Data residency and personal data handling. Financial services, healthcare and government clients in the UAE increasingly specify where data may reside. Shared infrastructure spanning multiple regions complicates that commitment; dedicated deployment simplifies it. This is worth resolving before signing rather than during a client security review, since retrofitting a residency commitment onto a live shared environment is materially harder than specifying it at provisioning.
Telemarketing rules attach to a licence, not to a campaign. UAE Cabinet Resolution No. 56 of 2024 governs marketing calls, requires prior approval to conduct telemarketing, restricts calling to defined daytime hours, and obliges businesses to disclose the source of their customer database to the regulator on request (UAE Legislation portal).
Whose Licence Do You Dial From?
For an outsourcer this is not a rhetorical question. Where numbers must be registered to the business conducting the activity, an outsourcing provider running outbound campaigns for several clients needs numbering that maps correctly to whoever holds the regulatory obligation.
Sub-account level number management makes this workable: each client’s numbers sit within their own scope, registered appropriately, with dialling rules and permitted hours enforced per account rather than globally. Flat numbering across a shared account makes it considerably harder to demonstrate which campaign dialled from which number under whose approval.
TabaTalk observes that this question surfaces late in most Gulf outsourcing implementations, usually when a client’s compliance team asks for evidence rather than at architecture selection. Raising it early tends to change which architecture people choose. The wider obligations sit in TabaTalk’s guide to outbound call centre compliance.
How to Choose: An Evaluation Checklist
Work through these before shortlisting anything. The answers separate platforms faster than feature comparisons do.
On isolation:
- Show me two client sub-accounts and prove an agent in one cannot reach data in the other.
- Can permissions be scoped so a supervisor sees several accounts while agents see one?
- Is reporting separable per client and combinable for us as the parent?
On operations:
- How long does provisioning a new client account take, realistically?
- Can retention periods for recordings differ per client?
- Can an individual client’s data be exported and deleted without affecting others?
- Are numbers, caller identity and dialling rules manageable per account?
On compliance:
- Which certifications does the platform hold, and what evidence can you supply to our clients’ assessors?
- If we handle payment data, how do you support Appendix A1 obligations, including the six-monthly separation testing?
- Where does data reside, and can residency be specified per client?
On commercials:
- How does pricing change as we add clients, and does a dedicated deployment carry different terms?
- Who bears the cost of upgrades, and can timing be controlled where a client requires a change freeze?
A hybrid answer is legitimate and often correct: shared infrastructure for the general book, dedicated deployment for the handful of accounts whose contracts or regulators demand it. Any vendor treating that as an unreasonable request is telling you something useful about their flexibility. TabaTalk’s overview of in-house, BPO and cloud operating models covers the surrounding decisions, and our BPO contact centre software page sets out how we handle client separation.
Frequently Asked Questions
Is multi-tenant software less secure than single-tenant?
Not inherently, though it carries different risk. Shared environments depend on logical controls rather than physical separation, which means a configuration error can expose several customers at once, while dedicated infrastructure limits that blast radius. PCI DSS reflects the distinction by imposing additional obligations on multi-tenant service providers, including six-monthly penetration testing of separation controls. Mature shared platforms with independently tested isolation are frequently more secure than poorly maintained dedicated instances.
Can a single vendor offer both architectures?
Some do, and for outsourcers it is worth asking directly. A vendor supporting shared sub-accounts for the general client book alongside dedicated deployment for regulated accounts lets you match architecture to contractual requirement rather than committing your whole operation to one model. Confirm that both options carry the same feature set, since dedicated deployments sometimes lag on updates, and check whether pricing and support terms differ meaningfully between them.
What is the noisy neighbour problem?
It describes performance degradation caused by another customer’s activity on shared infrastructure, such as a neighbouring tenant running a large campaign that consumes capacity during your peak. Well-designed platforms limit this through resource allocation and capacity headroom, so it is far less common than vendors of dedicated infrastructure suggest. Ask specifically what isolation exists at the resource level and whether any performance commitments appear in the service agreement rather than only in marketing material.
How does tenancy affect agent sharing between clients?
Shared architecture generally makes cross-client staffing easier, since one agent identity can hold permissions across several accounts, which matters for outsourcers redeploying staff between campaigns as volumes move. Dedicated instances usually require separate logins per client, adding friction and complicating occupancy management. Weigh this carefully if your commercial model depends on flexible staffing, since it affects daily operations more visibly than most architecture decisions do.
Does data residency require dedicated infrastructure?
Not necessarily. Many shared platforms support regional data storage, letting you specify where a given account’s data resides while remaining on common infrastructure. What matters is whether residency can be set per client rather than only per platform, and whether the vendor will commit to it contractually. Verify the commitment covers backups, recordings and analytics data, not only the primary database, since secondary copies frequently sit elsewhere.
What should outsourcers ask about client offboarding?
Ask how a single client’s data is exported, in what format, and how deletion is confirmed without affecting other accounts. Request the process in writing before signing, including timescales and any charges. Shared environments sometimes handle bulk deletion poorly, particularly for recordings and analytics derivatives. Getting a documented offboarding procedure at procurement is far easier than negotiating one during a contested contract termination.
Does migrating between architectures later cause problems?
Moving from shared to dedicated infrastructure, or the reverse, generally means re-implementing configuration, routing logic, integrations and reporting rather than simply relocating data. Treat it as a project rather than a switch. This is the main reason the decision deserves proper attention at selection, particularly for outsourcers, whose client contracts may commit them to arrangements that outlast their platform choice. TabaTalk’s guide to migrating from on-premise to cloud covers comparable ground.
Working out which architecture fits your client book?
The answer usually depends less on technology preference than on what your two most demanding contracts require, so that’s where we’d start.
TabaTalk provides cloud contact centre software built for Gulf operations, with client-level account separation, per-account numbering and dialling rules, configurable retention, and administrative visibility across your whole portfolio. Contact our sales team to walk through your client isolation requirements, or ask us to demonstrate two separated accounts side by side so you can see exactly where the boundaries sit.
