ooligo
n8n-flow

Triage et routage des leads inbound avec n8n + Claude

Difficulty
intermédiaire
Setup time
90min
For
revops · sdr-leader
RevOps

Stack

Un flow n8n qui capte chaque demande de démo inbound au moment où elle arrive, la score par rapport à votre rubric ICP avec Claude, l’enrichit avec des données firmographiques, et la route vers un flow en libre-service, une file SDR par territoire, ou une page Slack vers l’AE d’astreinte. Le bundle dans apps/web/public/artifacts/inbound-lead-triage-n8n/ livre l’export complet plus un _README.md couvrant l’import, la configuration des credentials et la vérification par branche.

Quand l’utiliser

Utilisez-le quand vous avez un volume significatif de demandes de démo inbound — environ 50+ par semaine — et que les SDRs passent du temps réel sur des leads qui n’auraient jamais dû atteindre un humain, ou laissent des leads à haute intention genuinement assis dans une file pendant qu’ils traitent les plus anciens en premier-entré-premier-sorti. Le symptôme qui justifie la construction est un temps de réponse inégal : vos meilleurs leads attendent des heures derrière vos pires.

C’est aussi le bon pattern quand votre rubric ICP est assez tranché pour que deux SDRs scoreraient le même lead différemment. Une fois que le rubric vit dans un seul document Markdown que Claude lit à chaque appel, le scoring devient cohérent entre les soumissions et révisable comme un seul artifact.

Quand NE PAS l’utiliser

Évitez-le si vous recevez moins de ~10 demandes de démo inbound par semaine. À ce volume, la décision de routage SDR est plus rapide faite à la main, et vous passerez plus de temps à maintenir le flow qu’il n’en économise. Le coût fixe de la rotation des credentials, les audits de dérive du rubric et l’inévitable page Slack à 3h du matin pour un timeout Claude dépasse le gain par lead.

Évitez-le aussi si votre ICP est réellement indéfini. Le flow est un multiplicateur sur votre rubric — si « bon lead » est ce que le responsable SDR ressentait ce matin-là, l’automatiser ne fait que figer le biais de ce jour dans 10 000 routages. Écrivez d’abord le rubric ; automatisez-le ensuite.

Enfin, n’utilisez pas ceci si votre mouvement commercial est strictement product-led et que votre formulaire de « demande de démo » est en réalité une invite de création de compte déguisée. Dans ce cas, le bon pattern est les déclencheurs d’activation in-product, pas une couche de triage prétendant que le formulaire est le point d’entrée.

Configuration

  1. Importez le bundle. Déposez apps/web/public/artifacts/inbound-lead-triage-n8n/inbound-lead-triage-n8n.json dans n8n via Workflows → Import from File. Le flow a deux points d’entrée : un webhook pour le chemin en temps réel et un cron quotidien pour le sweep de filet de sécurité.
  2. Câblez HubSpot. Créez les quatre propriétés de contact personnalisées listées dans _README.md (icp_score__c, icp_score_reasoning__c, icp_pain_hypothesis__c, icp_scoring_method__c). Configurez un workflow HubSpot qui POST vers /webhook/inbound-lead-triage à chaque fois qu’un contact soumet un formulaire de demande de démo, en transmettant contactId et le contexte du formulaire.
  3. Configurez Claude. Définissez la variable de workflow n8n ICP_RUBRIC sur votre rubric Markdown (gardez-le sous ~2k tokens — il est livré dans chaque appel). Le modèle par défaut est claude-haiku-4-5 ; le prompt impose un output JSON uniquement et des règles de fallback explicites pour les données manquantes et les adresses email gratuites.
  4. Définissez les règles de territoire. Remplissez la Google Sheet référencée par PLACEHOLDER_TERRITORY_SHEET_ID avec une ligne par pays plus une ligne * par défaut. Colonnes requises : country, sdr_email, sdr_owner_id, sdr_slack_handle, ae_email, ae_owner_id, ae_slack_handle.
  5. Vérifiez chaque branche. Parcourez la vérification en cinq étapes dans _README.md (score faible, score moyen, score élevé, échec Claude, filet de sécurité). N’activez le déclencheur HubSpot qu’après que les cinq ont réussi.

Ce que le flow fait

Le webhook accepte le payload de soumission de formulaire HubSpot et retourne immédiatement un 202 pour que la soumission de formulaire ne soit jamais bloquée par l’enrichissement ou le scoring. Normalize Payload (un nœud Code) aplatit l’enveloppe HubSpot en une seule forme JSON, met l’email en minuscules, extrait le domaine, et signale les fournisseurs d’email gratuits depuis un ensemble codé en dur pour que les nœuds en aval n’aient jamais à re-dériver ce signal.

Apollo — Enrich Domain appelle l’endpoint d’enrichissement d’organisation d’Apollo avec un timeout de 8s et neverError: true. Les échecs n’arrêtent pas le flow — ils produisent juste un payload avec enrichmentOk: false, que l’étape de scoring est instruée de traiter comme une pénalité d’un point. Merge Lead + Firmographics combine le lead normalisé et l’enrichissement dans le bundle que Claude voit.

Claude — Score Lead poste vers https://api.anthropic.com/v1/messages avec claude-haiku-4-5, un timeout de 6s, et un prompt système qui impose un seul objet JSON avec score, reasoning, primary_pain_hypothesis et disqualifiers. Le prompt dit explicitement à Claude de biaiser le score vers le bas de 1 quand les firmographiques sont manquants et de plafonner les adresses email gratuites à 4 sauf si les réponses du formulaire prouvent un vrai rôle — ces deux règles appartiennent au prompt plutôt qu’au code pour être auditables en un seul endroit.

Parse Score (with fallback) est le nœud le plus important. Il essaie de parser le JSON de Claude ; si le parsing échoue ou si le score est manquant, il calcule un score déterministe à partir de l’effectif + titre du poste + statut email gratuit. L’output porte toujours scoringMethod: "claude" ou "rule-based" pour que l’audit hebdomadaire puisse repérer quand l’utilisation du fallback augmente.

HubSpot — Upsert Score réécrit le score, le raisonnement, l’hypothèse de douleur et la méthode dans le contact pour que les SDRs voient pourquoi un lead a atterri dans leur file, pas seulement qu’il l’a fait. Route by Score est un nœud Switch avec trois branches explicites plus un fallback unrouted : score < 4 va en nurture libre-service, 4-7 va dans la file SDR (après un Sheets — Territory Lookup), 8+ page l’AE dans #inbound-hot, et tout ce qui passe à travers alerte les ops dans #inbound-ops-alerts.

Le deuxième point d’entrée — Nightly Backstop Cron à 02h15 — recherche dans HubSpot tout contact en stade abonné avec une recent_conversion_date dans les dernières 26 heures et sans icp_score__c, puis rejoue chacun via le webhook avec des appels par lots (batchSize: 5, batchInterval: 2000ms) pour que le rattrapage ne brûle pas les limites de débit.

Réalité des coûts

Par lead, avec claude-haiku-4-5, un appel de scoring typique représente environ 1,2k tokens d’entrée (rubric + bundle lead) et 200 tokens de sortie. Au tarif de Haiku 4.5, c’est environ 0,0015 $ par lead. L’enrichissement d’organisation Apollo au niveau Basic est environ 0,01-0,05 $ par crédit selon le plan ; budgétez 0,02 $ par lead comme chiffre de planification. n8n auto-hébergé est gratuit ; n8n Cloud Starter est 20 $/mois et gère facilement 10k exécutions.

Pour une équipe recevant 1 000 demandes de démo inbound par mois, le coût marginal total est sous 25 $/mois pour Claude + Apollo combinés. Le coût non marginal est l’heure du responsable SDR par semaine pour auditer un échantillon de leads scorés et affiner le rubric — c’est ce qui fait fonctionner ceci, pas ce qui le rend coûteux.

Métriques de succès

La métrique à observer est le délai médian de premier contact sur les leads score 8+. Avant ce flow, ce chiffre est dominé par la profondeur de la file SDR et l’heure de la journée. Après, il devrait tomber à moins de 5 minutes pendant les heures ouvrables car l’AE est paginé dans Slack avec le contexte complet au moment où le formulaire est soumis.

Une métrique secondaire est le pourcentage d’inbound qui atteint un humain. Si le flow est honnête, ce chiffre baisse de 30-50 % (les leads à score faible vont maintenant en nurture plutôt que dans une file SDR), et le taux de conversion SDR sur les leads qui atteignent effectivement un humain devrait augmenter en conséquence. Si vous voyez le premier mouvement sans le second, votre rubric filtre mal.

Alternatives

vs script Python DIY sur un cron. Un script en cron qui poll HubSpot toutes les 5 minutes ajoute 5 minutes de latence dans le pire cas et 2,5 en moyenne, ce qui tue tout l’intérêt de pager sur les leads à haute intention. Le flow n8n piloté par webhook est sub-seconde sur le chemin nominal. Vous obtenez aussi le journal d’exécution n8n comme couche d’observabilité gratuite au lieu de déboguer le stdout d’un script.

vs HubSpot Workflows + Operations Hub. HubSpot peut router par règles statiques (pays, taille de deal, champs de formulaire) mais ne peut pas appeler Claude avec un rubric et parser du JSON structuré sans un Custom Code Action — et une fois que vous écrivez du code personnalisé dans HubSpot, vous avez perdu la visibilité et la gestion des credentials que vous obtiendriez de n8n. Operations Hub Professional est aussi 800 $/mois avant d’avoir écrit une ligne de logique.

vs un routeur de leads prêt à l’emploi (Chili Piper, Distribute, RevenueHero). Ces outils excellent à l’étape de routage et de réservation de réunion et valent la peine d’être achetés si la réservation au premier contact est votre mouvement. Ils ne sont pas bons pour « scorer le lead avec mon rubric avant de décider quoi en faire » — c’est le travail que ce flow fait, et les deux se composent proprement : routez ici, puis passez les leads à score élevé à Chili Piper pour l’expérience de réservation.

Points de vigilance

  • Fiabilité du webhook. Les webhooks sortants de HubSpot échouent silencieusement à l’épuisement des tentatives. Protection : le Nightly Backstop Cron balaie tout contact en stade abonné avec une conversion récente dans les dernières 26 heures et sans icp_score__c, rejouant chacun via le même webhook. Si vous voyez des captures du filet de sécurité au-dessus de ~2 % du volume quotidien, escaladez vers le support HubSpot — c’est un vrai problème de fiabilité, pas un problème de paramétrage.
  • Latence Claude ou JSON malformé. Les inbound ont besoin d’un routage rapide ; Claude peut parfois prendre 5+ secondes ou retourner de la prose autour du JSON. Protection : le nœud Claude — Score Lead a un timeout de 6s et neverError: true, et Parse Score (with fallback) revient à un score déterministe basé sur des règles (effectif + titre du poste + email gratuit) tagué avec scoringMethod: "rule-based" dans HubSpot. Auditez le taux hebdomadairement — si l’utilisation basée sur des règles dépasse 5 % des exécutions, le modèle ou le prompt a besoin d’être corrigé, pas le seuil.
  • Jeu de scores et dérive du rubric. Les commerciaux apprendront rapidement ce qui déclenche un score élevé et se plaindront quand leurs leads favoris scorent bas. Protection : un audit hebdomadaire de 10 leads par le responsable SDR, comparant le score et le raisonnement de Claude avec le score aveugle du responsable. Si le désaccord dépasse 30 %, réécrivez le rubric — ne modifiez pas le seuil.
  • Fuite d’email gratuit. Des acheteurs seniors indépendants soumettent bien depuis des adresses gmail.com, et un plafond dur à 4 les manque. Protection : le plafond est imposé dans le prompt plutôt que dans le code, et le prompt permet à Claude de remplacer le plafond si les réponses du formulaire prouvent un vrai rôle. Revérifiez ce taux de remplacement trimestriellement — s’il est proche de zéro, votre formulaire ne pose pas la bonne question.
  • Dérive de la feuille de territoire. Un nouveau pays dans le trafic inbound sans ligne dans la feuille provoque le retour vide de la recherche et le déclenchement de la branche unrouted du nœud Switch. Protection : la branche unrouted poste vers #inbound-ops-alerts avec le score et la méthode pour que les ops voient l’écart immédiatement, au lieu que les leads échouent silencieusement à être routés.

Stack

  • n8n — ingress webhook, orchestration d’enrichissement, routage et le cron de filet de sécurité nocturne
  • HubSpot — source de l’inbound, destination pour le contact enrichi et scoré, et la cible de recherche pour le sweep du filet de sécurité
  • Claude (Haiku 4.5) — scoring ICP avec raisonnement, output JSON structuré, règles côté prompt déterministes pour les données manquantes et les plafonds email gratuit
  • Apollo — enrichissement firmographique par domaine (secteur, effectif, technologies)
  • Google Sheets — règles de routage de territoire, modifiables par le responsable SDR sans toucher à n8n
  • Slack — pagination haute-intention dans #inbound-hot et alertes ops dans #inbound-ops-alerts

Files in this artifact

Download all (.zip)