量に耐えるリードルーティングとSLAの順守
金曜の午後11時、従業員600人のフィンテック企業からの4万ドルのデモ申し込みが、4時間手つかずのまま放置されていました。それが割り当てられた担当者は、6週間前に退職していました。誰も気づきませんでした。ルーティングルールがまだ彼のキューを指していて、ITが退職手続きをしたときに彼の不在を知らせるSlackの自動返信が無効化され、ラウンドロビンのカウンターは彼の名前を素通りして元気に刻み続けていたからです。VP of Marketingが知るのは月曜の朝、見込み客のCROがなぜ折り返しの電話がなかったのかを直接CEOにメールしたときです。MOps現場担当者であるあなたは、午前9時2分にSlackを受け取ります。「どうしてこんなことが起きるんだ?」
それが実際の仕事です。ルーティングは「うちはラウンドロビンを使っている」ではありません。「毎月どの12%のリードがSLAに違反するかを知っていて、なぜかを知っていて、それを直すためにどのルールをリリースすべきかを知っている」ことです。まだその可視性のレベルにないなら、このプレイブックの残りは、そこにたどり着くための作業です。
実際に持ちこたえるルーティングのタクソノミー
単一軸のルーティングは、月300〜500件のリードのどこかで破綻します。ラウンドロビンだけでは、デモ申し込みがあなたのICPからのもので、コンテンツのダウンロードがバンガロールの学生だということが分かりません。テリトリーだけでは、EMEAのAEがPTO中で、ドイツの見込み客がキューに座っていることが分かりません。3つのレイヤーを積み重ねる必要があります。
レイヤー1:ファーモグラフィック。 セグメント(SMB / ミッドマーケット / エンタープライズ)、地理(テリトリールール向けの地域、コンプライアンス向けの国)、従業員数、業界。これは最も安いデータで、その大半はClearbit、ZoomInfo、またはまともなエンリッチメントベンダーからフォーム入力で無料で得られます。ファーモグラフィックのエンリッチメントが動いていないなら、読むのをやめて、まずそれを直しに行ってください。それなしのルーティングは当て推量です。
レイヤー2:インテント。 彼らは実際に何をしたか。pricing.yourdomain.com からのデモ申し込みは、eブックのダウンロードと同じリードではありません。価格ページの訪問、デモ申し込み、「営業に相談する」フォーム入力、エンゲージメントの高いプロダクトトライアルの登録は、ティア1のインテントです。ウェビナー参加とコンテンツのダウンロードはティア2です。ニュースレターの登録とゲート付きPDFはティア3のマーケティングナーチャリングです。ティア1は数分以内に人間の受信箱に届くべきです。ティア3が担当者を起こすことは決してあってはなりません。
レイヤー3:ICP適合スコア。 ファーモグラフィックと行動シグナルを使った複合スコアで、通常はスコアリングモデルからの0〜100のスコアです。スコアの目的は門番をすることではありません。同点を解消することです。2件のデモ申し込みが同じ分にキューに届いたとき、適合度の高いアカウントはシニアAEに、低い方はSDRプールに行きます。
この3つを積み重ねると、ルールはこう読めます。*「intent = デモ申し込み AND 適合スコア >= 60 AND セグメント = ミッドマーケット AND geo = NA なら、NA-MidMktのAEのラウンドロビンプールにルーティングする。」*それが1日1,500件のリードでも持ちこたえるルールです。純粋なラウンドロビンでは持ちません。
リードスコアリングは、これを機能させる上流の入力です。営業が信頼するリードスコアリングモデルで、営業が本当に納得するスコアの構築方法をご覧ください。
5分SLAの現実
誰もが引用するHarvard Business Review / InsideSalesの調査は本物で、ほとんどのMOpsマネージャーが認めたくないほど古いものです。数字はあまり動いていません。リードに1分以内に連絡すれば、5分のときに比べて約8倍、それをクオリファイできる可能性が高くなります。1時間待てば、得られたはずのコンバージョンの約60%を失います。5分を過ぎた1分ごとに、さらに10%のコンバージョンが上から削られていきます。
ですから、ティア1のインテントに対する実用的なSLAは5分です、それで終わりです。それは「担当者がリードを開いてアウトリーチを始めた」であって、「担当者がキューにリードを持っている」ではありません。キューの時間は見込み客には見えません。
5分が実際に何を意味するかは、ややこしくなります:
- 担当者がPT帯にいて、ドイツのリードが彼らの時間で午前3時に届くなら、SLAはフォーム入力から5分にはできません。担当者の勤務日の始まりから5分か、あるいはフォロー・ザ・サンのプールが必要です。
- リードがChili Piperや類似のインバウンドスケジューラー経由でミーティングを申し込み、自分でカレンダーに予約するなら、SLAは応答速度ではなく「カレンダーを承認し、準備メモを追加し、時間通りにコールに参加した」になります。
- 2人の担当者が同じリードプールを取り合っているなら、SLAダッシュボードは誰かによる最初の接触ではなく最初の応答を測定しなければなりません。さもなければ、担当者Aが担当者Bのリードを横取りしてSLAを満たし続けます。
現実的な運用目標:営業時間中、ティア1リードの80%を5分以内に、95%を30分以内に、時間外を含めて100%を4時間以内に連絡する。それを達成できないなら、答えはより厳しいルールではなく、より多くの担当者カバレッジか24/5のSDRプールです。
ルーティングの取り締まり役にならずにSLAを順守させる
この仕事には、遅れたフォローアップについて担当者にSlackを送る人になるバージョンがあります。それはやめてください。担当者があなたを嫌い始め、あなたは燃え尽き、根本的な問題は直りません。
代わりにうまくいくのは、段階的な自動化レイヤーと、目に見えるダッシュボードです:
自動化のフラグ。
- 担当者の応答がないまま4分時点で:「リード[名前]が4分経過、ステージ = デモ申し込み」と担当者にSlackのDM。
- 担当者の応答がないまま10分時点で:担当者のマネージャーにSlackの通知、そしてリードがプール内の次の担当者に自動再割り当て。
- 30分時点で:すべての違反とその理由を一覧にした日次ダイジェストメールが担当者の受信箱に届く。
マネージャーのダッシュボード。 Salesforce、HubSpot、またはチームが使うBIツールで構築します。必須の3つの切り口:
- 担当者別の違反率(直近30日のローリング)
- セグメントとソース別の違反率(どのソース/セグメントの組み合わせが最も違反しているか)
- 時間帯別の違反率(誰も朝のEMEA枠をカバーしていないため、違反が午前8〜9時に集中していないか)
ダッシュボードが社会的な作業をこなします。30日間で違反率22%の担当者は、月曜の朝のチームレポートにそれが載っているのを見て、自己修正します。マネージャーが1on1で外れ値に対処します、あなたではありません。あなたは構造的な違反を直すルール変更をリリースします。
この違いは重要です。アラートは情報(「あと4分残っています」)であり、罰は判断(「今週SLAを3回逃しました」)です。前者は担当者を味方につけます。後者は彼らに通知をオフにさせます。
誰も所有したがらない重複排除の問題
地味な真実がここにあります。「担当者がフォローアップしなかった」という苦情の約3分の1は、ルーティングの失敗ではありません。重複排除の失敗です。
典型的なパターン:
リードとアカウントの不一致。 acme.com からの新しいリードがデモフォームを入力します。ルーティングルールは「アカウントが存在するなら、アカウント所有者にルーティングする」と言います。Salesforceがメールドメインで重複排除してAcme Corpを見つけますが、一致したアカウントは2023年にClosed-Lostになっていて、所有者は別のセグメントのAEに昇進したSDRです。リードは誰も見ていないキューにルーティングされます。
企業名のあいまい重複排除。 「Google Inc.」対「Google」対「google.com」対「Alphabet」。正規化されたアカウントマッチングのレイヤーがないと、ルーティングは4つの異なるアカウントに4つのリードを作り、4人の担当者がそれぞれ他の誰かが対応していると思い込みます。
「Googleの John Smith」問題。 同じ名前の2人が、3日空けてフォームを入力します。重複排除ルールが名前 + 企業で彼らをマージし、最初のリードのソースアトリビューションを上書きし、マージされたリードを今それを所有している人にルーティングします。最初のリードの所有者は、新しい接触の通知を受け取りません。
その対策は、本物のリードとアカウントのマッチングレイヤー(LeanDataの十八番の機能、またはHubSpotの改善された企業マッチング、あるいはエンジニアリング予算があればカスタムソリューション)です。そして、ルーティングレイヤーで「一致あり、アカウントがアクティブ、所有者あり」を上記3つの失敗モードと区別するルールです。アカウントマッチングのログは、SLAレビューと合わせて毎月見直します。さもなければ、重複排除の失敗が永遠にルーティングの失敗を装い続けます。
LeanData対CRM内蔵のネイティブルール
この比較の正直なバージョン:CRM内蔵はベンダーが言うよりも長く十分に通用し、LeanData / Chili Piper / Defaultは、ルールの複雑さが些細でなくなったときに元を取ります。
| 観点 | CRM内蔵ルール(Salesforce / HubSpot) | LeanData / Chili Piper / Default |
|---|---|---|
| コスト | シートライセンスに含まれる | 年間3万〜8万ドル |
| 設定時間 | 機能するルールセットで1〜2週間 | 4〜8週間(マッピング、テスト、切り替え) |
| リード量のスイートスポット | 1日200件未満 | 1日200件以上 |
| きれいに扱えるセグメント数 | 1〜2セグメント | 5以上のセグメント、マルチプロダクト、マルチリージョン |
| アカウントベースのルーティング(ABM) | 苦痛、カスタムロジックが必要 | ネイティブ、これ向けに設計 |
| オブジェクト横断ロジック(リード → コンタクト → アカウント → 商談) | 機能するがエッジケースで壊れる | これ向けに構築 |
| 誰が所有するか | Salesforce管理者 / MOps | MOps現場担当者 + LeanData管理者 |
| 限界点 | 1日約500件のリードまたは3以上のセグメント | 1日約5,000件以上のリードまたは完全なABMマトリクス |
1日200件未満、1セグメント、ABM施策を実行していないなら、CRM内蔵ルールで持ちこたえます。年間5万ドルは、2人目のSDRやより良いエンリッチメントデータに使うほうが賢明です。
ABM、マルチプロダクトを運用していて、ルーティングにオブジェクト横断の依存関係がある場合(例:「リードのアカウントにオープンな商談があるなら、その商談所有者にルーティングする。さもなければリードのgeo + セグメント + 適合スコアに基づいてテリトリー担当者にルーティングする」)、CRM内蔵ルールは、1人の退職で考古学に変わるワークフロールールの巣になります。そこがLeanDataが元を取るところです。
罠は、実際には上流にある問題を直すためにLeanDataを買うことです。質の悪いエンリッチメント、スコアリングモデルの不在、データ入力レイヤーで壊れた重複排除。LeanDataはきれいなシステムをより良くします。汚れたシステムを救うことはありません。
「担当者がリードを無視した」の診断の連鎖
担当者がリードを無視したと責められたら、その評決を受け入れる前に、この6ステップの連鎖を実行してください。ほとんどの苦情はステップ6ではなく、ステップ2か3で破綻します。
- ルーティングされたか。 ルーティングログを確認します。ルールは発火したか。あなたが思っている担当者に一致したか。(時にルールは別の担当者に一致していて、誰が所有していたかについてマネージャーが間違っています。)
- 受信されたか。 それは実際に担当者のキュー / Salesforceビュー / HubSpot受信箱に届いたか。CRMビューのフィルターは、誰にも気づかれずに担当者からリードを隠すことがあります。
- 担当者は対応可能だったか。 PTO、病欠、退職、役割変更、90分間の顧客コール中。「担当者は席にいて画面を無視していた」という前提は、約40%の確率で間違っています。
- 彼らのキューで見えていたか。 デフォルトの並び順の新しいリードは、長いリストの7ページ目に着地することがあります。担当者が「スコアが最も高い順」でフィルターしていて、エンリッチメントがまだ走っていなかったためリードがスコアなしで入ってきたなら、それは見えません。
- 彼らはそれを開いたか。 SalesforceとHubSpotはどちらも初回開封のタイムスタンプを記録します。開かれていたなら、ステップ6にいます。そうでなければ、「無視」の上流にいます。
- 彼らはそれに対応したか。 メールは送ったか。電話は記録したか。カレンダーの招待は予約したか。これが「担当者がリードを無視した」です。ステップ1〜5はルーティング/データ/可視性の失敗です。
実例:あるCROが3件の「無視された」デモ申し込みをエスカレーションしました。私たちはこの連鎖を実行しました。3件すべてステップ2で破綻しました。担当者が2025年2月に設定した(まだSMBだけを扱っていた頃の)Salesforceのリストビューフィルターが、彼女が昇進したときに誰もフィルターを更新しなかったため、2026年にミッドマーケットのリードを隠していたのです。対策は、応答性についてのコーチングの会話ではなく、2分のフィルター編集でした。
同じ種類の上流の診断は、MQL→SQLコンバージョンの失敗にも重要です。MQLからSQLへのコンバージョン診断をご覧ください。
月次SLA違反レビュー
ルーティングが実際に直る会議は、月次のSLA違反レビューです。45分、4人:MOps現場担当者、SDRの責任者、AEの責任者、RevOpsリード。定例のアジェンダ:
- トップラインの数字(5分)。 総リード数、違反数、違反率。健全なB2B SaaSの実用上の上限は12%です。18%を超えるのは構造的です。カバレッジのギャップかルールの問題のどちらかです。
- 違反原因トップ5(15分)。 すべての違反を分類します:担当者がPTO、ルールが陳腐化、重複排除の失敗、時間外のカバレッジ、キューの可視性。今月のトップ原因が、あなたが修正をリリースするものです。
- 来月リリースするルール変更(15分)。 具体的な変更、例えば「主担当がOOOのとき、EMEAプールにフォールバック担当者を追加する」とか「12か月より古いアカウントの重複排除ルールを引き締める」。各変更には所有者、リリース日、測定計画があります。
- 再バランスすべきセグメント(5分)。 作業量のレビュー。ある担当者が次の担当者の3倍のリードを得ていないか。ある地域が過剰に対応され、別の地域が手薄になっていないか。
- 成果(5分)。 先月うまくいったルール変更。会議が純粋な欠陥レビューになるのを防ぎます。
会議を文書化します。ルール変更履歴を共有ドキュメント(Notion、Confluence、何でもよい)にリリースし、バージョン管理して日付を付けます。18か月後に次のMOps現場担当者がこれを引き継ぐとき、その変更履歴が彼らを救います。
これは、マーケティングオペレーションマネージャーの職務記述書が「ルーティングレイヤーを端から端まで所有する」と言うときに説明している作業です。一度きりの設定ではありません。恒久的な面です。
ルーティングは本番コードである
ルーティングを運用するMOps現場担当者にとって、最大のマインドセットの転換はこれです。これはプロジェクトではなく、ルールファイルは火曜の午後にいじるSalesforceのサンドボックスオブジェクトではありません。本番コードです。会社がお金をかけて生成するすべてのリードを処理しています。質の悪いルール変更は、質の悪いコードデプロイよりもコストがかかります。失敗モードが静かだからです。ルーティングされなかったリードは誰にも見えません。
そのように扱ってください:
- バージョン管理。 すべてのルール変更を、タイムスタンプ、所有者、理由とともに文書化します。
- レビュー。 大きな変更(セグメントの再バランス、新しいABMロジック)は、リリース前にもう1人の目を通します。
- 監視。 ダッシュボードを継続的に動かします。違反率は四半期のチェックインではなく、追跡対象のKPIです。
- テスト。 ルールを本番に切り替える前に、先月のリード量に対してサンドボックスかドライランモードで実行し、ルーティングの出力が筋が通っているか確認します。
同じ規律はアトリビューションモデルにも当てはまります。宗教戦争なしのマーケティングアトリビューションをご覧ください。
担当者がリードを無視しているのは、ほぼ決して担当者がリードを無視しているのではありません。それを構築したAEが2024年に去って以来、誰も触れていないルールなのです。あなたの仕事は、そのルールを見つけ、修正をリリースし、変更を文書化し、月曜の午前9時2分に届く次の「どうしてこんなことが起きるんだ?」のSlackが、本当に新しい何かについてのものであるようにすることです。
さらに詳しく

Principal Product Marketing Strategist