Cet article est destiné aux clients Support Enterprise qui utilisent une configuration Hub et Spoke pour gérer plusieurs marques et envisagent de passer à Multimarque.
Prérequis pour la migration vers Multimarque
Si vous envisagez de passer de Hub et Spoke (H&S) à Multimarque, prenez connaissance des obstacles potentiels qui empêcheraient une migration complète de votre compte vers Multimarque.
Avant de lire tous les détails, demandez-vous si vous utilisez vraiment tous vos comptes Spoke (comptes satellites). Certains de nos clients ont configuré Hub et Spoke, mais n’utilisent que le compte Hub (compte concentrateur). Si vous n’utilisez pas vos comptes Spoke ou si vos comptes Spoke ne partagent pas les tickets avec votre compte Hub, vous n’avez probablement pas besoin d’effectuer la migration.
- Communautés de centre d’aide Vous pouvez effectuer la migration du contenu de vos communautés en utilisant l’API du centre d’aide. Pour en savoir plus, consultez les sections portant sur les sujets et les publications dans la documentation destinée aux développeurs.
- Multimarque ou Hub et Spoke Une instance Multimarque ne peut pas exister au sein d’une configuration H&S. Ces produits sont incompatibles.
Si les points expliqués ci-dessus ne vous posent pas de problème et que vous voulez en savoir plus au sujet de la migration vers Multimarque, commencez par lire l’article Étapes de la migration vers Multimarque.
Comparaison de Hub et Spoke et Multimarque
Cette section présente les changements de comportement potentiels d’une configuration Hub & Spoke (H&S) après la migration vers Multimarque. Nous projetons de modifier le comportement de Multimarque pour certains des éléments ci-dessous, mais n’avons pas encore de calendrier précis.
- Authentification à distance/Connexion unique Chaque centre d’aide redirige les utilisateurs vers le même protocole de connexion unique et la même base de données. Cela est dû au fait que les utilisateurs sont par compte et non par marque.
-
Gestion de la marque dans Zopim À l’heure actuelle, les tickets créés par le biais de Zopim ne prennent pas l’attribut de marque en charge. Là aussi, nous projetons d’y remédier ultérieurement. Entre-temps, vous pouvez améliorer la configuration Multimarque Zopim en implémentant certaines suggestions.
- Signatures d’agent Il y a une seule signature par agent. Les agents peuvent utiliser les macros personnelles pour créer une signature d’agent pour chaque marque.
-
Identités de la marque des utilisateurs finaux Il n’est actuellement pas possible de segmenter les utilisateurs finaux dans les listes d’utilisateurs en fonction de l’identité de la marque, car nous n’effectuons pas de suivi permettant de savoir quel utilisateur a interagi avec quelle marque.
- Permissions des agents Par défaut, tous les agents ont accès à toutes les marques. Vous pouvez créer des vues de marque pour les agents. Si vous avez besoin d’implémenter des restrictions, utilisez les déclencheurs pour affecter les tickets de marque à des groupes et limitez les permissions des agents aux tickets de ces groupes.
-
Permissions des utilisateurs finaux Vous ne pouvez pas rendre certains centres d’aide invisibles à un sous-ensemble de vos utilisateurs finaux. C’est intentionnel, mais nous travaillons à développer une façon de prendre en charge un service segmenté et avec permissions en fonction du type d’utilisateur. Cependant, il est possible d’empêcher l’accès au contenu, au portail utilisateur et aux communautés en utilisant JavaScript et les marqueurs de l’utilisateur Zendesk.
-
Un seul modèle d’e-mail Au départ, vous serez limité à un modèle HTML par compte. Nous projetons de changer cela, mais pour l’instant, vous pouvez créer un modèle HTML partagé et vous servir des macros pour ajouter des éléments de marque au texte des réponses.
- Formulaires de ticket Vous pouvez restreindre l’accès à certains formulaires de ticket par marque (consultez Création et application de formulaires de ticket de marque). Cela vous permet de contrôler quels formulaires de ticket sont à la disposition des utilisateurs finaux et des agents en fonction de la marque du centre d’aide ou du ticket qu’ils consultent.
-
Intégrations Nous nous efforçons de faire en sorte que la valeur des marques se retrouve dans nos principales intégrations, notamment Jira et SFDC. Toutes les autres applications doivent être mises à jour par leurs propriétaires.
- Réinitialisation du mot de passe Si un utilisateur final demande la réinitialisation de son mot de passe à partir du portail d’une marque, son mot de passe est réinitialisé pour toutes les marques en même temps. L’e-mail de réinitialisation du mot de passe n’est pas personnalisable, mais il répertorie tous les centres d’aide associés pour que l’utilisateur final sache où son mot de passe a été mis à jour.
Étapes et limites de la migration
Voici les éléments clés de la migration vers Multimarque :
-
Étapes et calendrier
-
Limites
Étapes et calendrier typiques
- Vous configurez votre instance Multimarque (paramètres, canaux, marques, rôles d’agent, etc.)
- Zendesk migre un échantillon du contenu (tickets et articles du centre d’aide).
- Vous vérifiez que la migration de l’échantillon du contenu s’est bien déroulée comme prévu.
- Zendesk termine la migration du contenu, à l’exception des tickets avec un statut inférieur à Clos (c’est-à-dire les tickets en cours).
- Vous configurez votre workflow dans Multimarque (macros, déclencheurs, automatismes et vues).
- Vous vous préparez à la dernière étape de la migration en communiquant à vos clients le temps d’indisponibilité auquel ils doivent s’attendre (messages dans les centres d’aide des comptes Spoke et potentiellement un e-mail d’avertissement).
- Tâches du temps d’indisponibilité : Zendesk effectue la migration des tickets restants et vous changez de sous-domaine (des comptes Spoke à Multimarque) et configurez le mappage d’hôte pour chaque marque.
En termes de calendrier, ce processus dépend des ressources Zendesk disponibles, de la complexité de votre migration et de la rapidité à laquelle vous effectuez les tâches qui vous incombent. Nous ne pourrons pas vous donner la date prévue pour la fin de la migration avant d’avoir recueilli vos spécifications pour la migration.
- Tickets
- Nous migrons tous les commentaires, toutes les pièces jointes et toutes les métadonnées (c’est-à-dire la valeur actuelle de chaque champ de ticket et les marqueurs).
- Nous ne pouvons pas migrer les événements (p. ex., le marqueur « xyz » a été ajouté par le déclencheur 123 le 12 décembre 2014).
- L’ID des tickets ne peut pas être migré, car les nouveaux tickets sont créés dans l’instance Multimarque.
- Contenu du centre d’aide
- Nous migrons les articles (et les pièces jointes). Chaque article aura le même auteur après la migration (le propriétaire du compte ou une personne désignée de votre choix).
- La date de création, les commentaires et les abonnements ne sont pas disponibles pour les articles, les paramètres des sections et le contenu des communautés.
- Les modèles ne peuvent pas être migrés (c’est-à-dire les personnalisations de votre centre d’aide).
- Les paramètres de catégorie et de section ne peuvent pas être migrés. Vous devez tous les réinitialiser après la migration.
- Les ID des catégories, des sections et des articles changeront au moment de la migration. Tous les liens externes préalables devront être mis à jour.
- Informations sur l’utilisateur
- Les utilisateurs finaux, les agents, les groupes et les organisations peuvent être migrés (cela n’inclut pas les champs personnalisés, les notes des utilisateurs et les détails au sujet des informations ci-dessus).
- Les mots de passe des utilisateurs finaux ne peuvent pas être migrés. Donc si vos clients se connectent à Zendesk directement (c’est-à-dire qu’ils ont un profil d’authentification auprès de Zendesk), ils devront réinitialiser leur mot de passe une fois la migration terminée.
- Les rôles d’agent ne sont pas migrés.
- Les organisations, les langues, les fuseaux horaires, les détails, les notes et les champs personnalisés des profils ne sont pas migrés.
- Workflow
- Les macros ne peuvent pas être migrées.
-
Nous ne pouvons pas migrer vos vues, vos déclencheurs ni vos automatismes (cela n’aurait pas grand sens puisque vous devriez tous les passer en revue et les adapter à la nouvelle marque que vous avez créée).
-
Le contenu dynamique n’est pas disponible pour la migration.
- Autre
- Notes de satisfaction : indisponibles
- La migration des paramètres et des canaux n’est pas disponible (et cela n’aurait pas grand sens du fait des marques supplémentaires).
- Les marque-pages pour des articles spécifiques dirigeront l’utilisateur vers la page d’accueil du centre d’aide de marque (et non l’article équivalent dans le nouveau centre d’aide de marque).
- Nous nous efforçons de faire en sorte que la valeur des marques se retrouve dans nos principales intégrations, notamment Jira et SFDC. Toutes les autres applications doivent être mises à jour par leurs propriétaires.