Vous avez donc décidé de migrer depuis une autre application vers Intercom et vous souhaitez conserver vos données historiques. Et maintenant ?

Aperçu général du processus

Descriptions des étapes

Planification - définissez l'approche que vous adopterez : qui sera responsable de la migration, si des conversations ou des tickets seront créés dans Intercom, comment vous créerez les contacts dans Intercom, etc.
Configuration d'Intercom - au minimum, les bases (attributs) doivent être configurées dans Intercom pour compléter l'exercice de correspondance.
Correspondance - un exercice pour définir comment les entités et attributs existant dans la configuration actuelle de votre application seront mappés aux entités et attributs dans votre nouvelle configuration Intercom.
Script d'exportation / importation (la version la plus technique de cette étape) - créez le processus et les scripts pour soit récupérer et convertir votre export Zendesk en JSON, soit appeler les APIs Zendesk pour récupérer les données de contact et de ticket, et appeler les APIs Intercom pour créer des conversations / tickets.
Test par lots (UAT : User Acceptance Testing) - une fois la version 1 des scripts terminée, effectuez un test par lots sur un sous-ensemble de tickets afin de faire des mises à jour et d'itérer sur les scripts.
Exécution initiale - lorsque les scripts sont finalisés, vous définirez la « Date Delta » comme un point fixe dans le temps pour ne collecter que les tickets Closed jusqu'à cette date/heure. Ces tickets Closed peuvent maintenant être migrés vers votre environnement de production Intercom prêt au lancement mais non en direct.
Basculage & Deltas - lorsque vous êtes prêt à basculer depuis Zendesk, ce qui inclut le transfert de vos emails Support vers Intercom et/ou le lancement du Messenger Intercom pour le chat en direct, nous pouvons maintenant migrer les tickets restants qui ont été fermés depuis la date/heure Delta ainsi que tous les tickets Open / Pending.

Planification

La première question à se poser est « pourquoi ai-je besoin de ces données ? » La réponse influencera la structure et le style de votre migration.

Si vous avez besoin des données uniquement pour la conformité réglementaire, vous pouvez envisager si vous souhaitez ces données dans une base que vous pouvez interroger plutôt que dans Intercom.
Si vous avez seulement besoin des données dans Intercom pour que vos nouveaux rapports Intercom incluent les données historiques, il est recommandé de migrer les données sous leur forme la plus simple (évitez la migration message par message). Le processus clé ici est de s'assurer que les valeurs des attributs après migration complètent vos nouveaux processus afin que les rapports soient cohérents.
Si vous avez besoin des données pour fournir le contexte des interactions historiques d’un utilisateur afin de résoudre ses problèmes aujourd’hui, vous pouvez toujours migrer les tickets sous leur forme la plus simple, mais cela justifierait le plus la migration message par message. Gardez à l'esprit que cela augmentera le nombre total d'appels API à Intercom de 10 à 100 fois.
Si c’est une combinaison des raisons ci-dessus, il est recommandé de migrer dans Intercom !

Correspondance

Maintenant que vous avez confirmé pourquoi vous migrez vos données, l’étape suivante est de vous demander « Quelles données doivent être migrées depuis mon système source et sous quel format ? »

Gardez à l'esprit :

Chaque ticket ou conversation doit être associé à un utilisateur ou lead existant (il y a un enregistrement de contact pour chaque utilisateur final identifiable).
- Ces contacts seront-ils créés dans le cadre de la migration ou importés au préalable ?
- Ces contacts ont besoin au minimum d’un user_id (de votre produit) ou d’une adresse email.
Chaque ticket / chat / etc. source sera-t-il migré en tant que Conversation Intercom ou Ticket Intercom ?

Conversations vs. Tickets : lequel choisir ?

C’est l’une des décisions les plus importantes à prendre avant de commencer le scripting. Le choix affecte les endpoints API que vous utilisez, la structure des données dans Intercom, et ce que vos clients et agents verront.

Conversations — idéal si vos tickets Zendesk étaient principalement des interactions de support client (email ou chat). Les Conversations sont visibles dans le Messenger Intercom et supportent la communication en temps réel. Utilisez les endpoints Create conversation, Update conversation, Reply to conversation, et Manage conversation.
Tickets — idéal si vos tickets Zendesk étaient des demandes structurées et traçables (par exemple rapports de bug, demandes de fonctionnalités, tâches back-office) qui ne nécessitent pas un fil en direct côté client. Les Tickets ont des états définis et des attributs personnalisés. Utilisez les endpoints Create ticket, Update ticket, et Reply to ticket.
Vous pouvez migrer certaines données historiques en tant que Conversations et d’autres en tant que Tickets — mais essayez de limiter le nombre de structures différentes que vous créez, car cela ajoute de la complexité à vos scripts et à la validation des données.

Si vous souhaitez conserver les données historiques à la fois dans Tickets et Conversations dans Intercom (par exemple migrer des tickets Zendesk vers des conversations Intercom tout en conservant les enregistrements de tickets), vous devrez exécuter des scripts d’importation séparés pour chaque structure. Planifiez cela pendant votre phase de Correspondance avant d’écrire des scripts.

Pour importer des users depuis Zendesk, vous pouvez :
- Exporter les users au format CSV depuis Zendesk
- Accédez à Contacts > People dans Intercom et cliquez sur 'New Users or Leads', puis sélectionnez 'Import People'
- Téléchargez votre fichier CSV et mappez les attributs en conséquence

Ce n’est pas parce qu’un élément était un ticket dans Zendesk qu’il doit être un ticket dans Intercom. Nous avons des conversations temporelles qui peuvent être soit chat soit email, des tickets orientés client, et des tickets back-office — TOUS ayant des méthodes pour communiquer avec les clients.

Essayez de limiter le nombre de structures différentes que vous créez car cela ajoute de la complexité.

Identifiez quels attributs vous migrerez et à quoi ils doivent être mappés dans Intercom (tickets & contacts).
Identifiez et planifiez les cas limites potentiels.
À la fin de cette phase, vous avez un tableau ou un diagramme détaillant tout ce que vous souhaitez migrer et son équivalent dans Intercom !
Pour éviter les profils en double :
- Assurez-vous que les user IDs dans Zendesk correspondent à ceux dans Intercom
- Définissez les correspondances d’attributs entre Zendesk et Intercom avant de lancer la synchronisation
- N’oubliez pas que les modifications des user IDs via CSV après migration ne sont pas supportées (utilisez plutôt l’API d’Intercom)

Scripting

Il est maintenant temps de revoir le plan avec votre Implementation Engineer (IE).

Note : Ordre des opérations — lors d’une migration manuelle via l’API, vous devez compléter les étapes dans cet ordre sous peine d’échec des imports :

Créez ou importez d’abord les contacts. Chaque conversation ou ticket doit être lié à un contact existant. Les contacts nécessitent au minimum un user_id ou une adresse email.
Créez des attributs de données personnalisés (y compris les attributs de données de conversation). Ceux-ci doivent exister dans Intercom avant d’importer les conversations, afin que les valeurs des attributs soient correctement mappées.
Importez les conversations ou tickets. Ceux-ci ne peuvent être créés qu’une fois que les contacts qu’ils référencent existent déjà dans Intercom.

Tenter de créer des conversations ou des tickets avant que leurs contacts associés n'existent entraînera des erreurs.

C'est une occasion pour les deux parties de revoir le plan et de poser toutes les questions de clarification avant de créer les scripts.
Votre script changera en fonction de si vous préimportez le contact associé ou si vous créez le contact (user ou lead) dans le cadre du processus.
Le cadre général pour la création d'une conversation ou d'un ticket est :
- Récupérer les détails du ticket depuis Zendesk.
- Soit rechercher et associer le demandeur à l'user Intercom, soit créer l'enregistrement user et mettre à jour ses attributs.
- Créer la conversation / ticket en identifiant le canal.

Vous créez la conversation en simulant un message entrant du client (important pour la visibilité dans le Messenger).

Mettre à jour les attributs, pièces jointes et l'affectation (équipe & coéquipier) de la conversation / ticket
Répondre à la conversation avec un message sortant vers le client ou en ajoutant une note

Utilisez cette réponse pour publier la transcription COMPLÈTE de la conversation (corps) depuis Zendesk plutôt que le message par message.

Si vous répondez au client et avez créé une conversation sur canal email, ces notifications seront envoyées au client sauf si vous n'êtes pas en direct dans l'espace de travail ou si vous supprimez toutes les notifications email (nous pouvons vous aider avec cela).

Gérer l'état de la conversation / ticket

Tous les tickets fermés passeront d'abord par le processus d'ouverture, de mise à jour et de réponse avant d'être fermés par cet appel. Il est important ici de s'assurer que tous les workflows qui agiraient sur les conversations ont une exception dans les règles de déclenchement pour « Created via API » ou sont temporairement désactivés pendant la migration.

Test par lots

À ce stade, vous devriez avoir une version fonctionnelle du script de migration configurée et pouvez commencer les tests en migrant un sous-ensemble de données d'exemple dans votre espace de travail TEST.
Vérifiez soigneusement les résultats de ces tests et collaborez avec votre IE pour effectuer les ajustements nécessaires.
Si vous avez acheté un package de migration auprès des Services d'Implémentation Client Intercom et que nous le faisons pour vous, nous vous demanderons seulement de valider les résultats et nous effectuerons les mises à jour nécessaires !

Basculement

La façon dont vous prévoyez d'aborder la migration des tickets ouverts dans Zendesk influencera la planification de votre calendrier de basculement.
Drain and Fill :
- Avec cette approche, vous basculez vers Intercom avant votre date de lancement officielle afin que toutes les nouvelles demandes de support arrivent dans Intercom. Votre équipe de support travaillerait sur les deux plateformes jusqu'à ce que tous les tickets ouverts restants dans Zendesk soient fermés.
- Après la fermeture de tous les tickets Zendesk restants, vous effectuerez votre dernière migration par lots. En effet, cette approche ne migre pas du tout les tickets ouverts, mais attend que tous les tickets soient fermés dans Zendesk avant de les transférer.
Basculement en direct :
- Avec cette approche, vos équipes synchroniseraient le basculement vers Intercom pour coïncider avec l'exécution de la migration finale contenant uniquement les tickets ouverts.
- Cette approche nécessite une coordination bien plus grande que le drain and fill, car tout devra être redirigé vers Intercom pendant que les tickets ouverts sont migrés.

Points de terminaison API Zendesk pertinents (pour la récupération)

Points de terminaison API Intercom pertinents (pour la création)

Migration

Le plan est concret, le script de migration est terminé et affiné, il est maintenant temps de transférer vos données !