Relances commerciales : l’IA doit savoir quand se taire

Le ticket est ouvert depuis vingt minutes quand le mail part. Le client a signalé, pour la deuxième fois, une facture fausse ; il attend une réponse du support. Ce qu’il reçoit, c’est un message chaleureux de son commercial, qui lui propose de passer à l’offre supérieure. Personne n’a commis d’erreur : la séquence de relances commerciales a fait exactement ce qu’on lui avait demandé, au jour prévu, avec le prénom bien orthographié. Elle ne savait rien du ticket.

Ce décalage existe depuis que les relances sont automatisées. Il prend une autre dimension quand un agent IA rédige les messages à la place du modèle figé. Comme on l’expliquait dans notre guide sur ce qu’un agent IA sait faire, et à quelles conditions, un agent agit à partir de ce qu’on lui donne à voir. S’il ne voit que le pipeline commercial, il écrira de très bonnes relances au pire moment.

Ce que vos séquences savent arrêter, et ce qu’elles ignorent

Les outils de relance savent tous s’interrompre. La question est de savoir sur quoi. Chez HubSpot, la liste des cas de désinscription automatique d’une séquence est précise : le contact répond, y compris depuis une autre adresse ou un alias ; il réserve un rendez-vous par le lien du mail ; il se désabonne ; son adresse rebondit ; un collègue de la même société répond, si l’option est cochée. Tous ces signaux viennent de la messagerie ou de l’agenda. La séquence peut aussi réagir à un formulaire rempli ou à une page visitée. Le support n’y figure pas. Pour arrêter une séquence à partir d’autre chose, il faut passer par un workflow, et l’action « retirer de la séquence » n’existe dans les workflows que sur les offres Enterprise de Sales Hub et Service Hub.

Pipedrive suit la même logique. Ses automatisations d’e-mails ne vérifient que deux choses après un délai, d’après sa documentation sur les séquences : le mail précédent a-t-il reçu une réponse, un lien a-t-il été cliqué ? Si la condition n’est pas remplie, l’automatisation s’arrête. L’ouverture des mails n’est pas suivie, et la fonction demande l’abonnement Avancé ou supérieur.

Le constat vaut pour les deux outils : une relance s’arrête sur ce qui se passe dans la boîte mail du commercial. Ce qui se passe ailleurs dans la relation (une réclamation, un retard de paiement, un incident sur le produit) reste invisible pour elle, tant que personne ne l’a branché.

Avec l’IA qui rédige, l’erreur change de nature

Un modèle de mail générique envoyé pendant un litige reste un mail générique. Le client le reconnaît comme tel et l’ignore. Un message rédigé par une IA, qui reprend le dernier échange, cite le projet en cours et propose une suite logique, se lit comme écrit par une personne qui connaît le dossier. Au milieu d’une réclamation, ce soin devient une preuve de négligence : quelqu’un connaissait si bien le client qu’il a pu lui écrire sur mesure, sans voir qu’il était mécontent.

Plus la relance est personnalisée, plus elle doit être informée. C’est la raison pour laquelle les éditeurs de CRM travaillent maintenant sur ce qui alimente le dossier client, autant que sur la rédaction. Attio a présenté fin octobre ses « Activities » : tickets de support, messages privés sur les réseaux et événements du produit deviennent des données structurées, posées sur la fiche du contact ou de l’entreprise, chacune avec son propre schéma. Ces activités peuvent déclencher un workflow, être créées depuis n’importe quelle application reliée à Zapier, et alimenter des rapports, encore au stade alpha. L’éditeur présente la fonction comme une vue complète de la relation, pour les équipes et pour les agents. Il ne publie aucun résultat chiffré, et ce n’est pas le propos : c’est la tuyauterie, pas une promesse de ventes.

Quel que soit l’outil, ce travail se fait avant de confier la plume à l’IA. On le retrouve dans notre analyse de ce que les agents IA changent dans un CRM : la qualité des données passe avant le choix de l’outil.

Trois signaux à faire remonter avant la prochaine relance

Inutile de tout synchroniser. Il suffit que le CRM sache trois choses au moment où une relance va partir, et qu’elles soient rattachées à la bonne entreprise, pas seulement au contact qui a écrit au support.

Le premier signal est le plus fréquent : un ticket ouvert, avec son niveau de gravité. Une question d’utilisation ne pèse pas autant qu’une panne ou qu’une erreur de facture. Le deuxième vient de la comptabilité : une facture contestée, un avoir en attente, un retard de paiement. Il vit souvent dans un autre logiciel et c’est lui que l’on oublie. Le troisième vient du produit, quand l’entreprise en vend un : un incident en cours, ou un usage qui s’effondre depuis quelques semaines. Ce dernier est le plus difficile à brancher et le plus utile pour un renouvellement.

Le piège tient au rattachement. La personne qui ouvre un ticket est rarement celle que le commercial relance : l’utilisateur écrit au support, l’acheteur reçoit les propositions. Si le CRM ne relie pas les deux à une seule fiche entreprise, le signal remonte bien, mais sur une fiche que la séquence ne regarde pas.

Une règle qui suspend, une règle qui reprend

Arrêter les relances ne suffit pas. Un client sorti de la séquence pendant sa réclamation et jamais relancé ensuite, c’est une affaire perdue en silence. Il faut donc deux règles, et c’est la seconde que l’on oublie.

La première suspend. Dès qu’un des trois signaux apparaît sur l’entreprise, les relances en cours sont mises en pause pour tous ses contacts, et le commercial propriétaire est prévenu par une tâche, avec le motif. Suspendre plutôt que désinscrire : la séquence garde sa place, rien n’est perdu.

La seconde reprend. Quand le ticket est clos ou la facture réglée, la reprise ne se fait pas immédiatement. Un délai de quelques jours, fixé par l’équipe, laisse au client le temps de constater que le problème est résolu. Puis l’IA prépare le premier message de reprise, et c’est là que la validation humaine a le plus de valeur. Ce message n’est pas une relance comme les autres : il doit tenir compte de ce qui s’est passé, sans en faire trop. Le commercial le relit, le corrige si besoin, et l’envoie lui-même. Les messages suivants peuvent repartir en automatique.

Ce découpage applique ce que nous décrivions à propos des étapes à confier à un agent et de celles à garder : la rédaction et le suivi des délais passent à la machine ; le message qui engage la relation après un incident reste humain, tant que l’on n’a pas vérifié sur plusieurs cas que l’IA le réussit.

Le chiffre à relever avant de brancher quoi que ce soit

Avant de choisir un outil ou d’écrire une règle, une question permet de savoir si le chantier en vaut la peine : combien de relances sont parties, sur les trois derniers mois, vers une entreprise qui avait un ticket ouvert ce jour-là ? Il suffit d’exporter les envois de séquences et les tickets, et de les croiser par société et par date. Le chiffre est souvent plus élevé qu’on ne l’imagine, parce que personne ne l’a jamais calculé.

S’il est faible, une consigne aux commerciaux suffit peut-être. S’il ne l’est pas, le travail commence par le rattachement des contacts aux entreprises, se poursuit par les deux règles, et se termine seulement par la rédaction confiée à l’IA. Dans cet ordre, l’agent écrit des relances qui tombent au bon moment. Dans l’ordre inverse, il écrit vite et bien des messages qui n’auraient jamais dû partir.