Zendesk Brands, Shared and Separate

A brand is a customer-facing wrapper around your single support operation. Each one gets its own name, its own subdomain or mapped host, its own logo, and optionally its own help centre.

Every ticket belongs to exactly one brand, which is what makes outbound email carry the right identity and the right signature. Behind that wrapper, one team, one queue, one set of rules.

That is the design, and it's also the constraint. Brands are a presentation layer with a few real teeth. They are not separate Zendesk instances, and treating them as though they're is the source of most disappointment.

The right column is the one to dwell on. Your users are shared, so the same person contacting two brands is one user record with one ticket history. Usually that's what you want. Occasionally, where the brands are genuinely unrelated businesses, it is a privacy conversation you should have before launch.

Triggers and macros are shared too, which means brand-specific behaviour is built by adding a brand condition to a shared rule rather than by maintaining separate rule sets. Two brands is fine. Six brands with heavy customisation each turns your trigger list into something nobody wants to inherit.

Ticket forms sit in a useful middle. The form exists account-wide, and you restrict which brands may see it. That's the mechanism that lets a retail brand and a wholesale brand ask genuinely different questions while sharing one field library. Our guide to ticket forms covers the setup.

Worth walking through, because this is the part nobody demos and the part that decides whether multibrand works for your team.

An agent works one queue. Tickets from every brand arrive in the same views, and the brand shows as a field on the ticket. When they reply, the outbound email carries that brand name, address and signature automatically. There's no brand switcher, no logging in twice, no separate inbox.

That is genuinely good when the brands are related businesses with the same product knowledge behind them. It gets uncomfortable when they are not. An agent who handles a luxury brand and a discount brand in alternate tickets needs different tone, different policies and different escalation paths, and the interface gives them one small field as a reminder.

The practical fixes are unglamorous. Put brand in the view title rather than relying on a column. Build brand-specific macros and name them with the brand first, so the list sorts usefully. And if the tone difference really matters, split the queues with views and groups so most agents mostly see one brand, even though the account technically shares everything.

Worth deciding early too: whether agents may change a ticket brand freely. Letting them is flexible and occasionally results in a reply going out under the wrong identity. Locking it down means someone has to fix miscategorised tickets. Neither answer is wrong, but pick one on purpose.