Multi-brand customer support with one team is common for owners of two to five online shops and for agencies that run chat for their clients. The people are shared, yet each brand has its own offer, prices, tone and promises. The worst damage rarely comes from a slow reply. It comes from a reply sent on behalf of the wrong company: with another brand's terms, another delivery date or a greeting from a different site.
This guide is about organising the work: when to keep websites apart, how to record assignments, what to prepare separately for each brand and how to switch between them without mistakes. It does not cover several languages on one website; that topic has its own guide on multilingual customer service.
Separate websites or one: when to split brands
A working rule: if customers see two different companies, your team should see them separately too. A separate website in your tool means its own widget, its own conversation history and its own data. One shared website with departments makes sense when there is a single brand and only the product lines differ. The table below helps you decide for each pair of brands.
Scroll the table sideways to see all columns.
| Question | Lean towards a separate website | Lean towards a shared website |
|---|---|---|
| Do customers know both brands as one company? | No, they are different shops or agency clients | Yes, one company with several offers |
| Are the terms and prices different? | Yes, different return and delivery rules | No, the rules are shared |
| Who should see the conversations? | Only people assigned to that brand | The whole team |
| Do you need a separate report? | Yes, for example for an agency client | A split by department is enough |
| Does the tone of replies differ? | Yes, different form of address and wording | No, one tone for everything |
In its multibrand documentation, Zendesk gives every ticket a brand and lets agents see only the tickets of brands they belong to; the feature is available on selected plans. Zendesk: About multibrand. The page describes one product's options; it does not prove that splitting brands always beats a shared inbox.
If you are also moving several brands from different tools into one, check history export and the transition period first, as described in our guide to changing customer service systems. Record the website split before the migration, because it is harder to reverse later.
Who handles which website
A shared team does not mean everyone answers everywhere. A fictional example: an owner runs a tea shop and a ceramics shop, with two people on chat and one person for complaints. Without a written map, both chat agents check both shops, and each assumes the other has already replied. An assignment map removes that assumption.
- List websites and their hours.For each brand, note support hours and the promised response time. Brands may keep different hours even with the same people.
- Assign a lead and a backup.Each website has one person responsible for its queue during a shift, plus a backup for absences.
- Grant access only where needed.Someone working on one brand does not need to see the other brand's conversations. Less access means fewer chances to slip.
- Review the map after every team change.A new hire, a holiday or a new brand is the moment to recheck assignments before a customer falls into a gap.
Inside a single website, the usual split into departments and a case owner still applies, as explained in our guide to assigning customer requests. If you have two brands and a team of three, start with the minimum from our article on customer service in a small company and add settings only after that.
In its FAQ, LiveAgent suggests supporting several brands from one account through separate departments and a separate knowledge portal for each brand. LiveAgent FAQ. It describes one tool rather than measuring results; it only shows that the vendor itself plans for a split by brand.
Greetings, macros and help articles for each brand
The most frequent mistake in a shared team is shared macros. A returns answer copied from one brand to another carries the wrong deadline, the wrong address and the wrong form of address. Prepare a separate set for each website instead: the widget greeting, macros for the most common replies and help articles with that brand's rules.
Do not copy whole sets from one brand to the next. Build them from a skeleton, as described in our guide to customer service response templates, and add a tone decision for each brand. If one brand addresses customers informally and the other formally, write that down; our guide on how to address customers helps with the choice.
Brand: [name]. Form of address: informal / formal. Greeting: [first sentence in the widget]. Sign-off: [how we end a message]. Returns and delivery: [link to help article]. Words we avoid: [list]. Lead and backup: [names].
Switching context without slipping into the wrong tone
With several brands, mistakes rarely come from not knowing the answer. They come from writing for another company a minute ago and carrying the habit into the next conversation. A short routine before the first reply after switching websites helps. It takes a few seconds and protects you from a message you cannot take back.
- The website name in the panel matches the brand the customer is asking about.
- The macro you insert comes from this website's set.
- Dates, prices and terms in the reply come from this brand's rules.
- The form of address matches the brand card.
- Any link in the reply points to the same brand's domain.
Take extra care with customers who buy from two of your shops. If they ask in one shop about an order from the other, answer in the context of the brand where they asked and point them to the other brand's channel. Do not merge both matters in one message. We cover customers writing in several places at once in our guide to one enquiry across several channels.
How to set it up in Meetlead
In Meetlead, you set up brands as websites within one workspace. Each website has its own identifier, domains and widget configuration, including greeting texts. Conversations, customers, analytics, tags, schedules, macros, the knowledge base and help articles are isolated per website. The plan, limits and team belong to the workspace. You will find an overview on the Customers and team page.
A team invitation sets the role and the allowed websites, and chat availability and schedules are configured separately for each website. In the panel, the workspace and website switcher sits in the sidebar, and each browser tab remembers its own choice, so you can keep two brands open side by side. Meetlead has no shared inbox across all websites: you always work in the context of one. The number of websites and domains depends on your plan, and customer profiles are not merged between websites.
A report for each website
One combined figure for all brands hides problems. If one brand gets fast replies while the other waits until the next day, the average looks fine and nobody reacts. Review the numbers separately for each website: conversation volume, first response time, cases without an owner and the most common topics.
Once a month, compare those numbers with the assignment map. If one brand is growing while the same person still handles it, that is a signal to change assignments, not to add pressure. An agency can hand a client a report covering only that client's website, without anyone else's data. Also note which macros and help articles each brand received after the review, so the next report shows whether the change worked.
Questions about supporting several brands
Can one person handle two brands at the same time? Yes, if they have access to both websites and follow the context-check routine. With heavy traffic, it is better to set a main brand for each shift and treat the second as backup. Two open tabs with different websites help, but they do not replace checking the brand name before sending.
Will customers of one brand see that the same team supports them? Not necessarily. Customers see the greeting, name and look of that website's widget. In Meetlead, an agent's public alias belongs to the workspace, so it is the same on every website; pick a name that fits each brand. Do not hide information customers should know, though, such as which company they have a contract with.
