Blueprint et Journey Builder dans Zoho CRM

Blueprint et Journey Builder dans CRM peuvent présenter des similarités techniques en termes de composants du générateur — notamment les États, les Transitions et les actions automatisées.

Cependant, puisqu'ils diffèrent principalement par leur objectif et leur finalité, il ne devrait y avoir aucune confusion quant à ce qu'ils visent à accomplir.

La confusion éventuelle entre Blueprint et Journey Builder pourrait provenir du fait que les deux solutions disposent de blocs de construction similaires — États, Transitions et Actions. Cela s'explique par le fait que les deux solutions sont développées selon le concept de machine à états finis (FSM).

En savoir plus sur les systèmes de gestion des processus et un aperçu des capacités de processus dans Zoho CRM.

Machine à états finis (FSM) — Le modèle à la base des générateurs de processus

Une machine à états finis (FSM) est un système qui peut se trouver dans un seul état parmi plusieurs états possibles à un moment donné. Lorsqu'elle reçoit une entrée, elle peut se déplacer vers un état différent selon des règles prédéfinies. Elle se compose d'états, d'un état initial et de transitions entre les états. Elle est largement utilisée pour concevoir des systèmes séquentiels dans les domaines des logiciels, des jeux vidéo, de l'IA et bien d'autres.

Parmi les exemples concrets de FSM, on peut citer les portiques de contrôle d'accès à jetons, largement présents dans les gares du métro, ou encore les ascenseurs, les cadenas à combinaison et les distributeurs automatiques. Un portique ne peut se trouver que dans deux états — verrouillé ou déverrouillé — il y a donc deux états (finis). Pour passer de l'état verrouillé à l'état déverrouillé, il faut une pièce de monnaie. La pièce déclenche la transition entre l'état A et l'état B. Une fois déverrouillé, une pièce ne le remet pas à l'état verrouillé — il faut le tourner et le remettre en position d'une certaine manière. De même, sans pièce, vous ne pouvez pas l'ouvrir non plus. C'est donc un système clair et infaillible — insérez une pièce pour franchir le portique.

Dans le domaine des logiciels, diverses solutions BPM ont été modélisées selon le concept de machine à états finis, et sont donc vouées à être similaires. Elles sont toutes susceptibles de disposer d'états et de transitions, car c'est ce que la méthode de machine à états finis implique principalement.

Par conséquent, Blueprint et Journey Builder dans Zoho CRM, qui sont tous deux modélisés selon le concept de machine à états finis, contiennent les mêmes blocs de construction — États, Transitions et Actions. Cependant, la manière dont vous utilisez ces composants diffère, car les objectifs des deux solutions sont différents. Voici quelques facteurs fondamentaux de différence entre les deux.

Objectif principal

Blueprint est un outil de gestion des processus métier visant à promouvoir la conformité, tandis que Journey Builder est un outil pour optimiser le parcours client à travers les points de contact commerciaux.

États dans un processus ou états dans un parcours

Les États dans Blueprint sont construits à partir des valeurs de liste de sélection présentes dans la mise en page d'un enregistrement. Parce qu'il aide à gérer la conformité, Blueprint vous permet de considérer les valeurs de liste de sélection, comme le statut du lead ou l'étape de la transaction, comme des étapes et vous aide à gouverner la progression d'un enregistrement à travers différentes étapes depuis sa création.

Les États dans Journey Builder indiquent la position du client dans l'ensemble de son parcours d'achat. Cet état peut être associé à un module CRM. Par exemple, lorsqu'un visiteur s'inscrit pour votre produit, il peut alors être classifié comme un lead et son entrée de formulaire web pourrait être indiquée dans le Journey comme un état appelé Lead Created mappé au module Leads. Lorsqu'ils progressent dans le Journey, vous devez indiquer au CRM le module sur lequel ils doivent être mappés, afin de maintenir un suivi. De plus, les États dans Journey Builder sont des états en forme libre, c'est-à-dire que vous pouvez créer un État de votre choix lors de la construction de votre Journey. Ils ne proviennent pas spécifiquement d'un champ de liste de sélection et n'ont pas besoin d'être prédéfinis, contrairement à Blueprint.

Transitions ou déclencheurs

Blueprint guide les équipes de vente à travers un processus systématique. Dans le cadre de ce pilotage, Blueprint sollicite des données auprès des équipes à chaque étape, valide les données reçues et automatise les actions routinières, promouvant ainsi la conformité de manière transversale. L'exécution réussie d'un mandat, qu'il s'agisse de saisir des champs, de récupérer des pièces jointes ou de cocher des cases de contrôle, fait passer l'enregistrement d'un état à un autre.

Avec Journey Builder, il n'est pas question de « collecter des données » ou de guider des équipes, car ce n'est pas l'objectif. L'objectif est d'orchestrer une série d'événements en fonction d'un résultat antérieur. Par exemple, une visite sur le site web devrait déclencher un message de chat en direct pour un visiteur, et une réponse de chat ultérieure devrait alerter un agent ainsi qu'envoyer un accusé de réception à l'e-mail du client. Cet e-mail devrait par la suite déclencher des rappels de suivi auprès de l'agent pour traiter le message de chat. Dans cet exemple simple, vous pouvez voir comment l'objectif est d'automatiser une série d'actions ou d'événements pour offrir une expérience agréable au client. Ce n'est pas seulement pour un seul client, mais chaque client visitant le site web et utilisant le widget de chat bénéficiera de cette expérience. Par conséquent, tout cela vise à rationaliser le parcours client de manière transversale.

Ce qui fait passer un client d'une étape à une autre dans son parcours d'achat, ce sont les signaux ou événements reçus, qui le déclenchent ou le propulsent en avant dans le parcours. En fonction de ces déclencheurs, les actions ultérieures sont formulées. Le bloc de transition ici n'est donc pas un mandat de données, mais des signaux ou des événements. Exemples : Ouverture d'un e-mail, Réponse à une enquête, Création d'un ticket support, et ainsi de suite.

 

Facteurs de différence	Blueprint	Journey Builder
Objectif	Gestion de la conformité	Optimisation du parcours client
Pour qui est-ce conçu ?	Équipes internes de l'organisation	Clients
Définition d'un État	Chaque étape du processus métier. C'est-à-dire, les valeurs du champ de liste de sélection Statut choisi.	L'étape dans laquelle se trouve un client dans son parcours d'achat.
Définition d'une Transition	La Transition dans un Blueprint prescrit les directives à suivre, les actions à effectuer et les données à soumettre par l'utilisateur ou l'équipe désigné(e). L'accomplissement des actions prescrites fera passer l'enregistrement d'un état à un autre.	Une transition dans Journey Builder indique les signaux/déclencheurs/événements qui, lorsqu'ils sont rencontrés, font passer un enregistrement d'un état à un autre.
Exemple d'états et de transitions.	État 1 : Demande reçue État 2 : Brief des besoins créé Transition entre les états 1 et 2 : Créer un brief Joindre un document Ajouter une note sur la demande Ajouter les champs obligatoires : « Produit/Service requis. » Cela signifie qu'après la réception d'une demande, l'étape suivante consiste à vérifier et ajouter les coordonnées correctes. Ce n'est que lorsque les champs Téléphone et e-mail auront été remplis qu'il passera à l'étape suivante « Demande cultivée ».	État 1 : Lead créé État 2 : Lead intéressé Transition (Signал/événement) entre les états 1 et 2 : E-mail ouvert Lorsque le lead a « Ouvert l'e-mail », qui a peut-être été envoyé dans le cadre de l'État 1. L'ouverture de l'e-mail est donc un signal ou un événement pour que le CRM reconnaisse et fasse passer le prospect du point 1 au point 2 de son parcours.

 

FAQ

Est-il exact de dire que, dans Zoho CRM, Command Center est un « Blueprint multi-modules » ?

Non. Ce n'est pas exact de dire cela, car Blueprint et Command Center (Journey Builder) sont essentiellement différents dans leurs objectifs. Il est vrai que Blueprint est actuellement construit pour un seul module et que Command Center peut être construit multi-modules. Mais il s'agit d'une différence technique, et l'on ne peut pas supposer que Journey Builder est un Blueprint multi-modules simplement en raison de cette différence, car ils sont tous deux destinés à résoudre des problèmes différents.

1. Blueprint est destiné à la rationalisation des processus internes et à la conformité.
   Même si Blueprint était bientôt construit multi-modules, il continuerait à traiter la conformité, de sorte que son fonctionnement serait différent de celui d'un Journey Builder.
   
2. En revanche, Journey Builder vous aide principalement à orchestrer une série d'actions d'engagement planifiées sur tous les points de contact commerciaux.
   Même s'il est construit pour un seul module, il comprendra des déclencheurs et des actions d'engagement, et non des mandats de données comme c'est le cas avec Blueprint.
   

En quoi Journey Builder diffère-t-il de Cadence Studio ?

1. Cadence Studio peut être considéré comme un sous-ensemble de Journey Builder.
   
2. Si votre besoin est UNIQUEMENT de rationaliser les actions de suivi — c'est-à-dire utiliser une combinaison d'E-mail, Task et Appel pour assurer le suivi auprès d'un prospect jusqu'à l'obtention d'une réponse souhaitée — alors utilisez Cadence Studio.
   
3. Vous pouvez réaliser ce qui précède dans Journey Builder également, mais cela pourrait être laborieux dans Journey Builder, maintenant que Cadence Studio vous aidera à réaliser l'orchestration du suivi en un rien de temps. L'association d'un e-mail, d'une Task ou d'un appel, en fonction d'une ouverture, d'un clic ou d'un rebond antérieur, est plus fluide et gérée directement dans l'interface de Cadence Studio, ce qui vous évite de devoir configurer ces déclencheurs métticuleusement dans Journey Builder.
   
4. De cette façon, vous pouvez également déléguer toute l'orchestration d'engagement basée sur le suivi de Journey Builder à Cadence Studio et utiliser efficacement Journey Builder pour vous concentrer davantage sur les actions d'engagement dédiées après un suivi réussi.
   
5. Cadence Studio est efficace lors de la gestion des leads jusqu'à ce que votre prospect soit engagé. Journey Builder pourrait être plus efficace pour poursuivre l'engagement après le premier contact réussi et continuer à rationaliser le parcours jusqu'à l'achat, la rétention, la fidélité et l'advocacy.

En quoi Kiosk Studio diffère-t-il de Wizards ? Kiosk Studio est-il une solution de gestion des processus ?

Kiosk Studio et Wizards sont tous deux des solutions pour personnaliser votre compte Zoho CRM. Kiosk Studio est essentiellement une solution de personnalisation qui vous aide à personnaliser vos flux d'interface utilisateur afin d'exécuter des processus ad-hoc. Il s'agit d'une plateforme sans code pour créer votre propre widget dans lequel vous pouvez effectuer des actions personnalisées telles que l'entrée de données, la récupération, l'automatisation, etc.En revanche, Wizards est une solution de personnalisation spécifique qui se concentre sur l'expérience des données.

Wizards traite actuellement la création d'un enregistrement de manière systématique en scindant un formulaire long et encombré en segments ou « écrans » plus réfléchis, ce qui rend la saisie de données moins confuse et même agréable. Vous pouvez enregistrer un enregistrement en tant que brouillon et y revenir lorsque vous disposez de plus de détails. Par exemple, vous avez un lead au téléphone et vous essayez de lui expliquer votre produit. Certains champs du lead, tels que les détails sur ses besoins, ses antécédents commerciaux, etc., ne vous sont pas clairs pendant l'appel. Vous pouvez donc simplement enregistrer l'enregistrement en tant que brouillon et y revenir lorsque vous disposez de tous les détails, puis publier l'enregistrement dans le système. Par conséquent, Wizards se concentre sur la réalisation de cette flexibilité avec l'expérience des données dans CRM. Vous pouvez également automatiser les alertes.En savoir plus >> Document d'aide

En revanche, Kiosk ne se limite pas à la saisie ou la récupération de données, mais va au-delà — il peut aider à la saisie de données, la récupération, l'exécution d'alertes, les fonctions personnalisées et autres actions routinières. Plus important encore, il peut être déployé à un emplacement pratique de votre CRM, comme l'onglet Accueil, la vue Liste ou la vue Détail, voire dans l'espace Configuration. Vous pouvez l'utiliser pour récupérer les enregistrements sélectionnés et mettre à jour des informations spécifiques de plusieurs modules dans un seul widget, vous pouvez l'utiliser comme script d'appel, et le personnaliser pratiquement comme vous le souhaitez dans votre organisation.

En savoir plus >> Document d'aide

Examinons un Kiosk Studio simple pour une entreprise appelée Zylker Travels. Imaginez qu'un agent de voyages est au téléphone avec un client. Le client souhaite reprogrammer rapidement son voyage. Il peut être difficile pour l'agent de naviguer vers le bon module et de mettre à jour les champs corrects. Zylker a donc créé un Kiosk Studio, sans l'aide d'un développeur, pour concevoir un widget personnalisé et l'a déployé sur la page d'accueil, afin que l'agent puisse y accéder rapidement, interagir avec le widget, mettre à jour uniquement les champs pertinents et naviguer dans un flux UI flexible et très simple, spécifique à son organisation.

Voici à quoi ressemble la configuration d'un Kiosk Studio :

Un Blueprint, un Journey Builder et un flux Cadence peuvent-ils tous exécuter leurs flux sans aucun problème ?