4 min

1:1

Rappel quotidien des tâches Lemlist en 1:1 Teams avec n8n

Chez Dolist, les séquences de prospection Lemlist génèrent des tâches manuelles (appel, message LinkedIn, visite de profil) que personne ne voit, parce que personne ne vit dans Lemlist. J’ai monté un petit workflow n8n qui envoie chaque matin à chaque commercial, en message Teams 1:1, la liste de ses tâches du jour et du lendemain.

Le problème

L’outil de travail réel des commerciaux, c’est Teams. Résultat : des tâches Lemlist qui s’accumulent sur plusieurs jours et ne ressortent qu’au point hebdomadaire, bien après l’échéance. Ce n’est pas un problème de discipline, c’est un problème de canal.

Le natif Lemlist ne couvrait pas le besoin :

  • Les emails portent sur la santé des campagnes (boîte déconnectée, bounces, fin de campagne), pas sur les tâches.
  • L’intégration Slack est le seul canal lié aux tâches, mais l’équipe est sur Teams, elle ne couvre que les tâches nées d’une activité du lead (réponse, clic), pas les tâches « Manual task » ou « Call » posées dans une séquence, et elle notifie tâche par tâche au lieu d’une synthèse le matin.

Ce que j’ai construit

flowchart TD
    A["Schedule Trigger\n0 7 * * 1-5 (jours ouvres, 7h Paris)"] --> B["HTTP Request\nGET api.lemlist.com/api/tasks\nfiltre dueDate = aujourd'hui -> demain"]
    B --> C["Code : grouper par commercial\nfiltre + regroupe + formate le message"]
    C --> D{"Switch sur userId Lemlist"}
    D --> E["Teams 1:1 Commercial A"]
    D --> F["Teams 1:1 Commercial B"]
    D --> G["Teams 1:1 Commercial C"]
    D --> H["Teams 1:1 Commercial D"]
  • Déclencheur : cron 0 7 * * 1-5, fuseau Europe/Paris. Le rappel arrive avant la prise de poste, jamais le week-end.
  • Appel API : GET https://api.lemlist.com/api/tasks avec un filtre dueDate d’aujourd’hui à demain. La fenêtre sur deux jours évite de rater une tâche à cheval sur le changement de date. L’API ne filtre que par date, donc tout le reste est fait dans le nœud suivant.
  • Nœud Code : le cœur du workflow. Il normalise la réponse, garde les tâches au statut vide ou pending, exclut la tâche système "Out of office detected", regroupe par userId et construit le message : une icône par type (📞 appel, 💬 message LinkedIn, 👀 visite de profil…), les dix premières tâches avec « aujourd’hui » ou « demain », puis ...et N autre(s).
  • Switch + Teams : une règle par userId Lemlist, en dur, chacune reliée à un nœud Microsoft Teams (chatMessage) qui cible la conversation 1:1 entre le commercial et le compte technique du workflow.

La forme de la réponse Lemlist (tableau brut ou objet results/tasks/data/items) n’étant pas garantie, une petite fonction défensive évite une panne silencieuse :

function toArray(x) {
  if (Array.isArray(x)) return x;
  if (x && typeof x === 'object') {
    for (const key of ['results', 'tasks', 'data', 'items']) {
      if (Array.isArray(x[key])) return x[key];
    }
  }
  return [];
}

Le filtre "Out of office detected" a été ajouté après avoir vu ces tâches polluer le premier message de test.

Les limites

Les commerciaux non mappés tombent dans le vide

Le Switch ne connaît que quatre userId. Une tâche d’un cinquième commercial, ou sans userId (clé 'non_assigne' dans le code), ne matche aucune règle et n’a aucune sortie : le message est perdu sans erreur visible. Ajouter un commercial oblige à modifier le Switch et à créer un nœud Teams.

  • Pas de lien vers la tâche. Le commercial doit rouvrir Lemlist pour agir.
  • Pas de relance des tâches en retard. Une tâche non traitée sort simplement de la fenêtre une fois sa date passée.
  • Une incohérence entre branches. Trois nœuds Teams lisent $('Grouper par commercial').item.json.message, le quatrième $json.message avec contentType: html en plus. Même résultat aujourd’hui, mais un vrai bug en puissance si on fusionne des branches.

À refaire : remplacer le Switch par une table de correspondance (Data Table n8n) avec une branche de repli pour les userId inconnus, ajouter un lien vers chaque tâche si l’API l’expose, et harmoniser les expressions des nœuds Teams.

À retenir

Ce workflow ne fait rien de spectaculaire : il déplace une information qui existait déjà vers le canal où elle est vue. En RevOps, la valeur est souvent là, dans le choix du canal plus que dans la technique. Le mapping figé suffit pour quatre personnes, il est à revoir avant de passer à l’échelle.

Le même routage « un Switch par destinataire, un nœud Teams par branche » a ensuite servi ailleurs : voir Générer des posts LinkedIn avec l’IA via n8n.

À lire aussi

2Enrichir automatiquement des contacts Lemlist avec Apollo via n8n10 minLe récap hebdo des demandes de contact, avec Claude4Détection IA de signaux d’affaires : construire un système RevOps utile