Relancer les deals refroidis

Closed-lost, c'est là où les deals vont pour être oubliés. La raison de la perte est tapée dans une liste déroulante, le fil s'arrête, et dix-huit mois plus tard plus personne ne se souvient que le seul blocage était un cycle budgétaire qui a depuis tourné deux fois, ou une fonctionnalité livrée le printemps dernier. Les relire est un travail qui prendrait une journée entière à un commercial pour produire peut-être quatre emails qui valent d'être envoyés, donc ça ne remonte jamais en haut de la liste de personne.

Tout ce qu'il faut pour relancer un deal closed-lost est déjà écrit quelque part, à quatre endroits différents. Le CRM porte la raison de la perte, le registre public porte ce qui s'est passé chez l'entreprise depuis, les profils portent qui est encore là, et l'outil de suivi des tickets porte ce que vous avez construit depuis. La partie coûteuse, c'est de lire chaque historique de deal contre quatre systèmes pour trouver les quelques-uns qui méritent d'être rouverts, et c'est cette lecture qu'un agent IA fait ici une fois par mois.

Quels deals closed-lost entrent dans le périmètre

L'exécution liste les deals dans Attio marqués perdus depuis plus de 90 jours. Quatre-vingt-dix jours, c'est le plancher : en dessous, la raison de la perte est presque toujours encore vraie, et l'email se lit comme n'ayant pas écouté. Vingt-quatre mois, c'est le plafond, car au-delà, les personnes impliquées sont passées à autre chose et le message est un cold email déguisé en relance. Trois types de deals sont exclus d'office : ceux perdus face à un concurrent sur un contrat pluriannuel qui n'a pas encore expiré, quiconque a demandé à ne plus être contacté, et les comptes avec une opportunité ouverte en ce moment.

Pourquoi le champ de raison de perte ne suffit pas

Le champ de raison de perte est traité comme un indice. C'est une liste déroulante choisie à la fin d'une mauvaise semaine, et presque tout finit sur « prix ». Les notes, appels journalisés et fils d'emails en dessous racontent une autre histoire assez souvent pour changer l'email du tout au tout, car « prix » veut souvent dire pas de budget cette année, ou une revue de sécurité qui n'est jamais passée. « Je sais que le prix était un problème » est un modèle. « Je sais que la revue de sécurité a calé en octobre » prouve que quelqu'un a lu l'historique.

Chaque deal est classé dans l'une de quatre raisons, avec la preuve enregistrée : timing ou budget, une fonctionnalité manquante nommée précisément, perdu face à un concurrent, ou pas de décision. Cette précision est ce sur quoi s'appuient les étapes suivantes. « Perdu sur les fonctionnalités » ne peut être rapproché de rien. « Perdu car il n'y avait pas de journal d'audit » peut être recherché contre chaque ticket clos depuis, et quand cette recherche revient avec une date de livraison, la relance a un sujet.

Ce qui a changé depuis la perte du deal

Trois choses sont vérifiées pour chaque compte, chaque élément avec une date.

• L'entreprise. Apify cherche des recrutements, surtout dans la fonction où vous vendez, ainsi que des levées de fonds, une acquisition, un nouveau bureau ou marché, et des changements de direction au niveau ou au-dessus du rôle acheteur. L'URL source est gardée pour tout ce que l'email référencera, car une relance qui cite quelque chose que le lecteur peut vérifier est un message différent de celui qui fait juste allusion à une dynamique.
• Les personnes. Chaque contact est vérifié contre son profil LinkedIn. Quelqu'un encore présent reçoit l'email. Quelqu'un parti, avec un remplaçant trouvable au même poste, est substitué comme destinataire, et le message d'ouverture ne référence jamais une conversation à laquelle la nouvelle personne n'a pas participé. Quelqu'un parti vers une entreprise déjà dans votre CRM est signalé séparément comme une introduction chaleureuse là-bas, souvent plus précieuse que la relance elle-même.
• Le produit. Pour chaque deal perdu sur une fonctionnalité manquante, Linear est recherché pour ce qui a été livré depuis la clôture du deal, rapproché sur le fond plutôt que sur les mots. Un acheteur qui voulait « un moyen de voir qui a changé quoi » et un ticket livré intitulé « journal d'audit » sont la même chose.

La date de livraison compte autant que la correspondance. Une fonctionnalité livrée la semaine dernière est une nouvelle. Une livrée il y a quatorze mois est un aveu que personne ne les a prévenus à l'époque, et l'email a plus de valeur à le dire clairement qu'à présenter une livraison vieille d'un an comme si elle venait d'arriver.

Choisir les deals qui méritent d'être rouverts

Avec la raison de perte, les signaux frais, la situation des contacts et ce qui a été livré côte à côte, un deal mérite d'être rouvert quand l'un de ces éléments répond à la raison de la perte :

• perdu sur une fonctionnalité manquante, et cette fonctionnalité existe désormais
• perdu sur le timing ou le budget, et il y a une levée de fonds, un nouvel exercice fiscal ou une nouvelle personne au rôle acheteur
• perdu face à un concurrent, et leur contrat approche de sa fenêtre de renouvellement
• s'est tu, et la personne qui s'est tue a été remplacée

Là où rien ne répond à la raison de la perte, le deal est écarté et compté. L'instinct est d'écrire à tout le monde, car la liste est juste là et la rédaction ne coûte rien. Ce sont pourtant des comptes qui ont déjà dit non une fois, et un second contact sans information nouvelle est ce qui use la réputation d'un domaine. Compter les abandons plutôt que les cacher garde cela visible.

Chaque deal qui reste reçoit un brouillon dans Gmail : ce qui s'est passé, à peu près quand, ce qui a changé, et une question. Si une fonctionnalité a été livrée, l'email dit ce qu'elle fait. Rien n'est envoyé. Le lot part sur Slack avec combien de deals étaient dans le périmètre, combien ont été écartés et pourquoi, et les brouillons groupés par raison de perte, si bien que chaque propriétaire de compte peut parcourir les siens.