La réponse tardive est la moindre perte
Dans la mise en place d’une automatisation, l’essentiel de l’attention va à la rapidité. La première réponse à une demande, la relance d’une soumission en attente, le rappel la veille d’un rendez-vous, le délai entre la fin d’une prestation et la demande d’avis, tout cela est conçu avec soin et mesuré au trentième jour. Une réponse tardive est une perte réelle, et c’est une perte limitée. La demande qui a attendu jusqu’au lundi n’est qu’une demande. Le contact est généralement parti ailleurs entre-temps, et une personne qui présente des excuses et une soumission peut parfois le faire revenir.
Un message qui arrive après un désabonnement est une défaillance d’une autre nature. La personne a demandé à l’entreprise d’arrêter, par le seul moyen que l’entreprise elle-même lui offrait, et l’entreprise a continué. De son point de vue, cela a tout d’une décision délibérée, et la réponse habituelle à une décision de ce genre consiste à signaler le message comme pourriel, ce qui enregistre une plainte contre le domaine d’envoi auprès du fournisseur de messagerie.
C’est la plainte qui rend le dommage plus grand que le message. Les fournisseurs de messagerie tiennent un compte continu des plaintes visant un domaine, et une fois ce compte assez élevé, ils se mettent à classer les messages du domaine dans les courriels indésirables pour tout le monde, y compris les contacts qui les avaient demandés et le client qui attend une facture. Un seul message à une seule personne partie de la liste peut coûter la portée de tous les messages qui suivent. Une réponse tardive ne fait jamais cela. Elle coûte une demande et laisse le reste de la liste intact.
C’est aussi une infraction aux règles sur le consentement, passible d’une sanction, alors qu’une réponse tardive n’enfreint aucune règle. Nous le disons une fois en séance de stratégie, puis nous n’y revenons plus. Le nombre de plaintes parle de lui-même, et c’est un chiffre que l’équipe peut consulter directement dans les rapports de son propre outil de courriel.
Comment un désabonnement se perd
Dans les équipes que nous avons accompagnées, les outils eux-mêmes respectent sans exception leur propre lien de désabonnement. Le problème, c’est qu’une entreprise d’une certaine taille envoie des messages depuis plusieurs endroits, et que chacun tient son propre registre des désabonnés. L’outil d’infolettre a le sien. La messagerie intégrée au CRM en a un autre. Nos séquences de suivi tournent dans un outil d’automatisation qui en a un troisième, le compte SMS en a un quatrième, et quelqu’un aux ventes fait un publipostage depuis une feuille de calcul sans aucun registre.
Un contact clique sur le lien au bas de l’infolettre et il est retiré de l’infolettre. Rien n’en informe la séquence de suivi des soumissions. Deux jours plus tard, la séquence envoie sa deuxième relance, au nom d’une personne, avec un lien de réservation, exactement comme prévu. Du côté du contact, il s’est désabonné le mardi et la même entreprise lui a écrit le jeudi. La séquence était correcte, et la connexion entre les deux outils n’a jamais été établie.
La même défaillance a des versions plus discrètes. Un segment enregistré le lundi et envoyé le jeudi, avec un désabonnement le mardi entre les deux, part vers une liste qui était exacte au moment où elle a été constituée. Un contact qui s’est désabonné puis a rempli un formulaire six mois plus tard revient sous la forme d’une seconde fiche dont le champ d’exclusion est vide, et la séquence le traite comme un nouveau contact. Une exportation faite pour l’invitation à un événement survit dans une feuille de calcul, sert pour l’événement suivant et contient toutes les adresses désabonnées depuis. Un numéro de téléphone qui a répondu STOP au compte SMS figure toujours sur la liste de courriels, parce que les deux outils n’ont jamais échangé la moindre fiche. Chacun de ces cas se produit alors que chaque outil fonctionne comme prévu, parce qu’il existe deux listes là où il ne devrait y en avoir qu’une.
Nous cherchons ces cas avant la mise en service de la première séquence, parce que les découvrir après veut dire qu’une personne a déjà reçu un message après s’être désabonnée. Quand l’un d’eux apparaît malgré tout, la réponse du contact qui dit s’être déjà désabonné passe en tête des priorités, avant la formulation et le délai de réponse, et les envois sont suspendus dans tous les outils jusqu’à ce que les listes n’en fassent plus qu’une. C’est difficile à faire la deuxième semaine d’une mise en place, devant un client qui surveille le délai de réponse qu’on lui a promis. Le délai de réponse peut attendre.
Une seule liste, vérifiée au moment de l’envoi
Le garde-fou est une liste d’exclusion unique, tenue à un seul endroit, généralement le CRM, parce que c’est là que tous les autres outils regardent déjà. Chaque désabonnement, sur chaque canal, y est inscrit. Le lien de l’infolettre, le lien de la séquence, la réponse STOP sur le compte SMS, le rebond définitif et la personne qui dit au téléphone qu’elle préférerait ne plus entendre parler de l’entreprise aboutissent tous au même indicateur sur la même adresse, et cet indicateur y est inscrit le jour même.
Chaque envoi, depuis chaque outil, consulte cette liste avant de partir. La vérification a lieu au moment de l’envoi, parce que c’est dans l’intervalle entre la création d’un segment et son envoi que tombe le désabonnement du mardi. Quand un outil peut lire directement le CRM, il le lit. Quand il ne le peut pas, la liste d’envoi est exportée du CRM le matin même de l’envoi, avec le filtre d’exclusion dans la requête enregistrée, et aucune exportation antérieure à ce matin-là n’est utilisée. Cette règle figure en ces termes dans la note de passation.
La correspondance se fait sur l’adresse et le numéro de téléphone. Une fiche de contact peut être en double, et une personne partie puis revenue par un formulaire six mois plus tard a une nouvelle fiche avec la même adresse, or c’est à cette adresse que l’expéditeur va écrire. Une correspondance sur la fiche la laisserait passer. Une correspondance sur l’adresse bloque le second message, et c’est aussi ce qui intercepte la feuille de calcul, à condition qu’elle soit comparée à la liste avant usage, ce qui fait l’objet de la règle suivante.
Les envois manuels passent par le même contrôle, et c’est la règle qui fait débat. Un publipostage depuis la boîte de réception d’un représentant, une invitation à un événement envoyée depuis une feuille de calcul, un sondage client envoyé depuis l’outil de formulaires, une annonce ponctuelle de la direction générale : chacun doit être comparé à la liste avant de partir, et la façon la plus simple de s’y tenir est de retirer la feuille de calcul. La liste à partir de laquelle une personne envoie est une vue enregistrée dans le CRM, avec le filtre d’exclusion déjà appliqué, et rien d’autre. La règle est impopulaire dans la salle, parce qu’elle enlève une habitude de travail à des gens qui n’ont pas causé le problème, et c’est celle sur laquelle nous ne transigeons pas.
Le traitement des réponses relève de la même liste. Nos séquences s’arrêtent à toute réponse et la transmettent à une personne, dont une partie du travail, précisée dans la note de passation, consiste à inscrire le jour même sur la liste d’exclusion tout contact qui demande qu’on le laisse tranquille, quels que soient ses mots. Le lien de désabonnement ne touche que ceux qui s’en servent. Les autres le disent dans une phrase, et seule une phrase lue par une personne permet de les repérer.
La mettre à l’épreuve avant que quiconque s’y fie
Une liste d’exclusion qui n’a pas été testée relève de la croyance. Avant la mise en service, nous testons la liste comme nous testons le délai de réponse, de l’extérieur, avec une vraie adresse. Un contact de test est créé, se désabonne par un canal, puis chacun des autres outils de l’entreprise lui envoie un message. Si le moindre message arrive, la connexion entre l’outil qui l’a envoyé et la liste devient la prochaine tâche, et la mise en service attend qu’elle soit établie.
Le test est répété à partir de chaque canal, tour à tour, parce que les connexions ne sont pas symétriques. Un désabonnement de l’infolettre atteint généralement le CRM. Un STOP sur le compte SMS n’atteint rien tant que personne ne l’a connecté. Le nombre de paires à vérifier augmente avec chaque outil qui envoie des messages, et chacune est vérifiée, parce que la paire que personne n’a testée est celle qui écrit à quelqu’un après son désabonnement.
Au trentième jour, le test est refait et consigné dans le document des valeurs de référence, à côté des cinq chiffres, sous forme de réussite ou d’échec, avec la date et le nom de la personne qui l’a effectué. C’est la seule ligne de cette page sans chiffre, et celle que nous aimerions le moins voir changer entre les deux relevés. Une liste qui passe le test à la mise en service et y échoue au trentième jour signifie qu’un outil a été ajouté ou qu’une connexion s’est rompue entre-temps, et la note de passation indique qui consulter.
La responsabilité est l’autre moitié de chaque garde-fou que nous mettons en place, et le test règle cette question. La liste a un responsable désigné dans l’équipe du client, la personne même qui modifie la formulation de la séquence quand l’offre change, et la seule règle qui accompagne cette désignation est qu’un nouvel outil d’envoi se connecte à la liste avant d’envoyer quoi que ce soit. De nouveaux outils arrivent sans que personne en avise le marketing : un outil de sondage auquel le service à la clientèle s’est abonné, un système de réservation qui envoie ses propres rappels. C’est au responsable de la liste de poser la question.
