Contexte

Elba vend un SaaS en B2B pour sécuriser les SaaS qu’utilisent leurs clients. Des SaaS comme Slack, Google Drive, Notion, Okta, etc. peuvent en effet donner lieu à des échanges d’informations sensibles (e.g partage d’un mot de passe dans Slack).

Le rôle d’Elba est de porter ces évènements à l’attention des responsables de la cybersécurité. Donc, sans surprise, le lead idéal d’Elba dispose d’un responsable de la sécurité dans ses effectifs.

Dans ce contexte, le signal puissant qui présage d’un buying intent, est l’embauche d’un Head of Cybersecurity (+ toutes ses variations). Il est probable qu’en envoyant les campagnes au plus tard 1 mois après le recrutement, les taux de conversion outbound soient sensiblement plus élevés.

Problème

Comme souvent avec les signaux d’intent, le problème n’est pas d’avoir l’idée. C’est même rarement de pouvoir les capter. En réalité, l’information qu’on cherche est disponible en quelques clics seulement sur Sales Navigator.

Non, le problème c’est de :

1. dérouler un workflow complet, de la détection du signal, jusqu’à son activation par les sales

2. de faire scaler ce capteur.

(c’est pas la même chose d’ouvrir Sales Navigator tous les matins et de traiter manuellement une dizaine de signaux, que d’en traiter plusieurs centaines, automatiquement, tous les mois)

Objectifs

Il était convenu en début de mission que le capteur devait :

1. Détecter les mouvements de carrières des personas cible d’Elba.

2. Enrichir les contacts trouvés de leurs coordonnées (téléphone, email).

3. Enregistrer/mettre à jour dans le CRM tous les contacts sur lesquels un signal a été détecté.

4. Enregistrer les entreprises qui leur sont liées dans le CRM.

5. Avertir les sales dès qu’un signal a été détecté afin qu’ils puissent l’actionner.

Solution

Description générale

À grosse maille, voici comment le capteur à changements de poste est constitué :

Sales Navigator [Source de données]

Voici les recherches Sales Navigator à effectuer à intervalles de temps réguliers :

• Recherche 1

• Recherche 2

Ces recherches retournent les personnes correspondant au persona d’Elba à avoir changé de poste ces 90 derniers jours.

En comparant les résultats de deux recherches successives à un jour d’intervalle, on déduit donc les personnes à avoir changé de poste ces derniers jours.

Phantombuster [Extraction des données]

Phantombuster permet d’accomplir des actions automatisées sur LinkedIn.

Airtable [Base de données]

Airtable joue le rôle de base de données. C’est le centre névralgique du capteur construit, constitué de 3 tables principales :

1. Contacts → les personnes qui ont changé de poste.

2. Companies → les entreprises dont elles sont membres.

3. Events → le contenu exact du changement de poste.

La table Contacts est reliée aux tables Companies et Events.

Chaque table comporte plusieurs vues filtrées (”To Convert - FR”, “Conversion in Progress”, “To Enrich - FR”, etc.) correspondant à différentes étapes du process d’enrichissement. On y reviendra.

Datagma, Apollo, Kaspr [Enrichissement]

Encore une fois, c’est bien beau d’identifier les personnes qui ont changé de poste, mais c’est inutile si on ne peut pas les contacter. C’est pour cette raison que je tente de les enrichir en cascade avec Datagma, Apollo et Kaspr pour trouver numéros de téléphones et emails.

Hubspot [CRM]

Il est impensable de s’affranchir d’Hubspot, le CRM. Comme n’importe quelle entreprise sales-led, c’est la seule source de vérité.

C’est donc là qu’il faut mettre à disposition les informations qu’on a récoltées :

• La personne à avoir changé de poste si elle n’existe pas

• Son entreprise si elle n’existe pas non plus

• Une note qui informe du récent changement de poste

Slack [Notifications]

Enfin, comme les informations peuvent atterrir dans le CRM sans que personne ne s’en aperçoive, c’est une bonne idée de doubler les actions dans le CRM de notifications dans Slack. De cette manière, les sales peuvent agir au plus vite et augmenter leurs taux de conversion.

Comment l’implémenter

C’est la partie technique. Elle n’est utile qu’à ceux qui veulent reproduire ce que j’ai fait. J’encourage les autres à passer directement à la partie Résultats.

Extraction et sauvegarde des résultats de Sales Navigator

Pour y parvenir, il fait appel à deux sous-workflows :

Plus précisément, il créé les éléments dans Airtable en 3 étapes, à chaque fois avec des sous-workflows distincts.

D’abord les companies :

Ensuite les contacts :

Enfin les events:

Je repose lourdement sur workflow et sous-workflow. C’est une pratique que je recommande vivement.

On ne fait jamais un énorme workflow qui part dans tous les sens. On le décompose en plus petits workflows, appelés par un plus gros, lui-même appelé par d’encore plus gros. C’est plus simple à comprendre, maintenir et faire évoluer.

Conversion d’URL

Voilà le problème : les résultats de recherche de Sales Navigator sont un peu particuliers. Les URL des profils Sales Navigator sont distinctes des URL des profils LinkedIn.

Or, en vue d’enrichir les contacts qu’on a trouvés, on a besoin des URL LinkedIn, les seules que des outils comme Datagma, Apollo et Kaspr soient en mesure d’interpréter.

Ainsi, j’ai créé une vue filtrée contenant tous les contacts disposant d’une URL Sales Navigator et en attente d’une URL LinkedIn :

Voici le phantom en question :

Le plus simple pour “nourrir” Phantombuster, c’est de lui donner une Google Sheet avec la liste des profils à convertir. C’est donc ce que j’ai fait, grâce à ce workflow n8n :

Ensuite, grâce à une fonctionnalité avancée de Phantombuster, on peut envoyer automatiquement les résultats du convertisseur d’URL au webhook n8n de notre choix pour traitement supplémentaire :

Ensuite, c’est à n8n de traiter les résultats et de les enregistrer dans Airtable :

Enrichissement des contacts

Maintenant qu’on a pu trouver les URL LinkedIn standards des personas d’Elba à avoir récemment changé d’emploi, on peut les donner à manger, en cascade à nos différents outils d’enrichissement (Datagma, Apollo et Kaspr) afin de trouver téléphones et emails.

Tout part de cette nouvelle vue filtrée :

Et encore une fois, j’ai reposé lourdement sur les sous-workflows :

C’est là qu’on s’aperçoit qu’une partie des résultats sont inutilisables. Il est évident qu’on ne trouvera pas a minima un email pour tout le monde.

Enrichissement des entreprises

On n’a parlé que des contacts jusqu’ici mais il y a 2-3 choses en plus à faire avec les entreprises. En effet, on ne peut pas faire abstraction de l’entreprise dont le contact est membre (il est possible qu’elle soit déjà cliente).

Or, déterminer si une entreprise est cliente ou non, ça se passe dans Hubspot. Puisque l’identifiant unique d’une entreprise dans le CRM est son nom de domaine, il faut qu’on trouve cette information.

Voilà pourquoi il faut enrichir les entreprises trouvées.

Encore une fois, on donne “à manger” à Phantombuster par l’intermédiaire d’une spreadsheet, et on récupère les résultats sur un webhook n8n, grâce aux paramètres avancés du phantom.

Mettre les résultats à disposition des Sales

Une fois les contacts et les entreprises enrichis, il faut mettre le fruit de nos recherches dans Hubspot. On ne considère à cet effet que les contacts pour lesquels on a trouvé au moins un mail, et les entreprises correspondantes si on a trouvé leur nom de domaine.

Avec ce workflow, on créera les différentes entités (Contact, Company, Note) dans Hubspot :

Et enfin, une fois les entités créées dans Hubspot, il suffit d’alerter les sales dans Slack :

On fait bien la distinction entre le marché Français et le marché US, traités chacun par différent sales rep. Inutile d’innonder les sales de messages qui ne les concernent pas.

Résultats

Je me dois d’être honnête, Karl a rapidement déchanté, malgré un premier retour très enjoué :

Quelques mois plus tard, il publiait cet avis sur Cargo où je suis à peu près sûr qu’il fait référence au travail qu’on a fait ensemble.

Néanmoins, je ne crois pas que le cœur du problème soit la qualité de mon travail, mais plutôt le format de prestation proposé : une prestation de court terme, tarifée à la valeur ajoutée.

Jusqu’alors, je m’imaginais que je pouvais faire des automatisations très complexes, impliquant tout un tas d’outils, faire un peu de debugging en fin de mission, et qu’ensuite, elles continueraient de tourner indéfiniment sans le moindre bug. Je me trompais.

Ces automatisations ont énormément de valeur, mais il faut quelqu’un pour en assurer la maintenance.

C’est en partie pour cette raison que je propose de m’atteler à ce genre de projets qu’au court de missions de long terme, en tant que Growth Engineer Part-Time, facturée au TJM.

J’idéalisais les prestations packagées, vendues à la valeur ajoutée, qui correspondent assez mal aux projets très techniques comme celui-ci. J’écrirai bientôt à ce sujet.