This article is for Support Enterprise customers who are currently using a Hub and Spoke setup to manage multiple brands, and are considering migrating to Multibrand to manage multiple brands.
Prerequisites for migrating to Multibrand
As you are thinking about or planning to migrate from Hub & Spoke (H&S) to Multibrand (MB) please review these key roadblocks which will prevent us from fully migrating your account to Multibrand.
Before you read the details, ask yourself if you are really using all of your spokes. We have customers who have set up Hub & Spoke but are only using the Hub. If your Spokes are not being used, or the Spokes are not sharing tickets with the Hub, then it is likely that you do not need a migration.
If you are comfortable with all the above, and you want to know more about the multibrand migration, please start with the article Customer preparation for pre- and post-Multibrand migration.
Comparing Hub and Spoke to Multibrand
This section outlines the change in behavior a Hub & Spoke (H&S) might encounter after migrating to Multibrand. We have plans to change of the Multibrand behavior for some of the items below but we do not have a specific timeline on those yet.
- Remote Authentication/Single Sign On Each Help Center redirects users to the same Single Sign On protocol and database. This is a side effect of the fact that users are per account, not per brand.
-
Chat channel branding Tickets created through Zendesk Chat are not currently aware of the brand attribute. Again, we intend to correct that in the future. In the meantime, improve the Chat multibrand setup by implementing a subset of the suggestions in the article Multibranding Zendesk Chat.
- Agent signatures There is only one signature per agent. Agents can leverage personal macros to create an agent signature for each brand.
-
End user brand identities There is currently no way to segment end-users for customer lists or NPS reports based on brand identity because we do not track which of your users has interacted with which of your brands.
- Agent permissions All agents have access to all brands by default. You can create brand views for agents to use. If restriction is required, use triggers to assign brand tickets to groups and restrict agent permissions to tickets in those groups.
-
End User permissions You cannot hide certain Help Centers to a subset of your end users. This is by design, but we’re working on a way to support segmented and privileged service based on user type. However, it is possible to prevent access to content, user portal, and communities by using Zendesk user tags and javascripts.
-
Single email templates At launch you will be limited to one html template per account. We plan to update this in the future, but for now you can create a shared HTML template and use macros to brand the text of their responses
- Ticket forms You can restrict access to specific ticket forms by brand (see Creating and applying branded ticket forms). This allows you to control the ticket forms available to end-users and agents based on the brand of the Help Center or ticket they're viewing.
-
Integrations We are working to make sure that the brand value translates over in our major integrations, including JIRA and SFDC. All other apps will need to be updated by their owners.
- Password reset and Welcome email If an end-user requests a password reset from one brand portal, they will reset the password for all brands simultaneously. The password reset and welcome emails aren’t customizable, but it will list all associated Help Centers so the end-user is aware of all the brand that the login and password reset applies.
Understanding the steps and limitations of the migration
Here are the key elements of the Multibrand migration:
-
Steps and timeline
-
Limitations
Typical steps and timeline
- Zendesk prepares your Multibrand instance.
- Zendesk migrates a sample of the content (tickets and HC articles).
- You will verify that the sample content was migrated as expected.
- Zendesk will complete the migration of content except for tickets less than closed (i.e. tickets which are in "flight").
- You will fully configure your Multibrand instance which includes workflow (macros, triggers, automations, and views) and all other settings.
- You will prepare for switchover by communicating with your customers about the upcoming downtime.
- You and Zendesk will execute the downtime tasks: Zendesk to migrate the remaining tickets and you will switch subdomains (from Spoke to Multibrand), set host mapping for each brand, and SSL.
In terms of timeline, this effort is bounded by the Zendesk resources in place for this process, migration complexity of your program, and your responsiveness in completing your tasks. Only after gathering your migration requirements will we be able to tell you what is the expected completion date for your migration.
- Tickets
- We migrate all comments, attachments, and metadata (i.e. the current value of every ticket field and tags)
- We cannot migrate the events (i.e. tag "xyz" was added by trigger 123 on Dec.12, 2014)
- Ticket # ID cannot be migrated as new tickets are created in the Multibrand instance.
- Voicemail and voice recordings are not migrated. However, we give you a complimentary access to your old Zendesk instances for reference.
- Help Center content
- We migrate articles (and Help Center attachments). Every article will have the same author after the migration (the account owner or a person you designate).
- Article creation date, comments, and subscription are not available. So it is for Section's settings and Communities content.
- Templates cannot be migrated (i.e customization made to your Help Center)
- Category or Section settings cannot be migrated. You need to reset them after the migration.
- Category, Section and Article # IDs will change upon migration. Any previous external links will need to be updated.
- User information
- We do not migration Organizations information.
- End-user, agents, groups, and organization can be migrated (it does not include custom fields, user notes and details on the above information)
- End-user passwords cannot be migrated. So if your customers are logging into Zendesk directly (i.e. has an authentication profile with Zendesk), then your customers will need to reset their password once after the migration is completed.
- Agent roles is not migrated.
- Org, lang, time zone, Details + Notes, and custom fields on the profiles are not migrated.
- Workflow
- Macros can be migrated upon your request. We migrate the text located in all Global and Group macros.
- We cannot migrate your views, triggers, and automations. You need to review these elements and adjust them for the new brand you have created.
- Dynamic content is not available for migration
- Other
- Insights reports do not get migrated
- Satisfaction ratings: not available
- Migration of "Settings" and "Channels" are not available (and it would not make much sense given the additional brands.
- Bookmarks to specific articles will send user to branded Help Center homepage (not to the equivalent article in the new branded Help Center)
- We are working to make sure that the brand value translates over in our major integrations, including Jira and SFDC. All other apps will need to be updated by their owners.
0 Comments
Please sign in to leave a comment.