Multiple brands, one support team: what to separate and share
One support team, several brands: when each brand needs its own tenant, what teams share across tenants, and which work doubles.
Martin Semmele
Key takeaways
- The decision is made at four places: knowledge, Help Centre, widget and inbox. Where even one of them has to differ per brand, the brand needs its own tenant.
- One tenant per brand means, in most tools, one subscription per brand. If you do not budget for that in advance, you will budget for it afterwards.
- What gets shared is the team, not the knowledge: the same person works in several tenants, but every knowledge base is maintained separately.
- Knowledge that applies to all brands is the real maintenance burden. It belongs in one source from which each brand derives its own version, not in a shared base.
- Tone of voice, privacy disclosures and per-brand reporting are the three places where a shared base fails in practice.
Four places where the question is decided
The question of 'one tenant or several' sounds like a question of tools. It is a question of product: what do customers of one brand see that customers of the other must not see? In software architecture this is called tenant separation, and Microsoft puts the core of it this way in its guide to tenancy models: whoever shares infrastructure must make sure that answering one tenant's request never returns another tenant's data1. The same applies to support tools, only tied to four concrete places.
First, knowledge. If the AI agent answers questions about brand A from articles written for brand B, the result is confusing at best and wrong at worst: different deadlines, different prices, different contacts. Second, the Help Centre. If it runs under the brand's domain, it has to carry that brand's name, colours and language; a Help Centre in which a second brand appears betrays a corporate structure the customer should never see. Third, the widget. It carries the colour, logo and greeting of the brand on whose page it is embedded. Fourth, the inbox. If a request to brand A has to be invisible to colleagues who only look after brand B, it needs its own inbox.
The rule is: as soon as even one of the four places has to differ per brand, the brand needs its own tenant. In practice, almost all four differ. The shared base is the exception, not the norm, and it only fits when the brands present themselves to the outside world as one anyway, for example a main brand with a product line that carries the same name.
| Question | One shared tenant is enough when … | Separate tenants as soon as … |
|---|---|---|
| Knowledge | All brands have the same deadlines, prices and processes | An answer for brand A would be wrong for brand B |
| Help Centre | All brands appear under one domain and one name | A brand needs its own domain or its own language |
| Widget | Colour, logo and greeting are the same everywhere | A brand carries its own look and feel |
| Inbox | Every person may see every request | Only part of the team may see a request |
What a tenant per brand costs
Separate tenants are the clean solution, and they carry a price that often only becomes visible after the decision has been made: in most support tools, a tenant is also the unit that gets billed. A tenant per brand then means a subscription per brand, with its own seats and its own allowances. If you plan three brands on one person, you are planning three subscriptions.
At Comlayer this is explicitly the case: a workspace is exactly one brand. Each workspace has its own knowledge, its own Help Centre, its own widget, its own inbox and its own subscription with its own seats. Two brands are two workspaces and therefore two subscriptions; there is no shared plan across several workspaces. The same person can be a member of several workspaces and occupies a seat in each one. That is not a footnote but the calculation that has to be on the table before the decision.
The counter-entry is the work that a shared base costs, which is rarely budgeted: every answer has to be checked for whether it holds for all brands; every article needs a note saying which brand it applies to; and the AI agent has to guess at every question which brand is meant, which it could do from a chat window on brand A's page, but not from an email. Separation costs money, a shared base costs errors. Which of the two is more expensive depends on how often the brands contradict each other.
How a team works across multiple tenants
The good news about separate tenants: it is the knowledge that gets separated, not the team. The same people look after several tenants, and that needs three things which every tool solves a little differently.
The switch between tenants.
Anyone looking after three brands needs a way to switch between them without signing in again. At Comlayer this is the workspace switch in the sidebar: a person is a member of several workspaces and switches between them there. What does not exist is an inbox across all workspaces; every request sits in the workspace whose widget or Help Centre triggered it. That is a consequence of the separation, not a gap: a shared inbox would be exactly the place where a request to brand A sits next to one to brand B.
Responsibilities and notifications.
In practice, not every person looks after every brand. Who handles which brand is governed by membership: a person who only looks after brand B is only a member of its workspace and receives notifications only from there. That replaces rules that would otherwise have to be rebuilt as filters in the inbox. Roles apply per workspace; whoever is an administrator in one workspace can be a plain team member in another.
Duplicate maintenance of knowledge that applies to all.
This is the uncomfortable part, and it should not be talked up: knowledge that applies to all brands, such as a returns process or the support team's opening hours, has to be maintained separately in every tenant. Anyone who does that ten times by hand has ten different versions after the third update. The way out is not a shared knowledge base but a shared source: an internal document from which each brand derives its own version, with the brand's name, its deadlines and its tone of voice. We have described how such a review cycle attaches to the original and triggers an obligation in every version, for the case of several languages, in our own article on knowledge base governance in seven languages; the same mechanism applies to several brands.
| Task | Shared | Maintained per brand |
|---|---|---|
| Team and roles | The same people, membership per tenant | Roles are assigned per tenant |
| Knowledge that applies to all | One internal source | One derived version per brand |
| Knowledge that concerns only one brand | Nothing | Everything |
| Text snippets and tone of voice | The structure of the templates | Greeting, name, wording |
| Reporting | The comparison between the brands | The metrics themselves |
Three places where a shared base fails
Anyone who still considers a shared base should check three places where it breaks most often in practice. They are not theoretical; they are the reasons why teams separate after a year after all.
Tone of voice. One brand is informal, the other formal. One is terse and technical, the other warm and expansive. An AI agent that serves both from one knowledge base hits the tone for one of them at most. With separate tenants, tone and language are set per workspace, and the agent knows only that one. What tone-of-voice rules that hold up in daily work look like is in our article on the AI's tone of voice; with several brands there are several such rule sets, not one with exceptions.
Privacy disclosures. If a customer asks which data is stored about her, the answer must contain the data of this brand and, depending on who legally stands behind the brand, only that. If all brands sit in one tenant, what was stored together has to be separated by hand at export time. With separate tenants, the separation is already there. The reverse holds too: if several brands are the same company, a shared tenant is no problem at this point.
Reporting. With separate tenants, a support report per brand is a look into the respective workspace. With a shared base it is a question of filters, and the filter assumes that every request was cleanly assigned to a brand, which is rarely the case for emails sent to a shared address. If you want to know whether brand B generates more returns questions than brand A, you need the separation at the moment the request arrives.
The special case: agency or service provider
Support agencies and service providers that take over customer service for several clients face the same decision with one extra condition: the clients are different companies, and a shared tenant is out of the question. Here the separation is not a trade-off but a prerequisite.
The model is then the same as for several brands of one company, only with ownership reversed: the client owns the tenant, the agency is a member of it. At Comlayer the client creates its workspace, invites the agency as team members and keeps knowledge, Help Centre and subscription in its own hands. When the collaboration ends, the membership is removed and nothing has to be transferred. An agency that looks after ten clients is therefore a member of ten workspaces and switches between them; it does not need a collective tenant of its own, and it should not want one.
Making the decision in one afternoon
The decision can be made with four questions in one afternoon, and it should be made before the first article goes into the Help Centre, because separating afterwards means assigning every article and every request to a brand.
- 01For each of the four places (knowledge, Help Centre, widget, inbox), write down whether it has to differ between the brands. A single yes decides in favour of separate tenants.
- 02Collect the knowledge that applies to all brands in one list. That is the extent of the duplicate maintenance; it should stay small, and whatever is on it gets a shared internal source.
- 03Count the subscriptions: one tenant per brand, the seats per person and tenant. The number is on the table before the decision is made.
- 04Decide for each person which tenants she is a member of. Whoever looks after only one brand is a member only there.
Whoever has the four answers has the decision. Comlayer does not force it in either direction, but makes one thing clear: a workspace is one brand, and everything that belongs to it stays inside. What that means for security and privacy per workspace is on the security and privacy page.
Frequently asked questions
Do I need a separate tenant for every brand?
As soon as knowledge, Help Centre, widget or inbox have to differ between the brands, yes. A shared tenant only fits when the brands present themselves to the outside world as one and have the same deadlines, prices and processes.
Can one person work in several tenants?
Yes. At Comlayer a person is a member of several workspaces and switches between them in the sidebar. She occupies a seat in each workspace, and her role is assigned per workspace.
What do two brands mean for billing?
At Comlayer, two brands are two workspaces and therefore two subscriptions with their own seats. There is no shared plan across several workspaces. This calculation belongs before the decision, not after it.
How do I keep knowledge up to date that applies to all brands?
Not through a shared knowledge base, but through a shared internal source from which each brand derives its own version. Every change to the source triggers an obligation in every version; if that is not organised, you have as many versions as brands after the third update.
Is there an inbox across all brands?
Not at Comlayer. Every request sits in the workspace whose widget or Help Centre triggered it. A shared inbox would be exactly the place where the separation is undone again.
What applies to agencies with several clients?
The client creates the workspace and invites the agency as team members. Knowledge, Help Centre and subscription stay with the client; when the collaboration ends, the membership is removed. The agency is a member of as many workspaces as it has clients.