Prospection B2B par e-mail à froid automatisée avec n8n pour que l’équipe puisse la modifier elle-même

Le client et ses difficultés

Le client dirige une agence B2B qui acquiert des clients par prospection à froid. Il conservait ses contacts dans HubSpot, mais les envois se faisaient en dehors de l’outil : chaque campagne commençait par une copie des données dans un tableur. Un membre de l’équipe remplaçait ensuite à la main le prénom, le nom de l’entreprise et le secteur d’activité dans le message, puis l’envoyait depuis une boîte de réception ordinaire. Pour cent contacts, cela prenait des heures.

Les résultats étaient faibles pour plusieurs raisons. En pratique, tout le monde recevait le même message, quelle que soit son activité, la taille de son entreprise ou l’étape de la conversation ; le taux de réponse restait donc bas. Aucun mécanisme ne détectait non plus les réponses, si bien que les personnes ayant déjà répondu recevaient quand même des relances. C’est le pire scénario en prospection à froid : il détériore précisément la relation qu’on a réussi à établir. Enfin, personne ne savait combien d’e-mails étaient ouverts ni quels objets fonctionnaient, ce qui empêchait toute amélioration.

Le client a posé une condition ferme : la solution devait fonctionner sans code. Il voulait pouvoir modifier lui-même les contenus, l’ordre des messages et les règles, sans demander d’aide.

Ce que nous avons mis en place

Nous avons construit le workflow entier dans n8n pour respecter cette condition. Il commence dans HubSpot : l’automatisation récupère les contacts des listes choisies selon des critères comme le secteur, la taille de l’entreprise ou le statut, puis écarte immédiatement ceux qui ont déjà reçu un message ou répondu.

Les messages sont générés à partir de modèles avec des variables, comme le prénom, le nom de l’entreprise et le secteur. L’envoi passe par AWS SES depuis un domaine dédié, avec rotation des adresses d’expéditeur, car cela influence directement la délivrabilité. La séquence comporte trois étapes : un premier e-mail présentant la proposition de valeur, une relance après trois jours fondée sur un exemple de réalisation, puis un dernier message après sept jours. Chaque étape a son propre modèle : le troisième message ne doit pas ressembler à une répétition du premier.

La détection des réponses s’est révélée essentielle. L’automatisation vérifie si un contact a répondu, au moyen d’un événement entrant ou d’une vérification périodique. Si c’est le cas, son statut dans HubSpot est mis à jour automatiquement et il ne reçoit plus les messages suivants. Sinon, la séquence continue.

Fonctionnement actuel

Pour lancer une campagne, l’équipe commerciale prépare une liste dans HubSpot ; c’est pratiquement tout ce qu’elle a à faire. Le reste s’exécute automatiquement : import des contacts, génération des messages, envoi, délais de trois et sept jours, détection des réponses et mise à jour du statut. Les réponses arrivent dans la boîte du commercial, seul endroit où une intervention humaine reste nécessaire.

La mise en place a pris sept jours. Deux ont servi à analyser le processus, cartographier les segments et configurer les domaines d’envoi. Trois ont été consacrés au workflow et aux tests de toutes les branches conditionnelles. Les deux derniers ont servi à envoyer une campagne à un petit groupe de vrais contacts, surveiller la délivrabilité, comparer les objets et former l’équipe.

Résultats

Une séquence de relance en trois étapes fonctionne automatiquement, sans qu’une personne ait à surveiller un calendrier. La détection des réponses supprime l’erreur la plus coûteuse de l’ancien processus : une personne qui a répondu ne reçoit plus de message. L’envoi par AWS SES depuis un domaine dédié a amélioré la délivrabilité par rapport à une boîte de réception ordinaire. Enfin, comme l’ensemble est sans code, l’équipe modifie elle-même les messages et les règles, sans mobiliser de développeur. Cette condition essentielle du projet est respectée.

Ce que nous ferions autrement

Détecter les réponses par vérification périodique est pratique à mettre en place, mais cette méthode devient imprécise et coûteuse à plus grande échelle. La prochaine fois, nous nous appuierons dès le début uniquement sur les événements entrants et réserverons les vérifications périodiques aux situations de secours.

Deuxième leçon : le domaine aurait dû être mis en chauffe plusieurs semaines avant la première campagne. Nous nous en sommes occupés en parallèle du développement, alors qu’un domaine d’envoi récent démarre avec un handicap, quelle que soit la qualité de sa configuration. Enfin, nous avons intégré tardivement les mesures d’ouverture et de réponse, malgré le manque de données qui posait problème dès le départ. Pour le prochain projet, la collecte de ces données sera le premier élément activé : sans elle, comparer les objets revient à deviner.