Comparaison rapide entre la version 1.0 et la version 2.0

1. Stages sont des Milestone dans un processus métier
   
2. Signals reçoivent les interactions clients
   
3. Transitions qualifient le déplacement des clients à travers les Stages
   
4. Actions sont les réponses métier aux interactions clients
   
5. Identifiers aident à reconnaître les clients dans leur parcours à travers le processus
   

1. Stages sont des Milestone
   
2. Signals capturent les interactions clients
   
3. Touchpoints sont les points d'interaction dans votre entreprise
   
4. Identifiers aident à reconnaître les clients et leurs interactions pour les cartographier en tant que parcours

Modifications apportées pour la version 2.0 :

Changement de nomenclature

1. Les États sont désormais renommés en Stages pour faciliter la compréhension.
   STATES ➙ STAGES

Remplacement des éléments de configuration

1. Les Triggers sont remplacés par Signals (service de bus d'événements dynamique de Zoho) pour capturer les événements avec plus de précision et de sophistication.
   TRIGGERS ➙ SIGNALS
   En savoir plus : Que sont les Signals ?
2. Les déclencheurs API sont programmés pour être supprimés et sont remplacés par des Signals personnalisés.
   APIs ➙ CUSTOM SIGNALS

Que signifie cette suppression pour votre organisation ?

1. Si vous avez utilisé des déclencheurs API pour des touchpoints ou des transitions, ils seront remplacés par le Signal personnalisé équivalent dans CommandCenter lors de la migration de configuration.
   
2. Comme nous n'avons pas la visibilité sur les endroits où vous avez utilisé ces API dans votre entreprise, nous ne pouvons pas les remplacer à la source de connexion. Nous vous recommandons de les remplacer avant la date de suppression pour éviter toute interruption dans le processus de capture de parcours.
   
3. Après la migration, vous pouvez afficher une liste consolidée des anciens liens par rapport aux liens remplacés (depuis le coin supérieur droit du générateur) à titre de référence. Vous pouvez copier le nouveau lien en survolant le lien pour le remplacer à la source de connexion.
   
   

Remarque : Les déclencheurs API continueront à fonctionner jusqu'à la date de suppression. Cela signifie que si vous avez associé des Signals personnalisés ainsi que l'ancienne API à un déclencheur, les API et les Signals seront tous deux invoqués pour effectuer la transition.

Changement des comportements basés sur les modules dans Journey Builder

1. Pour chaque Stage, vous devez déterminer le module.
   Par exemple, supposons que vous capturiez des leads dans deux modules différents : l'un pour les leads via les soumissions et l'autre pour capturer les visiteurs stockés en tant qu'enregistrements en fonction des instances. Il s'agit tous les deux de leads et ils devraient finalement appartenir au Stage appelé Leads. Cependant, dans la version 1.0, les Stages étaient basés sur les modules, vous deviez donc créer deux Stages : leads en provenance du site et leads en provenance des soumissions.
   
   Cela créait une duplication des efforts et vous n'aviez pas une mesure exacte du nombre total de leads capturés.

1. Les Stages ne sont que des Stages sans dépendance vis-à-vis d'un module dans CRM. Cela signifie que vous pouvez importer des enregistrements clients provenant de plusieurs sources comme différents modules standard et personnalisés et les accommoder tous dans un seul Stage. Dans notre exemple, un Stage peut accommoder des leads capturés dans plusieurs modules. De cette façon, la trajectoire peut être mesurée à partir d'une seule source.
   
   
   
   En raison de la dissociation des modules, le comportement des conditions d'enregistrement (ou conditions de transition) est également mis à jour :
1. Dans la version 1.0, les conditions d'une transition sont basées sur les champs du module configuré dans le Stage source.
2. Dans la version 2.0, vous pouvez désormais choisir les conditions des enregistrements dans les transitions en fonction des modules utilisés dans les Stages participants.
   D'après notre exemple : La condition peut être basée sur les champs du module leads, du module personnalisé ou même du module deals (destination).
   

1. Dans la version 1.0, les Actions étaient configurées pour les États et les Transitions, ce qui créait une ambiguïté.
2. Dans la version 2.0, nous avons rendu les Actions disponibles uniquement pour les Stages. Cela signifie qu'après chaque transition, une Action peut être effectuée sur les enregistrements lors de l'atteinte d'un Stage. Il existe trois types d'Actions : instantanées, programmées et récurrentes.

1. Conformément à la dissociation des Stages vis-à-vis de la liaison à un module, les Actions sont également dissociées. Cela vous donne l'avantage de configurer des Actions pour les enregistrements dans les Stages visités.
   Par exemple, supposons que vous souhaitiez envoyer un e-mail à vos clients une fois la production terminée. Comme vous pouvez l'imaginer, la production terminée est un Stage construit sur le module de file d'attente d'usine. Pour envoyer un e-mail de mise à jour en utilisant la version 1.0, vous deviez créer un autre Stage appelé mise à jour client et connecter le Contact Created étape.
2. Dans la version 2.0, vous pouvez créer cette action pour l'étape visitée (Contact créé) à partir de l'étape actuelle (production terminée) sans avoir à dupliquer les efforts.
   

Vous pouvez créer un groupe d'actions spécifiquement pour les enregistrements de l'étape provenant d'une transition spécifique. Par exemple, si vous disposez d'un modèle de proposition différent pour les enregistrements arrivés par le biais de partenaires, cette option vous permet d'agir en fonction du contexte.

Migration vers la 2.0

Éléments concernés par la migration

1. Les configurations existantes de Path Finder et Journey Builder. Cela comprend la carte configurée, les paramètres, les variables, les délais, les Signals, et autres.
   
2. Les enregistrements de journey capturés et stockés dans le module CommandCenter.
   
3. Les journaux et les notes enregistrés dans le journey.
   

Si vous craignez que ces modifications affectent vos configurations existantes ou ne causent une perte de données ou des interruptions de processus quelconques, ne vous inquiétez pas. Il y a quelques points que nous aimerions clarifier avant de procéder à la migration :

Disponibilité de la migration assistée

✅ CommandCenter 2.0 est disponible immédiatement pour les nouvelles inscriptions. La migration ne s'applique pas.

✅ Pour les organisations existantes sans utilisation, la mise à jour est automatiquement migrée progressivement. Aucune intervention du client n'est requise.

⚠️ Les organisations qui utilisent l'un des outils CommandCenter (Journey Builder ou Path Finder) verront l'option de migration s'afficher dans la vue de liste des outils.

Remarque :

1. La migration s'applique uniquement aux configurations existantes. Les nouvelles configurations créées après la date de publication seront créées dans l'interface de la 2.0.
   
2. La migration ne peut pas être interrompue ou annulée une fois lancée.
   

Testez avant de migrer

1. L'ouverture d'une configuration Path Finder en mode prévisualisation vous montrera l'aperçu de la configuration. Vous pouvez accéder aux objectifs et aux variables à partir de cette page.
   
2. De même, l'ouverture d'une configuration Journey Builder en mode prévisualisation vous montrera les configurations du journey. Vous pouvez cliquer sur les états et les transitions pour comprendre comment les actions et les Signals sont rendus dans la 2.0, et explorer les nouveaux éléments comme les objectifs et les identifiants.
   

Remarque : Le mode prévisualisation est une interface en lecture seule. Si vous tentez de la modifier, vous devrez migrer vers la 2.0 pour continuer.

Pour prévisualiser les configurations

1. Allez à Configuration > CommandCenter.
   
2. Accédez à Journey Builder ou Path Finder, survolez la configuration que vous souhaitez prévisualiser, puis cliquez sur Prévisualiser 2.0.
   
3. Vous serez redirigé vers l'interface 2.0 en mode prévisualisation.
   
4. Pour lancer la migration, cliquez sur Modifier et Oui, migrer pour lancer la migration directement à partir du mode prévisualisation.
   

Types de migration :

Migration groupée vous permet de migrer toutes vos configurations vers la 2.0 en une seule fois. Vous pouvez migrer les configurations de Journey Builder et Path Finder en une seule opération, ou choisir de migrer les configurations de chaque service séparément.

Pour migrer les configurations des deux services en groupé

1. Allez à Configuration > CommandCenter.
   La migration sera activée pour les deux services : Journey Builder et Path Finder.
2. Cliquez sur Migrer vers 2.0 et sélectionnez Migrer tous les Journeys et Path Finders.
   
3. Dans la Confirmer la migration de tous les journeys et Path Finders vers 2.0 page, cliquez sur Oui, migrer.
   

Pour migrer tous les Journeys

1. Allez à Configuration > CommandCenter > Journey Builder.
   
2. Cliquez sur Migrer vers 2.0 et sélectionnez Migrer les Journeys uniquement.
   
3. Dans la Confirmer la migration de tous les Journeys vers 2.0 ? , cliquez sur Oui, migrer. 

Pour migrer tous les PathFinder

1. Accédez à Configuration > CommandCenter > Path Finder.
   
2. Cliquez sur le bouton Migrer vers 2.0 et sélectionnez Migrer uniquement les PathFinder.
   
3. Dans la fenêtre Confirmer la migration de tous les parcours vers 2.0 ? , cliquez sur Oui, migrer. 

Pour migrer les configurations individuellement

1. Survolez la configuration, cliquez sur Migrer vers 2.0.
   
2. Dans la page de confirmation qui s'affiche, cliquez sur :
   
1. Aperçu pour afficher un aperçu avant de migrer.
   
2. Migrer vers 2.0 pour lancer la migration de cette configuration.
   
   

Liste des indicateurs que vous verrez lors de la migration

1. (Migration en cours) indique une migration en cours
   
2. Erreur API s'affiche pour les configurations comportant des déclencheurs API, qui seront abandonnés à partir du 31 mars 2026.
   
3. 2.0 indique que la configuration a déjà été créée ou migrée vers 2.0
   
4. Désactivé Migrer vers 2.0 indique un échec de la migration. En cas d'échec, notre équipe d'automatisation en sera notifiée pour corriger le problème à partir du système backend.
   

Afficher les parcours en temps réel dans 2.0

Si vous êtes éligible pour la migration, vos captures de parcours dans le module CommandCenter afficheront le bouton Afficher CommandCenter 2.0 en façade du module. Cliquez sur ce bouton pour consulter les enregistrements dans la nouvelle interface utilisateur.

Ressources de référence :

CommandCenter dans Zoho CRM