How to run a multi-brand support desk

A multi-brand support desk lets one team run email support for several customer-facing brands from a single login and one shared queue, while each brand keeps its own support address, sender name, signature and saved replies. You structure it as one organisation, a brand per identity, and a verified mailbox per brand, then work every brand in one queue with the correct brand applied to each reply automatically.

The rest of this guide is the practical part: how to lay brands and mailboxes out so the structure stays simple, how brand-locked sending stops a reply going out under the wrong name, how a single queue keeps three busy brands readable, and how to decide which saved replies belong to one brand and which should be shared. Everything described here is shipped in Solves today.

One caveat up front: Solves is email-first and at pilot stage. It turns shared inboxes into owned tickets with replies, private notes, SLAs and multi-brand support. It does not run live chat, phone lines or social inboxes, and it is not a full contact-centre suite. If you need those channels at scale, a broader platform is the better fit.

Start with the boundary. Your organisation is the billing and security boundary: one account, one team, one set of permissions. Inside it you create a brand for every customer-facing identity, which is anything customers recognise as a distinct name when they write in.

Then attach mailboxes. A mailbox is a support address such as [email protected], and each mailbox belongs to exactly one brand. A brand can hold more than one mailbox where it makes sense, for example a support@ and a separate accounts@, but you never share one mailbox across two brands. Keep the map flat and obvious so a new teammate can read it at a glance.

Organisation	Your billing and security boundary: one account, one team, one set of permissions and reports.
Brand	One customer-facing identity: name, colour, default from-name and signature. Stays separate to the customer.
Mailbox	A support address that belongs to a single brand. A brand may have several; a mailbox has one brand.
Ticket	An owned conversation carrying its brand and mailbox, so the right identity and history follow it everywhere.

A worked example

Say an agency supports two client brands, Harbour and Kiln, plus its own accounts mailbox. That is two brands for the clients and a third for the agency itself, each with its own support address. Without a multi-brand desk it would be three inboxes, three logins and a constant risk of mixing them up. Structured this way it is one organisation, three brands, and a single team that can see exactly which brand each ticket belongs to.

Move off the shared inbox by forwarding first

You do not have to change where your email lives to start. Guided mailbox setup is forwarding-first: you forward each brand's existing support address into Solves and start owning tickets straight away, then verify the brand's domain with copyable DNS steps to switch on live sending. Until a brand's checks pass, sending stays gated, so you cannot go live with a misconfigured sender.

The single most common multi-brand mistake is answering a customer of one brand with another brand's signature, address or tone. It is easy to do when several inboxes blur together, and it quietly erodes trust. Solves makes that mistake structurally hard rather than relying on agents to remember.

Every ticket carries its brand and mailbox. When you open the reply composer it is locked to that brand and mailbox, and the from-address is read from the mailbox on the server, never from anything the browser sends. There is no free-text from-field to fat-finger. A reply for Harbour goes out as Harbour, full stop.

Changing the outbound brand on a ticket is possible, but it is a deliberate, audited admin action, not a quiet dropdown anyone can nudge. Alongside this, Solves prevents stale replies (sending against a conversation that has moved on) and keeps a wrong-brand send guard in front of outbound mail, so the safe path is also the default path.

Public replies and private notes stay separate

Brand safety is not only about the sender. Solves keeps a hard separation between public replies, which reach the customer, and private notes, which never do. Lighter collaborators can be limited to notes only, so a helper can add context to a Kiln ticket without any risk of an internal note leaving the building as a Kiln reply.

The point of a multi-brand desk is that the team works in one place. In Solves every open ticket across the brands you can access sits in a single queue, with a brand badge on each row so you always know who you are answering. A Harbour order question, a Kiln returns query and an agency invoice question can all sit together and each be answered in seconds with the right identity.

When one brand gets busy, filter the queue to it; when you want the whole picture, clear the filter. You can filter by brand, mailbox, assignee, state, priority and tag, and search across the queue, then save the combinations you use most as queue views.

• Saved views out of the box: New, Unassigned, Waiting, Snoozed, Breaching SLA, Resolved and All.
• Ticket states that map to real work: New, Open, Waiting for Customer, Snoozed, Resolved and Closed.
• First-response and resolution SLA timers with per-brand or organisation targets, with a breaching view and ageing so nothing rots.
• Reports that read across brands or filter to one: open backlog, ageing, waiting, first response, resolution, and created versus resolved.

Per-brand access without an enterprise role builder

Not everyone should see every brand. Team permissions use simple role presets plus per-brand access and ticket visibility, so you decide which brands each teammate can see and whether they can reply, add notes only, or manage that brand. A contact's previous tickets are grouped by brand, and history a teammate is not permitted to see is never exposed.

Saved replies are where multi-brand tone is won or lost. In Solves a saved reply can be scoped to a single brand or shared across the whole organisation, so you control exactly which canned answers reach which customers.

Scope to a brand anything that carries that brand's voice, policies or specifics: its returns wording, its delivery promises, its booking process. Share organisation-wide the generic, process-level replies that read the same for everyone, such as how to confirm an account email or how to raise an invoice query. The result is consistent wording per brand without rewriting the same generic reply five times.

One thing to know up front: Solves saved replies are fixed text, scoped per brand or organisation-wide. Dynamic placeholders that auto-fill a customer name or ticket field are not built yet, so write each saved reply to read well as it stands.

A practical habit: when you find yourself typing the same answer twice for one brand, save it as a brand-scoped reply; when you type it for two different brands, save it organisation-wide. Over a few weeks the library shapes itself around how the team actually works.