Brand Migration Guide

Zendesk's multi-brand feature provides a great tool to expand operational capacity and increase the functionality available to the teams who leverage it. There are a great number of articles describing the capabilities and best practices for using it. One area that we often see come up but less discussed is around the logistics of splitting out a new brand from an existing one.

The main goal of this article is to provide general guidance on preparing for and performing the brand migration; however, it is not expected to be able to cover all angles of every project, and so in addition to the recommendations within, an admin performing this task is expected to evaluate the unique circumstances of each case and adjust accordingly.

Preparing for migration:
In order to prepare for a brand migration, the two main areas of focus are on the operational or business requirements, and the Zendesk specific solution.

The business requirements are by their nature specific and unique to each organization. While there are some general cases such as creating a new vertical or splitting up a regional team into more separate countries, each team must evaluate their own needs. There are a few examples listed below and in the Zendesk articles.

Evaluating the Zendesk solution:
Before preparing for the migration, an admin should feel confident and capable with regards to the Zendesk multi-brand feature set. We recommend reading the following Zendesk support articles as a baseline.

We have found the most concise explanation of multi-brand is that brand in Zendesk is like any ticket field. It is an attribute or data point that can be set on any ticket, and in general it can be used in Zendesk like any other drop-down ticket field. In addition, there are some brand specific features to be aware of, including the following:

Brand is the field at the very top of the ticket form, so its location is more prominent than other fields.
Brand can be used to group ticket forms.
Brand can have its own Help Centre and channels, including email, web widget, talk, SDK.
Brand can have its own signature.

Sample Case:

Northwoods Coffee is an expanding business in the coffee industry. Originally starting out as a provayer of high-quality coffee beans to local vendors, they have expanded to include a retail business, several coffee shops, providing coffee-related equipment, and branched out into other beverages.

Currently Northwoods coffee has three brands: Northwoods coffee, which was the original brand and is the default; Northwoods beverages which covers other beverages including teas and other exotic beverages like ramon; and Northwoods Coffee shops which covers the coffeeshops specifically.

Adding the additional two brands was quite straightforward. Coffeeshops was set up as part of the original Zendesk implementation and had its workflow designed accordingly. When other beverages were added to the product line, they were distinct enough that the entire operations was set up with its own requirements.

Now, adding in a new brand to cover coffee-related equipment requires untangling the relationships between different product areas. We need to ask operational questions like, which processes are the same and which are dissimilar? Which resources can be shared and which must be unique? Then we need to focus on the specifics of Zendesk, which we will outline below:

How do we add a new brand?
Which resources have a brand specific component?
Are you using the new Brand Spaces feature?

Brand
The new brand must be created and set up accordingly. This includes name, subdomain, logo, signature and channels.
Groups
Is a new group required to support the brand tickets? Are existing agents required to have their group memberships updated, either added to the new group(s) or removed from the existing ones?
SLA Policies
Are any new SLA Policies required to support the new brand workflow? Is brand being used as a condition to set the SLA policy? If so, the condition will need to be updated - see below.
Ticket Forms
Do new ticket forms need to be created to support the workflow? Do any existing ticket forms need to be added to the new brand or removed from existing brands?
Views
Should new views be set up to show the tickets from the new brand? Are there any brand conditions in existing views that need to be updated? (see more below)
Macros
Are there any actions in the macros that set the brand? Do they need to be updated for the new brand? Do new macros need to be created for the new brand?
Schedules
Is a new schedule required for the brand? Make sure to update the business rules that set the schedule to include the new brand.
SLAs
Do any of the SLAs use brand as a condition? Do they need to be updated to include the new brand, or should new one(s) be set up for the new brand?
Triggers
Do any of the triggers use brand as a condition or set brand as an action? If so, then they may need to be updated to move brand to an Any instead of an All condition, or to be cloned in order to set the new brand for the new tickets.
Automations
Will new automations need to be set up for the new brand? Sometimes there is one automation per brand based on the conditions, and so a new one may need to be created. Or, the conditions can be updated to use an Any condition and either brand rather than an All condition with just one brand.
Channels
A web widget can be created for each brand, and so a new one may need to be created for each one. Facebook, X, Messaging and others can be configured for each brand, and so must have the same consideration as other channels. Mobile SDK may also require changes depending on account specific set up.
Email
Each brand can receive its own support email address. A new custom support address can be created for the brand, and emails will need to be forwarded to the new brand. In addition, some changes may be needed in the email template to accommodate the new brand.
Help Centre
Each brand can have its own Help Centre, and so a new Help Centre may need to be created for the new brand. Content may need to be migrated from the existing Help Centre to the new Help Centre (check on migrating content).
Routing
Routing configurations can also take brand into consideration and should be updated accordingly.
Custom Apps and Integrations
Any custom apps or integrations that use brand as a setting or set brand upon ticket creation may need to be updated as well.
Others
Chat, Talk, Reporting all may require updates.
Brand Spaces (new)
Are agents set up in brand spaces?

Updating conditions (Views, SLAs, Triggers, Automations)
For the resources that have a condition component, we have taken a three-step approach. First, we will take existing conditions including brand A inside of the All area and move into the Any area. There, we will set the conditions as either Brand A or Brand B. This will allow the workflow to continue as normal for all existing tickets, and also allow new tickets to work just fine in the rules once tickets start flowing to the new brand. Then, once we have cutover to supporting the new brand, we will do a validation phase. Once validation passes, we will remove brand A from the any conditions and move brand B into the all.

Final notes: Zendesk provides a helpful tool to analyse parameters used in different business rules and settings, but unfortunately it doesn't cover brand. We have built our own custom tool to do the analysis. You may be able to export your data using your own development resources, or look into third-party apps or integrations to help with the export.

In summary, there are myriad business cases for when a new brand may need to be added. We hope this guide can provide a brief description of considerations when setting up the new brand, both from an operational perspective as well as from a Zendesk product perspective.