One team, several front doors
Plenty of companies run more than one brand or site off a single support team — an agency with client sites, a group with several product lines, a company mid-rebrand. The challenge is real: each brand has its own voice, customers, and context, but you can't afford a separate team for each. Live chat has to keep the brands straight while the team stays shared.
Route by brand from the first message
The foundation is knowing which brand a chat belongs to before anyone types a reply. A visitor on Brand A's site should reach an agent who sees that context — the brand, the relevant knowledge, the right tone — not a generic queue where they have to explain which company they're even talking to. Routing that carries the brand context is what makes a shared team feel like dedicated ones.
Stay on-brand without separate staff
An agent covering several brands needs to switch voice cleanly — the playful tone of one brand, the formal tone of another. Per-brand canned responses and clear context cues make that switch reliable instead of relying on memory. The customer should never feel they reached someone who also handles a competitor down the hall, even when they did.
Keep the data separate, the team unified
Reporting and history should stay clean per brand, so you can see how each is really doing, even though the same people staff them all. That separation lets you make brand-level decisions — where the volume is, which needs more coverage — while still scheduling one team against the combined load rather than guessing per brand.
How MyLiveChat fits
MyLiveChat can run on multiple sites, route chats by department so brand context reaches the right agent, and keep per-brand canned responses and transcripts — so a shared team can cover several brands without blurring them. It scales from one agent upward, which suits a small team stretched across more than one front door.
Decide what is shared and what is separate, deliberately
Running chat for several brands from one team goes wrong in a predictable way: the operational
setup is decided by whatever was easiest to configure, and the customer experience follows it.
The better approach is to decide, brand by brand, which layer is shared and which is separate,
then configure to match that decision.
Four layers, and they do not have to move together:
- The widget. Almost always separate — brand name, colours, and greeting should match the site the visitor is on.
- The queue. Can be shared or split. Shared gives better coverage; split gives cleaner specialisation.
- The agents. Often shared, which is the point of the arrangement, but it puts the burden of context-switching on people.
- The reporting. Must be separable, or you cannot tell which brand is generating the workload.
The most common workable shape is separate widgets and reporting, a shared agent pool, and
queues split only where the product knowledge genuinely differs.
The context-switching problem is the real one
An agent handling three brands at once is not doing one job three times; they are switching
voice, product knowledge, and policy with every chat. Mistakes cluster exactly where you would
expect — a policy from brand A quoted to a customer of brand B, or a greeting with the
wrong company name.
Three things reduce it materially:
- Make the brand unmissable in the agent view. Whatever the interface shows, the brand should be the first thing an agent sees when a chat opens.
- Keep canned responses brand-scoped. One shared library invites the wrong policy being pasted into the wrong conversation. If tooling forces a shared set, prefix every entry with the brand.
- Batch where possible. An agent covering one brand for a block of hours makes fewer errors than one alternating all day, even though the second looks more efficient on paper.
Write down where the brands genuinely differ
Most cross-brand errors happen on a handful of policies rather than product detail. Build a
short comparison sheet covering the things agents will be asked daily: returns window, delivery
options and costs, warranty terms, refund authority, and escalation contact. One page, kept
current, visible while chatting.
The exercise usually surfaces something useful in its own right — differences between
brands that exist only because nobody ever reconciled them. Some of those are deliberate
positioning and should stay; others are accidents that could be aligned, which permanently
reduces the error surface.
If one brand is playful and another is formal, agents need guidance more concrete than
adjectives. Give each brand three or four worked examples — a greeting, a refusal, an
apology, a sign-off — written the way that brand should sound. Examples transfer; a style
adjective does not.
It is also fine for the differences to be modest. Customers notice a wrong brand name far
more than a slightly-off register, so prioritise getting the identifiable details right over
elaborate voice separation.
Agency and white-label arrangements need extra care
When the brands belong to clients rather than to you, two additional rules apply. First, be
explicit in the client agreement about who the agent appears to be, since customers reasonably
assume they are talking to the brand. Second, keep client data genuinely separated —
transcripts, contact details, and reporting for one client should not be visible to another,
and access should be scoped to the people who work on that account.
It is worth noting plainly what the platform does and does not give you here: MyLiveChat
supports separate sites with their own widgets and reporting, and the account model distinguishes
administrators from agents. Finer-grained separation than that is an operational discipline you
enforce, not something to assume the tooling guarantees.
What to measure
Report every core metric per brand, never only in aggregate — a combined response time
hides one brand being consistently underserved. Watch volume per brand against agent hours
allocated, since the split rarely matches the assumption it was set up with. And sample
transcripts specifically for cross-brand errors; they are invisible in the metrics and obvious
in the conversations.