Multi-tenant is the norm, not the exception — but not everyone implements it the same way
Almost any support platform you use today is multi-tenant: the same infrastructure serves many different companies at once, each with its own customers, conversations and knowledge base. That's not a problem in itself. The problem shows up when isolation between those companies isn't guaranteed at the architecture level, but instead depends on the application code remembering to filter correctly on every query.
The difference between "we filter by client in the code" and "the data engine guarantees it"
There are two very different ways to implement multi-tenant isolation. In the first, every database query includes a filter hand-written into each endpoint — and if a developer forgets that filter even once, one client's data can end up exposed to another. In the second, isolation is defined as a policy at the database engine level (in Postgres, via Row Level Security), so that no query can ever return another client's rows, because the database itself prevents it before the result ever reaches the application.
Concrete questions to ask a provider
Before trusting your data and your customers' data to a shared platform, it's worth asking directly: is isolation between clients implemented at the database level, or does it depend on filters in the application code? What happens if a developer on the platform's team makes a coding mistake — is there a layer that still protects the data? Does the provider's internal team have unrestricted access to every client's data, or does that also go through access controls?
Why this matters as much as functionality
It's easy to evaluate a provider by its visible features and leave data isolation as a "surely that's fine" checkbox with no verification. But if your company handles customer data on a platform shared with other companies, an isolation failure isn't a minor bug — it's a third-party data leak, with all the legal and trust implications that come with it.
What good isolation looks like in practice
In a well-designed architecture, every table containing customer data has an explicit policy tying each row to a tenant, and that policy is applied automatically no matter which query runs or who wrote it. Even if the development team makes a mistake writing a new function, the worst-case outcome is that the function doesn't work — not that it exposes one company's data to another.
It isn't just a technical topic, it's a business decision
Choosing a multi-client support provider without asking how data isolation is implemented means delegating a critical security decision without ever having evaluated it. You don't need to be technical to ask the right question — it's enough to ask for a concrete answer, and to be wary of a vague response like "our data is secure" with no explanation of how.