Automatisation CRM : ce qu'elle couvre vraiment et comment elle déraille en silence

Demandez à dix petites entreprises ce que signifie l'automatisation CRM et huit décriront une séquence d'e-mails. Quelqu'un remplit un formulaire et reçoit, dans les quinze jours, quatre messages rédigés des mois plus tôt par la personne qui avait alors le temps de les écrire.

C'est l'automatisation CRM au sens où un essuie-glace est une voiture. C'est réel, c'est visible, et cela représente une fraction de la mécanique. Les parties qui changent vraiment le fonctionnement d'une entreprise sont moins photogéniques : des données qui s'enregistrent comme effet secondaire du travail, des fiches qui s'orientent seules vers un propriétaire, des étapes qui reflètent la réalité sans que personne déplace une carte, des relations qui lèvent la main quand elles commencent à s'endormir, et des rapports qui existent le lundi matin sans qu'un humain les assemble.

Cet article couvre les cinq, puis consacre un vrai temps à la partie que la plupart des articles évitent : les manières précises dont l'automatisation CRM déraille. Pas l'avertissement générique « commencez petit », mais les trois modes de panne qui produisent de vrais dégâts, pourquoi chacun est difficile à voir, et ce qu'une petite équipe doit en faire. Il se termine par la gouvernance, mot qui semble réservé aux entreprises dotées d'un service conformité et qui est en réalité la différence entre une automatisation à laquelle vous ferez encore confiance dans un an et une que vous éteindrez discrètement.

Les cinq domaines que l'automatisation CRM doit couvrir

1. Une saisie qui devient un effet secondaire du travail

L'automatisation la plus précieuse d'un CRM est celle qui empêche quiconque d'y taper quoi que ce soit.

Toutes les autres règles que vous construirez dépendent du fait que la fiche existe et soit exacte. Si les demandes vivent dans trois boîtes mail et un téléphone, si la moitié des appels ne sont jamais consignés, si le montant d'une affaire est une estimation vieille de six semaines, alors chaque règle en aval travaille sur de la fiction. Automatiser par-dessus une mauvaise capture ne fait qu'accélérer la fiction.

Une capture bien faite signifie que la fiche naît de ce qui vient de se produire. Un formulaire envoyé devient un contact. Un message devient un prospect. Une réunion produit son propre résumé, ses décisions, ses actions à mener et l'adresse e-mail corrigée que le prospect a mentionnée en passant. Une carte de visite photographiée devient un contact avec les champs remplis. Rien de tout cela n'est une tâche de frappe, et c'est bien l'idée : la fiche existe parce que le travail a eu lieu, pas parce que quelqu'un a trouvé vingt minutes en fin de journée.

Le sujet mérite son propre traitement, et il l'a dans le guide sur le CRM sans saisie de données. Pour l'automatisation, retenez la dépendance : la capture n'est pas une automatisation parmi cinq, c'est le socle sur lequel les quatre autres reposent.

2. L'attribution, qui décide si quelque chose se produit

Une fiche sans propriétaire est une fiche que personne ne travaille. Dans les petites équipes, ce n'est pas un risque théorique, c'est un mardi ordinaire. Une demande arrive, deux personnes la voient, chacune suppose que l'autre s'en occupe, et elle reste là.

Les règles d'attribution sont sans éclat et pèsent bien plus lourd que leur complexité ne le laisse croire. Orientez par source, par territoire, par ligne de produit, par rotation ou selon qui est réellement disponible, et faites-le dans les minutes qui suivent l'apparition de la fiche. Rendez ensuite l'attribution visible sur la fiche et dans une notification, car un propriétaire qui ignore qu'il est propriétaire équivaut à aucun propriétaire.

Résistez à la tentation d'être malin trop tôt. Orienter selon un score de prospect, avant d'avoir assez d'affaires signées pour qu'un score veuille dire quelque chose, remplace un fait par une inférence puis agit sur l'inférence. Orientez sur quelque chose que vous savez réellement.

3. Des changements d'étape qui suivent les faits

L'étape d'une affaire est une affirmation sur la réalité. Dans la plupart des pipelines de petites entreprises, c'est une affirmation qui était vraie il y a environ onze jours.

Automatiser les changements d'étape signifie que l'affirmation se met à jour quand le fait sous-jacent change. Une proposition part, l'affaire entre en étape Proposition envoyée, et les tâches propres à cette étape naissent avec elle. Un document signé arrive, l'affaire passe en Gagnée et le passage de relais démarre. Un devis expire sans réponse, l'affaire recule au lieu de rester dans une étape qui flatte vos prévisions.

Deux contraintes gardent cela honnête. La première : un changement d'étape doit être déclenché par un événement, pas par le seul écoulement du temps, car la promotion par ancienneté est la façon dont un pipeline se remplit d'affaires qui ont avancé en vieillissant. La seconde : tout ce qui recule une affaire ou la bascule en perte doit laisser une trace du pourquoi, saisie le jour même. Les motifs de perte écrits un mois plus tard relèvent de la littérature.

4. La détection de dormance, l'automatisation que l'on oublie

Tout ce qui précède concerne des fiches qui avancent. La catégorie que les petites entreprises négligent systématiquement est l'inverse : remarquer que quelque chose a cessé d'avancer.

Les affaires meurent rarement à un instant que l'on peut désigner. Elles s'endorment. Le client cesse de répondre, le commercial compte relancer, la semaine devient chargée, et huit semaines plus tard l'affaire est techniquement ouverte et pratiquement morte. La même chose arrive aux relations clients. Personne ne décide de négliger un compte, on passe simplement un trimestre sans lui parler.

La détection de dormance est une règle permanente qui guette une absence plutôt qu'une présence. Une affaire ouverte sans activité depuis sept jours. Une affaire active sans prochaine étape datée. Un client sans contact depuis quatre-vingt-dix jours. Un prospect qualifié jamais appelé. Chacune produit une courte liste et un propriétaire nommé, ce qui est une expérience radicalement différente du vague sentiment que vous négligez sans doute quelqu'un.

Le détail de conception décisif est la clause d'exclusion. Une affaire légitimement en pause jusqu'au conseil d'administration du client dans trois semaines ne doit pas produire une relance tous les sept jours. Sinon l'équipe apprend à ignorer la notification, et une notification que tout le monde ignore est pire que rien, car elle enseigne aussi à ignorer celles qui comptent.

5. Des rapports qui s'assemblent tout seuls

La dernière catégorie a la valeur horaire la plus nette et suscite le moins de résistance.

Dans la plupart des petites entreprises, quelqu'un passe une partie du premier jour ouvré du mois à recopier des chiffres du CRM vers un tableur pour que ces mêmes chiffres soient commentés en réunion. Les chiffres existent déjà. Tout le travail est dans l'assemblage, et l'assemblage est l'activité la plus automatisable qui soit.

Un récapitulatif mensuel qui produit le chiffre d'affaires, le nombre d'affaires gagnées et perdues, le cycle moyen, l'activité par personne et les créances en cours, classé dans l'espace de travail sans que personne le construise, n'est pas une automatisation sophistiquée. C'est une requête planifiée. C'est aussi, invariablement, l'automatisation dont les gens sont le plus surpris de découvrir qu'ils la faisaient à la main.

La version hebdomadaire compte plus que la mensuelle. Un condensé du lundi listant les nouveaux prospects, les affaires qui ont bougé, celles qui se sont tues, celles qui se closent cette semaine et les factures impayées change la raison d'être de la réunion. Elle cesse d'être une réunion où l'on établit des faits à voix haute pour devenir une réunion où l'on décide, soit à peu près la moitié du temps récupéré.

Comment l'automatisation CRM déraille

Voici la partie que la plupart des articles omettent, parce qu'elle est inconfortable et ne vend rien.

Les pannes d'automatisation ne ressemblent pas aux bogues logiciels. Un bogue lève une erreur et quelqu'un le remarque. Une panne d'automatisation ressemble exactement à un succès jusqu'au moment où ce n'en est plus un, et à ce stade elle échoue en général depuis un moment. Cela se produit de trois façons distinctes, de plus en plus graves.

Les règles sans propriétaire

La première panne est organisationnelle et quasi universelle.

Quelqu'un met une règle en place lors d'un mois énergique. Elle fonctionne. Six mois plus tard l'entreprise a changé : les noms d'étapes sont différents, la question de qualification est différente, la personne qui gérait ce segment est partie. La règle, elle, n'a pas changé, car les règles ne changent pas d'elles-mêmes. Elle tourne toujours, se déclenche toujours, fait toujours quelque chose qui avait du sens face à une version de l'entreprise qui n'existe plus.

Personne ne l'éteint, car éteindre une règle suppose de savoir ce qu'elle fait, et celui qui le savait est parti. Elle reste donc. Les nouveaux supposent qu'elle est délibérée. On la contourne au lieu de la corriger, et le contournement devient le processus. En un an, vous avez un ensemble d'automatisations que personne dans l'entreprise ne peut expliquer entièrement, forme curieuse et fort répandue de dette technique dans une entreprise sans ingénieurs.

Le remède n'est pas la documentation, que personne ne lit. Le remède est un nom. Chaque règle a une personne capable de l'expliquer en une phrase et habilitée à la supprimer. Quand cette personne part, ses règles sont réattribuées dans la même conversation que ses comptes clients. Si une règle ne trouve pas de propriétaire, c'est la meilleure preuve disponible qu'elle doit être retirée.

Les pannes silencieuses

La deuxième panne est technique et c'est celle qui trompe les gens expérimentés.

Une règle qui a cessé de fonctionner n'émet aucun signal. Elle ne lève pas d'erreur. Elle n'a pas l'air cassée. Elle est dans la liste et paraît correcte, et la raison en est qu'elle est correcte, au sens où sa logique est exactement ce que vous avez écrit. Simplement, elle ne correspond plus jamais à rien.

Cela arrive constamment. Un champ est renommé, la condition qui cherchait l'ancienne valeur correspond désormais à zéro fiche. Une étape est scindée en deux, et la règle qui guettait l'étape d'origine ne capte plus que la moitié des affaires. Une application connectée change son format d'export et écrit « Nouvelle-Zélande » là où elle écrivait « NZ ». Aucun de ces cas ne lève d'erreur. Ils réduisent simplement à zéro le taux de déclenchement d'une règle qui continue d'avoir l'air vivante.

L'indice est toujours le même et presque personne ne le vérifie : une règle qui s'est déclenchée zéro fois ce mois-ci est soit inutile soit cassée, et les deux hypothèses méritent un coup d'œil. C'est pourquoi le journal d'exécution compte davantage que l'éditeur. L'éditeur montre ce qu'une règle est censée faire. Le journal montre ce qu'elle a fait. L'écart entre les deux est le refuge de toutes les pannes silencieuses.

Les chaînes multi-applications aggravent cela d'une façon précise. Quand le déclencheur vit dans un outil, la donnée dans un autre et l'action dans un troisième, une rupture au milieu produit une règle à moitié fonctionnelle : elle se déclenche, fait la première chose, et la seconde n'a silencieusement pas lieu. Chaque page de statut fournisseur est au vert. La chaîne est cassée quand même.

Les automatisations qui se déclenchent sur de mauvaises données

La troisième panne est celle que vos clients voient, et la seule de la liste qui puisse réellement vous coûter une relation.

Toute automatisation est un amplificateur. Avec une bonne fiche, elle fait vite la bonne chose. Avec une mauvaise fiche, elle fait vite la mauvaise chose, à grande échelle, à de vraies personnes, avec votre nom dessus.

Les formes précises que cela prend méritent d'être nommées, car elles reviennent dans toutes les entreprises qui automatisent :

Le doublon. Quelqu'un remplit votre formulaire puis vous écrit sur WhatsApp. Deux fiches, deux messages de bienvenue, un destinataire qui sait désormais que votre système ne fait pas attention. Une condition de dédoublonnage sur un identifiant stable, numéro de téléphone ou e-mail, n'est facultative sur aucune règle sortante.

Le champ de fusion vide. Un message qui commence par « Bonjour {first_name}, » va très bien jusqu'à ce qu'arrive une fiche ne contenant qu'un nom d'entreprise, et vous voilà en train de saluer un blanc. Chaque variable a besoin d'une valeur de repli, et chaque règle sortante d'un test contre une fiche volontairement incomplète avant la mise en service.

La fiche de test. Quelqu'un crée « Prospect test » un mardi après-midi pour vérifier un formulaire. Trois jours plus tard, elle reçoit une relance ferme sur une facture impayée. C'est drôle exactement une fois, et seulement si la fiche de test était interne.

Le client qui a payé et qu'on relance quand même. Une facture est marquée payée à un endroit mais la séquence de relance surveille un autre champ, et un client qui a réglé la semaine dernière reçoit un rappel de plus en plus ferme. Rien ne détruit plus vite la confiance interne dans l'automatisation, et le correctif consiste à faire fermer la boucle explicitement par le paiement : marquer payé, arrêter la séquence, clore les tâches de relance.

Le fait périmé traité comme actuel. Un montant d'affaire saisi en janvier alimente une règle de remise en août. La règle fonctionne parfaitement. L'entrée a huit mois.

Notez ce que tout cela a en commun. Aucun n'est un problème de logique, et aucun ne se résout en ajoutant des conditions à la règle. Ce sont tous des problèmes de données que l'automatisation a convertis en événements visibles par le client. Donc la garde appartient à la donnée : exiger les champs dont dépend l'action, dédoublonner avant l'envoi, exclure les fiches de test par convention, et laisser une règle refuser de tourner plutôt que tourner sur de l'incomplet. Une automatisation qui refuse de se déclencher est un désagrément mineur. Une automatisation qui se déclenche sur du n'importe quoi est un appel téléphonique.

Il existe une version plus large de cette panne. Ses causes recoupent largement celles pour lesquelles les projets CRM échouent au départ, traitées dans le guide sur pourquoi les déploiements CRM échouent : dans les deux cas, un système dépend d'un entretien humain que personne n'a le temps de fournir.

Où se situe Zoye

Zoye aborde le sujet autrement qu'un éditeur de règles, et la différence tient surtout à ce qu'on vous demande d'entretenir.

Vous décrivez la règle en une phrase, dans l'application, sur WhatsApp ou dans Slack. Zoye la transforme en un vrai déclencheur, de vraies conditions et de vraies actions, puis vous montre la règle finie réécrite en langage clair pour que vous vérifiiez que ce qu'elle a compris correspond à ce que vous vouliez dire. Rien ne tourne avant votre approbation. Un éditeur visuel existe si vous voulez voir la forme d'une règle ou l'ajuster, et vous n'êtes jamais obligé de l'ouvrir.

Les rapports Zoye réunissent affaires, tâches, contacts et finances dans un seul tableau de bord, si bien que le récapitulatif mensuel s'assemble seul au lieu d'être construit à la main

Deux éléments structurels comptent plus que l'étape phrase-vers-règle, et tous deux répondent directement aux modes de panne ci-dessus.

Le premier : les fiches sont déjà liées entre elles. Une affaire connaît son contact, ses tâches, ses fichiers et ses factures, et les déclencheurs comme les actions atteignent huit des outils de l'espace de travail. Il n'y a pas de correspondance de champs entre systèmes parce qu'il n'y a pas d'écart entre systèmes, ce qui supprime toute la classe de pannes silencieuses issues d'un champ renommé ou d'un jeton expiré au milieu d'une chaîne. Le déclencheur, la donnée et l'action sont le même espace de travail.

Le second : le journal d'exécution. Chaque exécution enregistre ce qui s'est déclenché, ce qui a changé et ce qui a été envoyé, et elle est réversible. C'est sans éclat et c'est précisément ce qui fait passer l'automatisation d'un acte de foi à quelque chose d'auditable. Quand une règle se déclenche sur une mauvaise fiche, vous voulez le voir le jour même, le comprendre en trente secondes et l'annuler, plutôt que le reconstituer trois semaines plus tard à partir d'une réclamation.

Six recettes sont prêtes à activer : relance immédiate d'un nouveau prospect, affaire dormante depuis sept jours, intégration après une affaire gagnée, relance de facture en retard, remontée des tâches bloquées, et tâche parente qui se clôt quand toutes ses sous-tâches sont terminées. Pour un menu plus large, y compris les règles que vous écririez vous-même, la collection d'exemples d'automatisations de processus en détaille vingt avec leur déclencheur et leur condition. La vue complète de la portée du moteur se trouve sur la page automatisations de processus.

Pour être clair sur le périmètre : Zoye n'est pas un logiciel comptable, donc les règles de facturation relancent et consignent plutôt qu'elles ne rapprochent vos écritures. Ce n'est pas une suite de tickets support. Et Zoye ne gère pas vos campagnes publicitaires, elle capte et travaille les prospects que ces campagnes produisent.

La gouvernance, ou comment y faire encore confiance dans un an

Gouvernance est un mot lourd pour trois habitudes légères. Elles font la différence entre un ensemble d'automatisations qui capitalise et un ensemble qui devient lentement un passif auquel personne ne veut toucher.

Journalisez chaque exécution. Non comme une piste d'audit pour quelqu'un d'autre, mais comme un outil de diagnostic pour vous. Chaque règle doit enregistrer ce qui s'est déclenché, sur quelle fiche, ce qui a changé et ce qui a été envoyé. Sans cela, impossible de distinguer une règle qui fonctionne d'une règle qui ne correspond silencieusement à rien, et ces deux états sont identiques partout sauf dans le journal. Lisez le journal pendant les quinze premiers jours de toute nouvelle règle et vérifiez que le nombre de déclenchements correspond à peu près à votre prévision. Deux déclenchements quand vous en attendiez quarante : la condition est trop étroite. Quatre cents : vous venez de découvrir un problème avant vos clients.

Rendez-la réversible. Avant d'activer une règle qui touche un client, connaissez la réponse à une question simple : si elle se déclenche sur la mauvaise fiche, que fais-je dans les cinq minutes ? Pour une action interne, la réponse est en général annuler. Pour un message sortant, c'est des excuses humaines, et c'est exactement pourquoi les règles sortantes méritent des gardes de données plus strictes. Cette asymétrie doit orienter ce que vous automatisez en premier : les actions internes sont peu coûteuses à rater, les externes non.

Revoyez chaque mois, élaguez chaque trimestre. La revue mensuelle est courte et pose une question par règle : s'est-elle déclenchée à peu près comme prévu ? L'élagage trimestriel est plus dur et demande si la règle décrit encore le fonctionnement de l'entreprise. Le retrait est le geste sous-utilisé ici. Les équipes ajoutent des automatisations avec enthousiasme et n'en retirent presque jamais, et c'est ainsi qu'une entreprise se retrouve avec des règles codant un processus terminé l'an dernier. Une règle qui ne correspond plus à la réalité n'est pas neutre. Elle produit activement de mauvais résultats avec une totale assurance.

Le rythme compte aussi. Une nouvelle règle tous les quinze jours est un bon tempo pour une petite équipe, et c'est plus rapide qu'il n'y paraît : douze automatisations en six mois, c'est davantage que ce que la plupart des entreprises de cette taille mettent jamais en service, et chacune sera comprise par quelqu'un.

Quoi automatiser, et dans quel ordre

Si vous partez de zéro, l'ordre ci-dessous suit les dépendances plutôt que l'attrait.

D'abord, la capture. Tant que les fiches n'existent pas de façon fiable et sans frappe, rien de ce qui est bâti dessus n'est digne de confiance. C'est peu excitant et c'est porteur.

Ensuite, l'attribution. Chaque nouvelle fiche reçoit un propriétaire nommé en quelques minutes, selon une règle assez simple pour que chacun en prédise le résultat.

Puis les deux règles de revenu. Première réponse immédiate à une demande, et relance quand une affaire ouverte s'endort. Elles portent directement sur de l'argent déjà dépensé, elles se mesurent en quinze jours, et elles ne demandent à personne de changer sa façon de travailler.

Puis la relance financière. Rappels de facture avant et après l'échéance, avec une condition d'arrêt explicite au paiement. C'est le seul groupe dont la valeur se compte en jours de trésorerie, ce qui le rend facile à justifier et à vérifier.

Puis le condensé. Un assemblage hebdomadaire de ce qui a bougé, de ce qui s'est tu et de ce qui est dû. Il change la nature de la réunion hebdomadaire plus que tout le reste.

En dernier, tout ce qui est malin. Scoring, logique de branchement, routage multi-conditions, prédictif de toute sorte. Non parce que c'est mauvais, mais parce que chacun multiplie les conséquences des modes de panne ci-dessus, et qu'aucun n'aide si la capture est peu fiable et si la moitié de vos règles n'ont pas de propriétaire.

Automatisez la fiche, pas la relation

La ligne à tenir est celle-ci. L'automatisation CRM doit prendre en charge tout ce qui est mécanique dans le maintien de la vérité : la capter, l'orienter, la mettre à jour, remarquer quand elle s'endort et la restituer en rapports. Elle ne doit pas prendre en charge les parties de la relation client où être humain constitue toute la valeur.

Automatisez la fiche pour qu'elle soit toujours à jour. Automatisez le tempo pour que rien n'attende la mémoire de quelqu'un. Automatisez l'assemblage pour que personne ne passe son lundi matin dans un tableur. Puis investissez le temps récupéré dans la conversation que l'automatisation vient de rendre possible, la seule partie de tout cela dont un client se souviendra.

Essayez Zoye et décrivez votre première règle en une phrase.

Pour aller plus loin, voir la présentation des automatisations de processus, le guide sur le CRM sans saisie de données et l'analyse de pourquoi les déploiements CRM échouent.