sales-lead-routing について
営業チーム向けに、リード振り分けの設計と実装を支援するツール非依存のスキルです。モデル選定、割り当てやフォールバック規則、営業プラットフォームへの実装、効果測定を扱います。
主な機能
- 01振り分けモデルの選定
- 02優先順位付き割り当て規則
- 03応答時間と超過時の振り分け計画
- 04営業プラットフォームの実装ガイド
- 05指標とレビュー周期
活用シーン
- 01営業チーム向けモデルの選定
- 02リード割り当てとフォールバック規則の策定
- 03Salesforce または HubSpot への実装
- 04応答速度とコンバージョン指標の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ sales-skills/ sales --skill sales-lead-routingインストール後、Claude Code で/sales-lead-routingを入力して読み込まれたか確認します。
同梱ファイルreferences/learnings.md
詳細
リードのルーティングルールを設計する
ルーティングモデルの選択や割り当てルールの定義から、プラットフォームへの実装、リード対応速度の最適化、キャパシティ管理まで、リードのルーティング設計と実装を支援します。このスキルは特定のツールに依存せず、Salesforce、HubSpot、Salesloft、Apollo、単体のルーティングツールに対応しています。
ステップ 1 — コンテキストを確認する
references/learnings.md が存在する場合は、蓄積された知見を確認するため、最初に読みます。
ユーザーに次の質問をします。
-
チームの構成を教えてください。
- 担当者は何人ですか(SDR、AE、またはその両方)?
- 担当者は専門分野別(セグメント、テリトリー、業種別)ですか、それともジェネラリストですか?
- シニア担当者とジュニア担当者のような、階層的な経験区分はありますか?
-
リードはどこから来ますか?
- A)インバウンド(ウェブサイトのフォーム、コンテンツ、イベント)
- B)アウトバウンド(SDR が獲得、コールドアウトバウンド)
- C)プロダクト主導(サインアップ、トライアル、PQL)
- D)パートナー/チャネル
- E)複数の組み合わせ — 詳細を教えてください
-
現在、リードをどのようにルーティングしていますか?
- A)手動割り当て(マネージャーが割り当て)
- B)ラウンドロビン
- C)テリトリー別
- D)CRM の自動化ルール
- E)システムなし — 先着順
- F)これから導入する
-
どのツールを使用していますか?
- CRM:Salesforce、HubSpot、Pipedrive、その他
- セールスエンゲージメント:Salesloft、Apollo、Mailshake、その他
- ルーティングツール:LeanData、Chili Piper、Distributely、なし
-
リードの量はどのくらいですか?(週次または月次のインバウンドリード数のおおよその見積もり)
ユーザーのリクエストにこれらの情報の大半がすでに含まれている場合は、該当するステップに直接進みます。 合理的な前提を明示したうえで、最善の回答をまず提示し、最後に最も重要な確認質問を 1~2 個だけ尋ねます。必要な情報をすべて集めるまで回答を保留しないでください。
ステップ 2 — ルーティングモデルのフレームワーク
チームの構成とリードの特性に基づいて、適切なルーティングモデルを選びます。
判断マトリクス
| モデル | 最適な対象 | チーム規模 | 複雑さ | リード対応速度 |
|---|---|---|---|---|
| ラウンドロビン | 均等な分配、ジェネラリストチーム | 問わない | 低 | 速い |
| テリトリー別 | 地域別または担当アカウント別の専門化 | 担当者 4 人以上 | 中 | 速い |
| スコア別 | リードの質と担当者のスキルのマッチング | 担当者 6 人以上 | 高 | 中 |
| アカウント別 | 担当者が割り当てられた特定アカウント | ABM を実施しているチームなら規模を問わない | 中 | 速い(担当者がいる場合) |
| ハイブリッド | 複数のセグメントがある複雑な組織 | 担当者 10 人以上 | 高 | 変動 |
ラウンドロビン
- 仕組み:各担当者に順番に、均等にリードを割り当てます
- バリエーション:シンプル(A→B→C→A)、重み付け(A に 40%、B に 30%、C に 30%)、稼働状況を考慮(不在中の担当者をスキップ)
- 最適な対象:小規模なチーム、リードの質が均等、専門化が不要
- 制約:担当者のスキル、リードの質、テリトリーは考慮しません
テリトリー別
- 仕組み:地理的な地域、業種、または企業規模のセグメントに基づいてリードを割り当てます
- テリトリーの種類:地理(北米西部、北米東部、EMEA、APAC)、業種(ヘルスケア、FinTech、SaaS)、セグメント(SMB、ミッドマーケット、エンタープライズ)
- 最適な対象:地域や業種に関する専門知識を持ち、専門化が可能な規模のチーム
- 制約:テリトリーごとにリード数が異なると、分配が不均等になります
スコア別
- 仕組み:スコアの高いリードはシニアまたは経験豊富な担当者に、低いリードは適格性を確認するため SDR に割り当てます
- ティア:ホット(スコア 80 以上 → シニア AE)、ウォーム(50~79 → 標準 AE)、コールド(30~49 → SDR)、30 未満 → ナーチャリング/破棄
- フォールバックルール:スコアがないリード(データ不足によりスコアなし)は、手動で適格性を確認できるよう SDR に割り当てます。あるティアの担当者プールがキャパシティ上限に達した場合、次の下位ティアにあふれた分を割り当てます(例:シニア AE 全員が上限に達している場合、ホットリードを標準 AE プールに割り当てます)。担当者ごとにキャパシティ上限(例:週 30 件まで)を設定し、上限に達したら自動で再分配します。
- 最適な対象:リードスコアリングを導入済みのチーム(
/sales-lead-scoreを参照)、担当者の経験に階層があるチーム - 制約:機能するスコアリングモデルが必要です。スコアが不適切だと、ルーティングも不適切になります
アカウントベース
- 仕組み:リードを既存アカウントのオーナーに紐づけます。新規アカウントは別のモデルでルーティングします。
- ロジック:リードの企業が既存アカウントと一致するか確認し、一致する場合はアカウントオーナーに割り当てます。一致しない場合は、ラウンドロビンまたはテリトリーにフォールバックします。
- 最適な用途:ABM チーム、指定アカウント戦略、営業担当者間の競合防止
- 制限事項:アカウントデータのクレンジングと重複排除が必要です
ステップ 3 — ルーティングルールの設計
優先順位のウォーターフォール
ルーティングルールは優先順位のウォーターフォールとして構築します。最初に一致したルールが適用されます。
| 優先度 | ルール | 例 |
|---|---|---|
| 1 | 既存アカウントとの一致 | リードの企業が担当中のアカウントと一致 → アカウントオーナーにルーティング |
| 2 | 指定アカウントリスト | 企業がターゲットアカウントリストに含まれる → 割り当て済み AE にルーティング |
| 3 | スコアのしきい値 | スコア ≥ 80 → シニア AE プールにルーティング |
| 4 | テリトリーとの一致 | 地域/セグメントがテリトリーと一致 → テリトリーオーナーにルーティング |
| 5 | ラウンドロビンのフォールバック | 他のルールに一致しない → 対応可能な営業担当者間でラウンドロビン |
リード対応速度の SLA
リード対応速度は、ルーティングにおいて最も重要な指標です。応答時間はコンバージョンに直接影響します。
| 応答時間 | コンバージョンへの影響 |
|---|---|
| < 5 分 | 30 分の場合と比べ、適格と判断される可能性が 8 倍 |
| 5~30 分 | 基準値 |
| 30~60 分 | 適格率が 50%低下 |
| > 1 時間 | 80%以上低下 |
| > 24 時間 | ほぼ見込みなし — 再ナーチャリングする方が効果的 |
リードタイプ別の SLA 推奨事項:
- インバウンドのデモリクエスト:< 5 分
- インバウンドのコンテンツダウンロード:< 1 時間
- PQL(プロダクト主導):< 15 分
- アウトバウンドへの応答/返信:< 1 時間
- パートナーからの紹介:< 30 分
オーバーフローとフォールバックのルール
割り当てられた営業担当者が時間内に応答できない場合の対応です。
| シナリオ | フォールバック |
|---|---|
| 営業担当者が SLA 内に応答しない | マネージャーにエスカレーションし、次に対応可能な担当者へ再割り当て |
| 営業担当者が不在 | ローテーションをスキップし、バックアップに割り当て |
| テリトリーオーナーの対応可能件数が上限 | 隣接するテリトリーまたは SDR プールにオーバーフロー |
| アカウントオーナーがいない | ラウンドロビンにフォールスルー |
競合の解決
- 複数の営業担当者が同じリードを担当しようとする:アカウントオーナーを優先します。アカウントオーナーがいない場合は、ファーストタッチのアトリビューションを適用します。
- リードが複数のテリトリーに一致する:プライマリテリトリーを優先します(テリトリールールでプライマリを定義してください)。
- 既存顧客の新しいコンタクト:ラウンドロビンではなく、アカウントオーナーにルーティングします。
- 再利用/再エンゲージしたリード:元の担当者が引き続きチームに所属している場合はその担当者に戻し、そうでない場合はラウンドロビンにします。
ステップ 4 — プラットフォームへの実装
Salesforce
- 割り当てルール:Setup > Lead Assignment Rules — 条件を定義し、ユーザーまたはキューに割り当てます
- キュー:プール用のリードキュー(SDR プール、AE プール、テリトリーキュー)を作成します
- Flow Builder:スコアベースのルーティング、アカウント照合、SLA エスカレーションなどの複雑なロジックに使用します
- 照合ルール:Setup > Duplicate Management > Matching Rules — リードを既存アカウントに照合します
- エスカレーションルール:Setup > Escalation Rules — SLA 内に連絡がなかった場合、自動的にエスカレーションします
- サードパーティ:高度なルーティングとビジュアルなルールビルダーには、LeanData または Distributely を使用します
HubSpot
- リードローテーション:Settings > Users & Teams > Lead Rotation — 組み込みのラウンドロビン機能です
- ワークフロー:Automation > Workflows — プロパティに基づいた if/then 形式のルーティングロジックを構築します
- コンタクトオーナーの割り当て:ワークフローのアクションを使用し、テリトリー、スコア、またはアカウントに基づいてオーナーを設定します
- SLA の監視:オーナーが X 時間以内にアクティビティを記録しない場合に再割り当てするワークフローを作成します
- サードパーティ:フォームからのリアルタイムのスケジュール設定とルーティングには、Chili Piper を使用します
Salesloft
- Rhythm ルーティング:Rhythm は営業担当者のアクションに優先順位を付けます — CRM 同期を通じてルーティングを設定します
- ケイデンスの割り当て:CRM の割り当てに基づいて、リードをケイデンスに自動インポートします
- ラウンドロビン:標準機能ではありません — CRM で処理し、割り当てを Salesloft に同期します
Apollo
- シーケンスへの割り当て:特定の担当者が所有するシーケンスにコンタクトを割り当てます
- CRM 同期:Apollo は CRM の所有権を尊重します。CRM でルーティングし、Apollo に同期します
- リスト:担当者やテリトリーごとに条件で絞り込んだリストを作成し、それに応じてシーケンスを割り当てます
ステップ 5 — 測定
主な指標
| 指標 | 目標 | わかること |
|---|---|---|
| リード対応速度 | < 5 min(インバウンドのデモ)、< 1 hr(その他) | 担当者は十分な速さで対応していますか? |
| リード受け入れ率 | > 80% | 担当者は割り当てられたリードを受け入れていますか、それとも拒否していますか?受け入れ率が低い場合、ターゲティングやルーティングに問題があります |
| ルート別コンバージョン | モデル間で比較 | どのルーティング経路が最も高いコンバージョン率を生み出していますか?特定のテリトリーや階層の実績が低いかどうかを特定できます |
| キャパシティ使用率 | 担当者あたり 70-90% | 担当者に過剰な負荷がかかっていますか、それとも十分に活用されていませんか?重み付けやテリトリーを調整します |
| 選り好み率 | < 10% | 担当者はスコアの低いリードを無視していますか?SLA の徹底やスコアリングの調整が必要な場合があります |
最適化の頻度
- 毎週:リード対応速度と受け入れ率を確認します
- 毎月:ルート別コンバージョンを確認し、重み付けやテリトリーを調整します
- 四半期ごと:ルーティングモデル全体を見直します。モデルはチーム構成やリードソースにまだ合っていますか?
注意点
-
エンリッチメントなしでルーティングしないでください。 リードがメールアドレスのみで届く場合(フォーム経由など)は、ルーティング前に企業データを付加します。企業名や役職のデータがなければ、テリトリーやスコアに基づくルーティングは機能しません。ルーティング前に
/sales-enrichを使って不足情報を補完します。 -
リード対応速度を軽視しないでください。 完璧なルーティングモデルでも、対応が遅ければ、単純なラウンドロビンで素早く対応するより劣ります。最適化できる項目が 1 つだけなら、リード対応速度を最適化します。データは明らかです。5 分と 30 分では、適格性確認率に 8 倍の差があります。
-
シンプルな方法が機能する前に複雑にしないでください。 まずはラウンドロビンから始めます。テリトリーやスコアに基づくルーティングを追加するのは、コンバージョンが改善するというデータが得られてからにします。複雑にすると、保守の負担と障害の発生要因が増えます。
-
自己改善:ここに記載されていないことを見つけた場合は、今日の日付を付けて
references/learnings.mdに追記します。
関連スキル
/sales-qualified— Qualified プラットフォームのヘルプ(Salesforce ネイティブのリアルタイムなウェブサイトチャット経由のリードルーティング)/sales-lead-score— スコアに基づくルーティングに利用するスコアリングモデルを設計します/sales-enrich— ルーティングルールに必要な企業名や役職のデータでリードをエンリッチします/sales-prospect-list— テリトリーを事前にセグメント化した見込み顧客リストを作成します/revops— マーケティングから営業への引き継ぎプロセス全体を設計します/sales-cadence— 異なるルートセグメント向けのケイデンスを設計します/sales-do— どのスキルを使えばよいかわからない場合は、ルーターが営業に関するあらゆる目標に適したスキルを選びます。
例
例 1:成長中のチーム向けラウンドロビン
ユーザーの発言:「SDR が 8 人いて、インバウンドリードが週に約 200 件あります。どのようにルーティングすればよいですか?」 スキルの処理:
- 基本方式として重み付きラウンドロビンを推奨します(最初は均等に分配)
- SLA ルールを設計します。デモのリクエストは < 5 min、コンテンツのリードは < 1 hour
- 担当者のキャパシティが上限に達している場合や不在の場合のあふれ分ルールを追加します
- HubSpot/Salesforce での実装手順を提示します 結果:SLA とあふれ分への対応を備えたラウンドロビンルーティング
例 2:テリトリールーティング
ユーザーの発言:「4 人の AE 向けに、NA West、NA East、EMEA、APAC のテリトリールーティングが必要です。」 スキルの処理:
- 地理情報に基づくテリトリールールを定義します(国や州を各テリトリーに対応付け)
- 地理情報より優先される指定アカウントに対応します
- 地理情報が不明なリード向けのフォールバックを追加します
- CRM での実装手順を提示します 結果:指定アカウントによる上書きと地理情報によるフォールバックを備えたテリトリールーティング
例3:スコアベースの段階的ルーティング
ユーザーの発言:「スコアの高いリードはシニア担当者に、低いリードは SDR に割り当てたいです。HubSpot を使っています。」 スキルの処理:
- 段階的なルーティング(ホット/ウォーム/コールド)のスコアしきい値を定義します
- 各段階を担当者プール(シニア AE、標準 AE、SDR)に割り当てます
- スコア未設定のリード用にフォールバックを追加します
- HubSpot ワークフローの実装手順を提示します 結果:スコアしきい値、担当者プールへの割り当て、フォールバックルールを備えた段階的なルーティング
トラブルシューティング
対応されないままのリード
症状:リードが割り当てられているものの、SLA 以内に連絡されません 原因:担当者の過負荷、SLA の適用不足、または営業時間外のリード割り当て 解決策:エスカレーションルールを追加します。SLA 以内にアクティビティがなければ、次に対応可能な担当者へ再割り当てします。担当者ごとにキャパシティ上限を設定します。営業時間/タイムゾーンに基づいてルーティングします。
偏った割り当て
症状:担当者によって、他の担当者の3倍のリードを抱えています 原因:テリトリーの不均衡、加重ラウンドロビンの設定ミス、またはアカウント照合によって特定の担当者にリードが集中しています 解決策:毎月、テリトリーごとの件数を確認します。重みを調整して偏りをなくします。特定の担当者が1日に X 件を超えるリードを受け取らないよう、キャパシティ上限を追加します。
リードの所有権をめぐる担当者間の競合
症状:複数の担当者が同じリードまたはアカウントの所有権を主張しています 原因:ルーティングにアカウント照合の手順がない、または CRM に重複アカウントがあります 解決策:ルーティングのウォーターフォールで、最初の手順としてアカウント照合を追加します。CRM 内のアカウントを重複排除します。既存アカウントでは常にアカウント所有者を優先するなど、明確なルールを定めます。