ooligo
n8n-flow

n8nとClaudeによるインバウンドリードのトリアージとルーティング

Difficulty
中級
Setup time
90min
For
revops · sdr-leader
RevOps

Stack

インバウンドのデモリクエストが届いた瞬間に捕捉し、ClaudeでICPルーブリックに照らしてスコアリングし、ファーモグラフィックデータでエンリッチし、セルフサーブフロー・テリトリー別SDRキュー・オンコールAEへのSlack通知のいずれかにルーティングするn8nフローです。apps/web/public/artifacts/inbound-lead-triage-n8n/のバンドルには、完全なエクスポートと、インポート・クレデンシャル設定・ブランチごとの検証手順を説明した_README.mdが含まれています。

このフローを使う場面

週50件以上のインバウンドデモリクエストがあり、SDRが本来人間の目を通す必要のないリードに時間を費やしている、あるいは本当に高いインテントを持つリードが先入れ先出しキューで古いリードの後ろで待たされている場合に使います。このフローの導入を正当化する症状は、対応時間のばらつきです。最良のリードが最悪のリードの後ろで何時間も待っている状態がその典型です。

ICPルーブリックが十分に具体的で、2人のSDRが同じリードを異なるスコアで評価してしまう場合にも、このパターンが適切です。ルーブリックを単一のMarkdownドキュメントに集約してClaudeが毎回読み込む構成にすることで、すべての送信に対して一貫したスコアリングが実現し、単一のアーティファクトとして監査可能になります。

このフローを使わない場面

週のインバウンドデモリクエストが10件未満の場合は導入を見送ってください。その程度の量であれば、SDRによる手動ルーティングの方が速く、フローのメンテナンスに費やす時間の方がコスト削減効果を上回ります。クレデンシャルのローテーション、ルーブリックのドリフト監査、そして深夜3時にClaudeタイムアウトの通知が届くリスクは、リード1件あたりの改善効果を超えてしまいます。

ICPが実質的に未定義の場合も見送ってください。このフローはルーブリックの乗数です。「良いリード」の定義がSDRマネージャーのその日の気分次第であれば、自動化はその日のバイアスを1万件のルーティングに固定するだけです。まずルーブリックを文書化し、その後に自動化を行ってください。

また、商談フローが完全にプロダクト主導で、「デモリクエスト」フォームが実質的にアカウント作成のプロンプトになっている場合もこのフローは不適切です。その場合の正しいパターンは、プロダクト内のアクティベーショントリガーであり、フォームをエントリポイントと見なすトリアージ層ではありません。

セットアップ

  1. バンドルをインポートする。 apps/web/public/artifacts/inbound-lead-triage-n8n/inbound-lead-triage-n8n.jsonをn8nのWorkflows → Import from Fileからインポートします。フローには2つのエントリポイントがあります。リアルタイムパス用のwebhookと、バックストップスイープ用の日次cronです。
  2. HubSpotを接続する。 _README.mdに記載されている4つのカスタムコンタクトプロパティ(icp_score__cicp_score_reasoning__cicp_pain_hypothesis__cicp_scoring_method__c)を作成します。コンタクトがデモリクエストフォームを送信した際にcontactIdとフォームコンテキストを/webhook/inbound-lead-triageにPOSTするHubSpotワークフローを設定します。
  3. Claudeを設定する。 n8nワークフロー変数ICP_RUBRICにルーブリックのMarkdownを設定します(毎回の呼び出しで送信されるため、約2kトークン以内に収めてください)。デフォルトモデルはclaude-haiku-4-5で、プロンプトはJSONのみの出力と、データ欠損・フリーメールアドレスに対する明示的なフォールバックルールを強制します。
  4. テリトリールールを設定する。 PLACEHOLDER_TERRITORY_SHEET_IDで参照されるGoogle Sheetsに、国ごとに1行、デフォルト行として*を追加します。必須列はcountrysdr_emailsdr_owner_idsdr_slack_handleae_emailae_owner_idae_slack_handleです。
  5. 各ブランチを検証する。 _README.mdの5ステップ検証(低スコア、中スコア、高スコア、Claude失敗、バックストップ)を実施します。5つすべてが通過した後にのみHubSpotトリガーを有効化してください。

フローの動作

webhookはHubSpotのフォーム送信ペイロードを受け取り、エンリッチメントやスコアリングによってフォーム送信がブロックされないよう、即座に202を返します。Normalize Payload(Codeノード)はHubSpotのエンベロープを単一のJSON形状にフラット化し、メールをローワーケースに変換し、ドメインを抽出し、ハードコードされたセットからフリーメールプロバイダーにフラグを立てます。これにより後続ノードでシグナルを再導出する必要がなくなります。

Apollo — Enrich Domainは8sのタイムアウトとneverError: trueでApolloの組織エンリッチエンドポイントを呼び出します。失敗してもフローは止まりません。enrichmentOk: falseのペイロードが生成されるだけで、スコアリングステップはこれを1ポイントのペナルティとして扱うよう指示されています。Merge Lead + Firmographicsは正規化されたリードとエンリッチメントを結合し、Claudeが参照するバンドルを作成します。

Claude — Score Leadclaude-haiku-4-5、6sのタイムアウト、scorereasoningprimary_pain_hypothesisdisqualifiersを持つ単一のJSONオブジェクトを強制するシステムプロンプトでhttps://api.anthropic.com/v1/messagesにPOSTします。プロンプトは、ファーモグラフィックスが欠損している場合にスコアを1下げること、フォームの回答が実際のロールを証明しない限りフリーメールアドレスは4でキャップすることをClaudeに明示的に指示しています。どちらのルールもコードではなくプロンプトに記述することで、一元的に監査可能になります。

Parse Score (with fallback)が最も重要なノードです。ClaudeのJSONのパースを試み、パース失敗またはスコア欠損の場合、ヘッドカウント・職名・フリーメールステータスから決定論的スコアを算出します。出力には常にscoringMethod: "claude"または"rule-based"が含まれるため、週次監査でフォールバック使用率の増加を検出できます。

HubSpot — Upsert Scoreはスコア、推論、ペイン仮説、メソッドをコンタクトに書き戻すため、SDRはリードがキューに入った理由を確認できます。Route by Scoreは3つの明示的なブランチとunroutedフォールバックを持つSwitchノードです。スコア4未満はセルフサーブナーチャー、4〜7はSheets — Territory Lookupを経てSDRキュー、8以上は#inbound-hotでAEにページ送信、それ以外は#inbound-ops-alertsでopsに通知します。

2つ目のエントリポイント、Nightly Backstop Cron(02:15実行)はHubSpotでsubscriber段階にあり、直近26時間以内のrecent_conversion_dateを持ち、icp_score__cが設定されていないコンタクトを検索し、レート制限を消費しないようバッチコール(batchSize: 5batchInterval: 2000ms)でwebhookを経由して各コンタクトを再処理します。

コスト

claude-haiku-4-5使用時、典型的なスコアリング呼び出しはリードあたり約1.2k入力トークン(ルーブリック+リードバンドル)と200出力トークンです。Haiku 4.5の料金でおよそ1リードあたり$0.0015です。ApolloのBasicティアでの組織エンリッチは、プランによってクレジットあたり$0.01〜$0.05で、計画値として1リードあたり$0.02を見込んでください。n8nのセルフホストは無料、n8n Cloud Starterは月$20で1万実行を容易に処理できます。

月1,000件のインバウンドデモリクエストを持つチームの場合、Claude+Apollo合わせた限界費用は月$25未満です。限界費用ではないのは、週にSDRリーダーがスコアリング済みリードのサンプルを監査し、ルーブリックを調整する1時間です。これこそが、コストをかけるのではなく、フローを機能させるものです。

成功指標

注目すべき指標はスコア8以上のリードに対する初回接触までの中央値時間です。このフロー導入前は、この数値はSDRキューの深さと時刻に左右されます。導入後は、フォーム送信の瞬間にAEが完全なコンテキストとともにSlackでページされるため、営業時間中は5分未満に短縮されるはずです。

副次指標は人間に到達するインバウンドの割合です。フローが正直に機能していれば、この数値は30〜50%低下します(低スコアリードがSDRキューの代わりにナーチャーに流れるため)。そして人間に届くリードのSDR転換率は相応に上昇するはずです。1つ目の変化が見られて2つ目が見られない場合、ルーブリックのフィルタリングが誤っています。

代替手段との比較

vs cronで動くDIY Pythonスクリプト。 5分ごとにHubSpotをポーリングするcron駆動スクリプトは、最悪ケースで5分、平均で2.5分のレイテンシを追加します。これは高インテントリードへのページングという目的を無効にします。webhookで駆動するn8nフローはハッピーパスでサブ秒です。さらにn8nの実行ログが無料の可観測性レイヤーとなり、スクリプトのstdoutをデバッグする必要がありません。

vs HubSpot Workflows + Operations Hub。 HubSpotは静的ルール(国、ディールサイズ、フォームフィールド)によるルーティングが可能ですが、Custom Code Actionなしにルーブリックを使ってClaudeを呼び出し構造化JSONをパースすることはできません。HubSpotでカスタムコードを書き始めた時点で、n8nで得られる可視性とクレデンシャル管理は失われます。Operations Hub Professionalはロジックを1行も書く前に月$800です。

vs 既製のリードルーター(Chili Piper、Distribute、RevenueHero)。 これらはルーティングとミーティング予約のステップに優れており、最初の接触で予約するモーションであれば購入する価値があります。ただし「ルーブリックでリードをスコアリングしてから何をするか決める」という処理には対応していません。これがこのフローの担う役割であり、両者はきれいに連携できます。ここでルーティングし、スコア上位のリードをChili Piperに渡して予約体験を提供してください。

注意点

  • Webhookの信頼性。 HubSpotの送信webhookはリトライ枯渇時にサイレントに失敗します。対策:Nightly Backstop Cronが直近26時間以内の転換日を持ちicp_score__cが設定されていないsubscriber段階のコンタクトをスイープし、同じwebhookで再処理します。バックストップのキャッチ率が1日の量の約2%を超えたら、HubSpotサポートにエスカレーションしてください。チューニングの問題ではなく、実際の信頼性問題です。
  • Claudeのレイテンシまたは不正なJSON。 インバウンドは素早いルーティングが必要ですが、Claudeはときに5秒以上かかったり、JSONの周囲に散文を返したりすることがあります。対策:Claude — Score Leadノードには6sのタイムアウトとneverError: trueが設定されており、Parse Score (with fallback)はHubSpotでscoringMethod: "rule-based"としてタグ付けされた決定論的なルールベーススコア(ヘッドカウント+職名+フリーメール)にフォールバックします。週次で使用率を監査し、ルールベース使用率が実行の5%を超えたら、閾値ではなくモデルまたはプロンプトを修正してください。
  • スコアのゲーミングとルーブリックのドリフト。 担当者はすぐに高スコアのトリガーを学習し、お気に入りのリードのスコアが低いと文句を言います。対策:SDRリーダーによる週次10リードの監査。Claudeのスコアとレコメンデーションをリーダーのブラインドスコアと比較します。不一致が30%を超えたら、閾値を調整するのではなくルーブリックを書き直してください。
  • フリーメールの漏れ。 自営業の上位バイヤーがgmail.comアドレスで送信することがあり、4でのハードキャップでは見逃してしまいます。対策:キャップはコードではなくプロンプトで強制されており、フォームの回答が実際のロールを証明する場合はClaudeがキャップをオーバーライドできます。そのオーバーライド率を四半期ごとに確認し、ほぼゼロであればフォームで適切な質問ができていません。
  • テリトリーシートのドリフト。 シートに行がない国からインバウンドが来ると、ルックアップが空を返し、Switchノードのunroutedブランチが発火します。対策:unroutedブランチはスコアとメソッドとともに#inbound-ops-alertsにポストするため、リードがサイレントにルーティング失敗する代わりにopsが即座にギャップを把握できます。

スタック

  • n8n — webhookイングレス、エンリッチメントオーケストレーション、ルーティング、および夜間バックストップcron
  • HubSpot — インバウンドのソース、エンリッチおよびスコアリング済みコンタクトの保存先、バックストップスイープのルックアップ対象
  • Claude(Haiku 4.5) — 推論付きICPスコアリング、構造化JSON出力、データ欠損とフリーメールキャップに対するプロンプト側の決定論的ルール
  • Apollo — ドメインによるファーモグラフィックエンリッチメント(業種、ヘッドカウント、テクノロジー)
  • Google Sheets — n8nに触れることなくSDRリーダーが編集可能なテリトリールーティングルール
  • Slack#inbound-hotでの高インテントページングと#inbound-ops-alertsでのopsアラート

Files in this artifact

Download all (.zip)