Une demande manquée n’est perdue qu’une fois
Une demande à laquelle personne ne répond coûte ce qu’il a fallu dépenser pour l’obtenir. La publicité a été payée, le formulaire rempli, le message a passé la fin de semaine dans une boîte de réception partagée et, le lundi, la personne avait déjà acheté chez le premier à répondre. La perte est limitée. Il ne lui arrive rien de plus, et l’opinion qu’elle a de l’entreprise est celle qu’elle s’est faite quand personne ne lui a écrit.
Une fiche en double est une défaillance d’un autre ordre, parce que le dommage se prolonge au-delà du point où s’arrêtait celui de la demande manquée. Une même personne existe deux fois dans le CRM. Toutes les automatisations construites sur ce CRM la traitent comme deux personnes, si bien qu’elle reçoit deux accusés de réception à quelques minutes d’intervalle puis, plus tard, deux relances sur la même soumission. Elle ignore qu’il s’agit d’un problème de données et y voit une entreprise qui ne sait pas à qui elle parle.
La demande manquée n’était, elle, qu’une demande. Les doublons représentent une part de l’ensemble de la base de données, et une séquence atteint la base entière le jour de sa mise en service. C’est pourquoi nous réglons les doublons en premier, et pourquoi nous le disons en séance de stratégie, même quand le client vient parler de suivi.
Comment naissent les doublons
Les doublons viennent rarement de la négligence. Une même personne remplit le formulaire Web, écrit deux mois plus tard à la boîte de réception partagée depuis une autre adresse, appelle le bureau et envoie un message sur un réseau social. Chaque voie crée une fiche faute de vérification préalable, parce que l’intégration du formulaire crée un contact à chaque envoi et que la synchronisation de la boîte de réception en crée un pour chaque nouvelle adresse d’expéditeur.
De petites différences suffisent à tromper une comparaison simple. Une majuscule dans une adresse courriel, un espace final, une adresse professionnelle et une personnelle, un prénom complet dans un formulaire et abrégé dans le suivant. Chacune passe pour une autre personne aux yeux d’un système qui compare le texte exact, ce que font la plupart des CRM sauf indication contraire.
Les importations font le reste. Une liste exportée d’un ancien système, une feuille de calcul que quelqu’un a gardée deux ans sur son propre ordinateur, un lot de cartes d’affaires saisies après un salon professionnel. Chaque fois, tout est collé dans le CRM avec la vérification des doublons désactivée, parce qu’elle ralentissait l’importation. Nous avons vu des équipes dont la principale source de doublons était une seule importation, oubliée de tous jusqu’à ce que nous trouvions la date de création.
La plupart de ces voies échappent à la vérification propre au CRM, qui ne porte que sur un champ à la création d’une fiche, et le nombre de doublons grossit sans bruit jusqu’au premier envoi automatisé.
Ce que deux séquences font à une personne
La séquence elle-même est généralement bien construite. Elle s’arrête à une réponse, à une réservation ou à un désabonnement, et le nombre de messages est plafonné. Mais elle s’arrête sur la fiche qui a répondu. Sur l’autre, elle continue, si bien qu’une personne qui a répondu au premier message et réservé un appel reçoit quand même, trois jours plus tard, une relance demandant si la soumission est arrivée, venant d’une entreprise avec qui elle est en pleine discussion.
C’est avec les désabonnements que la défaillance est la plus grave. Un désabonnement est rattaché à la fiche et non à la personne, si bien que quelqu’un qui se désabonne depuis une fiche reste abonné sur l’autre, et que le message suivant part comme prévu. C’est ce message-là qui provoque une plainte. L’entreprise a été priée par écrit d’arrêter, et elle a continué.
Rien de tout cela n’apparaît dans le tableau de bord. Le rapport compte deux contacts et deux séquences lancées pour une seule réponse, si bien que le taux de réponse s’affiche à la moitié de sa valeur réelle. L’historique se scinde aussi, avec les notes d’appel sur une fiche et la soumission sur l’autre. L’équipe attribue ce faible taux à la formulation et réécrit les messages. La formulation était bonne.
Les règles de fusion appliquées en premier
Avant qu’une séquence soit mise en service, nous procédons donc à une fusion, selon des règles que le client approuve par écrit, parce qu’une fusion est destructrice et que ce qui n’est pas conservé disparaît. La première règle définit ce qui compte comme une même personne. Une adresse courriel en minuscules et sans espaces est le critère principal, et un numéro de téléphone réduit à ses chiffres, le second. Toute correspondance plus lâche, par exemple le même nom dans la même entreprise avec une autre adresse, est signalée à une personne et jamais fusionnée d’office.
La deuxième règle désigne la fiche conservée. Nous gardons la plus ancienne, parce qu’elle contient généralement l’historique, et nous y reportons les champs plus récents. En cas de divergence, la valeur la plus récente l’emporte pour un numéro de téléphone ou un titre de poste, et la plus ancienne pour la source et la date de création. Les notes, courriels, appels et transactions des deux fiches passent sur la fiche conservée, et rien n’est supprimé avant la lecture du journal de fusion.
La troisième règle porte sur l’état des séquences. Si l’une ou l’autre fiche est désabonnée, la fiche fusionnée l’est aussi. Une réponse sur l’une des deux la marque comme ayant répondu et arrête toute séquence en cours, et un rebond sur l’une des adresses met fin aux envois vers celle-ci. Une transaction ouverte sur l’une ou l’autre est reprise, et la fiche est exclue de la séquence des nouvelles demandes. Le statut le plus strict l’emporte toujours. La fusion par défaut d’un CRM se trompe ici, parce qu’elle garde le statut de la fiche conservée quoi qu’ait indiqué l’autre.
La fusion n’est pas ponctuelle, et c’est la quatrième règle. De nouveaux doublons arrivent chaque jour par les mêmes voies, si bien que la même comparaison tourne chaque nuit sur les fiches du jour. Ce qui correspond est fusionné selon les règles ou mis en file d’attente pour qu’une personne de l’équipe du client l’examine, et cette personne est nommée avant la mise en place. Les quatre règles figurent dans la note de passation, avec les champs et les filtres qu’elles utilisent, pour que quelqu’un qui ne les a pas écrites puisse modifier un seuil sans nous appeler.
