L’emplacement de l’automatisation détermine ce qu’elle voit
La plupart des automatisations qu’on nous demande d’examiner ont été construites là où leur auteur se sentait à l’aise. Un gestionnaire marketing qui avait utilisé un connecteur dans un emploi précédent y a placé le suivi, un administrateur du CRM a construit la même chose sous forme de flux de travail dans le CRM, et ni l’un ni l’autre n’a noté pourquoi. Le choix est traité comme une question de goût. Ce n’en est pas une, parce que les deux versions ne surveillent pas la même chose.
Un flux de travail dans le CRM repose sur la fiche elle-même. Il voit un champ changer en temps réel, que la modification vienne d’un écran, d’un formulaire ou d’une importation, et il peut démarrer sur n’importe quel changement : une fiche qui change d’étape, une date qui passe, une propriété qui se remplit, un courriel qu’on ouvre. Chacune de ses actions s’inscrit dans la chronologie de la fiche, à côté des appels et des notes laissés par une personne.
Un dimanche à 21 h, une demande arrive, et ce flux de travail en accuse réception immédiatement. Un connecteur ne s’en occupe que quelques minutes plus tard, parce qu’il ne surveillait pas la fiche. Il demandait au CRM, à quelques minutes d’intervalle avec la plupart des forfaits, si de nouvelles fiches étaient apparues, et le CRM répond aux outils externes avec une liste d’événements plus courte que celle dont disposent ses propres flux de travail. La modification d’un champ sur une fiche qui existait déjà est un déclencheur distinct, que le CRM peut rendre accessible ou non aux outils extérieurs. Pour ce message précis, le délai n’a pas d’importance. Il en a pour le déclencheur qui se révèle absent de la liste partagée, ce que l’équipe découvre en voulant construire l’automatisation suivante. Le connecteur contient alors six mois d’étapes, et le déplacer revient à tout reconstruire.
Ce qu’un connecteur surveille réellement
Avant de nous engager à quoi que ce soit, nous demandons la liste des déclencheurs du connecteur, et elle est plus courte qu’on ne le croit. Nouveau contact, nouvelle transaction, transaction passée à une étape donnée, et parfois une fiche modifiée, avec une vérification du champ qui a changé. Souvent, c’est tout. Le flux de travail du CRM peut généralement démarrer sur l’ouverture d’une soumission, une tâche en retard, un client qui modifie lui-même ses coordonnées ou l’arrivée d’une date de renouvellement, ce que le connecteur ne peut souvent pas faire.
La fiche que lit le connecteur est la fiche telle qu’elle était au moment où il l’a récupérée. Si une transaction change deux fois d’étape entre deux vérifications, le connecteur voit la deuxième étape et jamais la première, et l’étape qui aurait dû se déclencher au premier changement est manquée sans laisser aucune trace. Dans le CRM, ces deux changements sont deux événements. Le flux de travail s’exécute deux fois.
Reste la question de ce que le connecteur a le droit d’inscrire dans le CRM. Un flux de travail dans le CRM écrit sur la fiche qu’il lisait, si bien que l’accusé de réception envoyé et la tâche créée figurent tous deux dans la chronologie qu’ouvre le représentant des ventes. Le connecteur écrit par la porte même par laquelle il lit, ce qui veut dire que chaque note qu’il laisse est une requête distincte qui peut échouer isolément, et quand cela arrive, la fiche n’affiche rien du tout.
Le connecteur n’est pas pour autant le mauvais outil. Il voit moins de choses dans le CRM et davantage ailleurs, un compromis que nous demandons à l’équipe d’accepter sciemment. La plupart des équipes n’ont jamais vu la liste.
Comment un champ défaillant est repéré
Les champs changent de nom. La personne responsable du formulaire du site Web modifie un libellé, un administrateur fait le ménage dans les propriétés du CRM, un nouvel outil importe des contacts avec un champ source orthographié autrement, ou un collègue supprime un champ que personne ne semblait utiliser. L’automatisation qui dépendait de l’ancien nom lit désormais une valeur vide, et la suite dépend de l’endroit où elle se trouve.
Dans le CRM, le flux de travail qui utilisait ce champ affiche généralement un avertissement à l’étape qui l’a perdu, dans l’outil que l’équipe ouvre tous les matins. La fiche sur laquelle il s’est exécuté porte une note indiquant qu’une étape a été sautée. Quelqu’un s’en aperçoit dans la semaine, parce que l’endroit où la panne s’est produite est celui où l’on travaille. Cela tient simplement à l’endroit où l’erreur peut apparaître.
À côté du CRM, le connecteur continue de tourner. Il a récupéré une fiche, a trouvé vide le champ auquel il était associé et a fait ce qu’on lui avait demandé avec ce vide. Le message part avec un blanc là où devrait figurer le prénom, à chaque nouvelle demande, au rythme habituel du connecteur. Si tant est que le connecteur compte cela comme une erreur, le signalement aboutit dans un tableau de bord que l’équipe du client n’a aucune raison d’ouvrir, et chez la personne qui a configuré le connecteur, souvent passée à autre chose depuis.
C’est ce coût que nous désignons quand nous disons que le connecteur en voit moins. Une étape à côté du CRM peut tomber en panne sans que les personnes concernées en soient averties, et l’automatisation continue au même rythme à faire ce qu’il ne faut pas. Plus d’une fois, la raison pour laquelle les réponses avaient cessé était un champ renommé un trimestre plus tôt.
Nous prévoyons un test à ce sujet dans la passation, et nous l’effectuons sous les yeux du client. Nous renommons volontairement un champ dont dépend l’automatisation, puis nous regardons où l’échec apparaît et qui en est averti. Si personne ne l’est, la mise en place n’est pas terminée. Le champ reprend son nom et la correction est faite avant notre départ.
Les compromis que nous mettons sur la table
Nous tranchons avant de dessiner la première étape, en nous fondant sur quatre points auxquels l’équipe peut répondre elle-même. Le premier est de savoir si chaque étape fait appel à un outil auquel le CRM a déjà accès. Une automatisation qui lit un formulaire, enregistre un contact, envoie un courriel et crée une tâche peut fonctionner entièrement dans la plupart des CRM, et c’est là que nous la construisons. Une étape qui doit écrire dans le système comptable, ou envoyer un SMS par un fournisseur de téléphonie que le CRM ne connaît pas, dépasse ce que le CRM peut faire seul. C’est cette seule étape qui fait entrer un connecteur dans la mise en place.
Vient ensuite ce que le CRM facture pour ses propres automatisations. Dans bon nombre des CRM qu’utilisent les petites équipes, les flux de travail relèvent d’un forfait supérieur à celui que l’équipe paie. La comparaison qui compte oppose le prix de ce forfait aux frais du connecteur pour le nombre d’exécutions que l’équipe fera réellement, et les deux chiffres figurent sur la même page. Un connecteur choisi parce qu’il semblait gratuit le reste rarement une fois que le suivi s’applique à chaque demande.
Le troisième est de savoir qui ouvrira l’outil où aboutissent les erreurs. Si la personne responsable de l’automatisation passe ses journées dans le CRM et n’a jamais ouvert le connecteur, le tableau de bord du connecteur est un endroit où les erreurs passent inaperçues. Si cette même personne pilote déjà les autres automatisations de l’entreprise depuis le connecteur, la réponse s’inverse. Nous le disons alors.
Le quatrième est la durée pendant laquelle l’équipe compte rester sur ce CRM. Un flux de travail construit à l’intérieur est perdu le jour de la migration, et chaque étape doit être reconstruite dans le nouveau système. La chaîne du connecteur survit au changement. On remplace son déclencheur et sa première étape, et le reste demeure intact. Pour une équipe qui parle déjà de changer d’outil, c’est un vrai argument en faveur du connecteur, et nous ne prétendons pas le contraire.
Quand nous construisons malgré tout à côté du CRM
Quand une seule étape impose un connecteur, le déclencheur reste dans le CRM. Le flux de travail du CRM démarre sur l’événement qu’il peut voir et exécute lui-même toutes les étapes dont il est capable, puis confie au connecteur, par un appel en fin de parcours, la seule étape qu’il ne peut pas faire. Dès lors, le connecteur n’a plus du tout à surveiller le CRM. Il attend qu’on le sollicite.
Le connecteur inscrit son résultat dans la fiche avant toute autre chose, sous forme de note ou de valeur de champ, de sorte que la chronologie montre que l’étape a été transférée et si elle est revenue. Quand le transfert échoue, c’est le flux de travail du CRM qui s’en aperçoit, parce qu’il attendait une valeur qui n’est jamais arrivée, et son avertissement apparaît là où l’équipe regarde déjà. Plus personne n’a besoin d’ouvrir le tableau de bord du connecteur.
Ses identifiants figurent dans la note de passation, avec le nom d’une personne en regard, sur la ligne même qui indique qui modifie le message quand l’offre change. Un connecteur dont le mot de passe est parti avec un prestataire est une automatisation que personne ne peut arrêter. On nous a demandé plus d’une fois d’en retrouver un, et la recherche prend plus de temps que la correction.
