Comment relancer automatiquement chaque lead selon son étape dans Attio ?

Dans Attio, un workflow réagit à un changement sur une fiche, et une séquence envoie une suite d'emails à une personne. Relancer un lead selon son étape, c'est relier les deux : savoir où il en est, et lui envoyer le message qui le fait passer à l'étape suivante. Simple sur le papier. En pratique, les leads sautent des étapes, arrivent déjà avancés, déclenchent plusieurs workflows à la fois, et chaque bloc qui agit coûte un crédit.

La réponse courte

Construisez un workflow par étape du cycle de vie, et faites-lui tout faire : changer l'étape et inscrire le lead dans la séquence qui va avec. Chaque workflow suit le même ordre : un trigger Attribute value changed sur la donnée que votre équipe saisit, un delay (plus court pour les étapes les plus avancées), un filter qui vérifie l'étape actuelle et la nouvelle valeur, un switch qui sort le lead de sa séquence en cours, puis la mise à jour du cycle de vie et l'inscription dans la nouvelle séquence. Dans le nouveau builder d'Attio, delay, filter et switch ne consomment aucun crédit : un lead qui n'est pas concerné ne coûte rien.

Quel est le prérequis avant de construire quoi que ce soit ?

Vous ne pouvez relancer par étape que si l'étape se lit dans vos données. Avant de toucher à un workflow, répondez précisément à une question : qu'est-ce qui fait qu'un lead est à telle étape plutôt qu'à telle autre ?

Si aucun attribut ne porte cette réponse, il faut la trouver ou la connecter. Parfois c'est un travail de recherche dans vos outils, parfois une connexion technique entre votre plateforme et le CRM. Il n'existe pas de raccourci : une séquence branchée sur une étape mal définie envoie le bon message aux mauvaises personnes.

Pourquoi le cycle de vie doit-il être écrit par le CRM, et pas par l'équipe ?

Parce que votre équipe a mieux à faire. Elle doit saisir la donnée que personne d'autre ne peut capturer : la date d'un rendez-vous, le résultat d'un appel, une case cochée. Pas un statut.

Fixez des règles claires, et laissez le CRM recouper ces informations pour attribuer l'étape lui-même. Vous y gagnez deux choses : un cycle de vie toujours juste, et la preuve que vous avez réellement compris comment vos leads avancent. Si une règle ne s'écrit pas, c'est que le process n'est pas encore clair.

Le cycle de vie, c'est le CRM qui l'écrit. Jamais l'équipe.

Faut-il des workflows séparés pour le cycle de vie et pour les relances ?

Non. La tentation est grande de construire d'un côté les workflows qui tiennent le cycle de vie, et de l'autre ceux qui déclenchent les relances. Vous vous retrouvez alors avec deux systèmes qui observent les mêmes données et doivent rester d'accord entre eux.

Prenons un cycle de vie courant pour une plateforme en ligne : nouveau lead, lead qualifié, compte créé, profil rempli, en closing, client, repeater. Les relances suivent exactement ces étapes. Tant que le lead n'a pas de compte, on l'invite à en créer un. Une fois le compte créé, on l'aide à remplir son profil. Le workflow qui fait passer un lead à l'étape « compte créé » est donc le mieux placé pour l'inscrire dans la séquence « remplir son profil ». Un seul workflow par étape, et deux systèmes en moins à synchroniser.

Toutes les étapes n'ont pas besoin d'une séquence. Un client ou un repeater n'a pas forcément de relance : son workflow se contente de mettre à jour l'étape.

Quel déclencheur utiliser ?

Attribute value changed, sur l'attribut métier qui fait avancer le lead : la date de création du compte, la case « profil complété », la date de signature. Jamais sur le cycle de vie lui-même : c'est lui que le workflow s'apprête à écrire.

Ce trigger a une propriété décisive : il se déclenche aussi à la création du record, si l'attribut reçoit une valeur à ce moment-là. Un lead importé depuis votre plateforme, ou créé à la main, avec un compte déjà ouvert, est donc bien pris en charge. Le trigger Record updated, lui, ne se déclenche pas dans ce cas.

Pourquoi ajouter un delay, et dans quel ordre ?

Parce que plusieurs workflows peuvent partir en même temps. Un lead créé directement à l'étape « profil rempli » porte déjà la date de création de compte et la case profil complété : les workflows de plusieurs étapes se déclenchent à la même seconde. S'ils s'exécutent dans le désordre, l'étape finale dépend du hasard.

La règle : un delay dans chaque workflow, plus court pour l'étape la plus avancée, un peu plus long pour l'étape précédente, et ainsi de suite jusqu'à la plus jeune. Le workflow de l'étape la plus avancée passe donc toujours en premier. Quand les autres arrivent, leur filter lit l'étape actuelle, constate qu'elle est déjà plus avancée que celle qu'ils voulaient écrire, et s'arrête là. On remonte ainsi la chaîne de la fin vers le début, sans qu'aucun workflow n'écrase le travail d'un autre.

Quelques secondes d'écart entre deux étapes suffisent. Deux secondes fonctionnent ; cinq secondes vous laissent plus de marge. Avec sept étapes, cela donne par exemple 5 secondes pour repeater, 10 pour client, 15 pour en closing, et ainsi de suite jusqu'à 35 pour nouveau lead. Un écart régulier a un autre avantage : le jour où une étape s'ajoute entre deux autres, elle trouve sa place sans que vous retouchiez tous les workflows. Et comme le cycle de vie tourne en arrière-plan, quelques secondes de plus ne gênent personne.

Que doit vérifier le filter ?

Deux choses, pas une :

1. La nouvelle valeur répond-elle aux critères de cette étape ?
2. L'étape actuelle est-elle bien moins avancée que celle que le workflow s'apprête à écrire ?

C'est le second contrôle qui empêche les retours en arrière. Un trigger peut se déclencher plusieurs fois, et une même action vaut souvent pour deux étapes. L'action qui fait d'un prospect un client est aussi celle qui fait d'un client un repeater, un client qui revient. Sans contrôle de l'étape actuelle, chaque nouveau déclenchement fait retomber le repeater au rang de client. Un repeater est un repeater pour toujours.

Le filter porte aussi vos exclusions avant toute inscription dans une séquence :

• Le lead est perdu. On ne relance pas.
• Il a demandé à ne plus recevoir de relances, tout en restant intéressé. Il n'est pas perdu pour autant, il ne veut simplement plus d'emails.
• Une date de rappel est fixée dans le futur. Le contacter avant cette date n'a aucun sens.

Combien de crédits ce système consomme-t-il ?

Dans le nouveau builder d'Attio, un bloc ne consomme de crédit que s'il écrit une donnée, envoie ou reçoit quelque chose à l'extérieur, ou utilise l'IA. Le trigger, le delay, le filter et le switch sont donc gratuits. Seuls les blocs qui agissent coûtent un crédit chacun : la sortie d'une séquence, la mise à jour du cycle de vie, l'inscription dans une séquence.

C'est ce qui rend l'ordre trigger, delay, filter si efficace. Un lead qui ne remplit pas les conditions s'arrête au filter et ne coûte rien. Les crédits ne partent que pour les leads qui changent réellement d'étape. Attention : dans les anciens workflows d'Attio, le delay coûte un crédit. Cette construction vaut pour le nouveau builder.

Comment sortir le lead de la séquence précédente ?

C'est le point délicat. Le bloc Exit from sequence vise une séquence précise : il n'existe pas de bloc « sortir de toutes les séquences ». Et chaque sortie coûte un crédit. Enchaîner un bloc de sortie par séquence existante, au cas où, coûte cher pour rien.

La parade tient dans la structure elle-même. Puisque chaque étape a sa séquence, l'étape actuelle du lead vous dit dans quelle séquence il se trouve. Juste après le filter, et avant de mettre à jour le cycle de vie, placez un switch sur l'étape actuelle : une branche par étape qui possède une séquence, avec un seul bloc Exit from sequence au bout. Le lead ne sort que de la séquence où il est, pour un seul crédit, même s'il saute directement de « nouveau lead » à « profil rempli ».

Le workflow complet d'une étape :

1. Trigger Attribute value changed, sur l'attribut métier.
2. Delay, selon le rang de l'étape.
3. Filter : nouvelle valeur, étape actuelle, exclusions.
4. Switch sur l'étape actuelle, puis Exit from sequence de la séquence correspondante.
5. Update record : le cycle de vie prend la nouvelle étape.
6. Enroll in sequence : la séquence de la nouvelle étape, si elle en a une.

Deux sorties se font sans aucun workflow, grâce aux critères de sortie des séquences Attio : quand le lead répond à un email de la séquence (toujours actif), et quand il réserve un rendez-vous avec l'expéditeur (à ajouter dans chaque séquence). Pensez à ajouter le second : un lead qui a pris rendez-vous n'a plus besoin d'être relancé.

Faut-il toujours se baser sur le cycle de vie ?

Par défaut, oui. Si l'information peut vivre dans le cycle de vie, mettez-la dans le cycle de vie. C'est d'ailleurs souvent la bonne réponse quand vous hésitez : détaillez un peu plus le cycle de vie, plutôt que de construire un système de relance à côté.

On descend à un attribut plus fin uniquement quand le message doit changer à l'intérieur d'une même étape. Une personne qui a commencé à remplir son profil ne doit pas recevoir le même rappel que celle qui ne l'a jamais ouvert : elles sont à la même étape, mais la relance n'est pas la même.

Comment écrire la séquence elle-même ?

Aussi personnelle que possible, aussi générique que nécessaire pour rester juste pour tous ceux qui y entrent. Trouver cet équilibre, c'est le vrai travail.

La mécanique décrite plus haut garantit que le bon lead reçoit la bonne séquence au bon moment. La séquence, elle, doit lui donner une raison de passer à l'étape suivante.

À quoi ça ressemble sur le terrain ?

Nous avons construit ce système chez une société d'investissement en marchés privés, dont nous avons monté le CRM Attio depuis zéro. Son cycle de vie client va du nouveau lead au repeater, et il est tenu entièrement par des workflows : personne dans l'équipe ne le modifie à la main. Quelques secondes d'écart séparent chaque étape, et la sortie de séquence passe par un switch sur l'étape actuelle.

Que retenir ?

• L'étape doit se lire dans vos données avant toute construction.
• Un cycle de vie écrit par les workflows, jamais par l'équipe.
• Un seul workflow par étape, qui tient à la fois le cycle de vie et la relance.
• Trigger Attribute value changed sur l'attribut métier, jamais sur le cycle de vie.
• Un delay par workflow, du plus court (étape la plus avancée) au plus long.
• Un filter sur la nouvelle valeur et l'étape actuelle : aucun retour en arrière, aucun crédit gâché.
• Un switch sur l'étape actuelle pour sortir le lead de la seule séquence où il se trouve.

Questions fréquentes

Le trigger Attribute value changed se déclenche-t-il à la création d'un record ?

Oui, si l'attribut reçoit une valeur au moment de la création. C'est ce qui le rend préférable à Record updated, qui ne se déclenche pas dans ce cas.

Le delay et le filter consomment-ils des crédits dans Attio ?

Pas dans le nouveau builder de workflows : un bloc ne consomme de crédit que s'il écrit une donnée, envoie ou reçoit quelque chose à l'extérieur, ou utilise l'IA. Dans les anciens workflows, le delay coûte un crédit.

Peut-on sortir un contact de toutes ses séquences Attio d'un coup ?

Non. Le bloc Exit from sequence vise une séquence précise. Pour ne sortir le contact que de la bonne, placez un switch sur son étape actuelle, avant de mettre son cycle de vie à jour.

Un lead sort-il automatiquement d'une séquence quand il répond ?

Oui, ce critère de sortie est toujours actif, à condition que la réponse arrive sur le fil d'emails de la séquence. La sortie quand il réserve un rendez-vous avec l'expéditeur existe aussi, mais il faut l'ajouter dans chaque séquence.