MQL to SQLのスコア閾値：両チームが受け入れられる数値の設定方法

どの収益チームでも最も議論される数字はクォータではありません。それはMQLの閾値です。

マーケティングはそれを低くしたいと思います。営業は高くしたいと思います。RevOpsは「データドリブン」にしたいと思います。そして最終的には誰もが数字（通常は50、75、または100）に同意します。その数字は過去の従業員から引き継がれたか、ブログ投稿からコピーされたか、丸い数字に感じたから選ばれたものです。

そのどれも間違っているわけではありません。しかしどれも正しくもありません。なぜなら、MQLの閾値は数学の答えではないからです。それはポリシーの決定事項です。毎月営業に流れるリードの数、それらのリードの平均品質、そしてマーケティングがPipelineを生み出すためにどれだけのプレッシャーを受けているかを決定します。どちらの方向に間違えても何かが壊れます：営業がゴミにあふれるか、実際には閾値の問題であるPipelineのギャップでマーケティングが責められるかです。

ここでは、自社のCRMのデータに基づいて、両チームがコミットできる閾値を設定する方法をご紹介します。

---

閾値の設定にベンダーのデフォルトや丸い数字ではなくクローズドウォン分析を使用するB2B営業チームは、Forrester Researchによると、MQL to OpportunityのConversion Rateが最大30%向上します。

MQLの閾値が低すぎると、連携していない組織では営業の却下率が平均40〜60%になります。つまり担当者は商談をクローズするのではなく、リードを却下するためにかなりの時間を費やすことになります（SiriusDecisionsのベンチマークデータ）。

閾値を変更する前に量と品質のトレードオフをモデル化する組織——+15/-15のシナリオ分析を実行——は、競合する選好ではなく共有データから議論できるため、Pipelineの混乱リスクを軽減します。

---

重要データ：リードスコアリングとMQL閾値

• MQL to SQLのハンドオフプロセスが厳密に連携した企業は、MarketingProfsのマーケティングと営業のアライメントに関する調査によると、マーケティング活動から209%多くの収益を達成しています。
• 営業に送られるリードのうち**実際にコンタクトされるのはわずか27%**で、閾値のキャリブレーションが実際に取り組まれるリードに多大な影響を与えます（InsideSales.com）。
• リードスコアリングの閾値を四半期ごとにレビューして再キャリブレーションする組織は、閾値を一度設定してそのままにするチームと比べて、MQL to OpportunityのConversion Rateが最大30%向上します（Forrester Research）。
• 閾値が低すぎると、連携していない組織ではMQLの却下率が平均**40〜60%**になります。つまり営業は商談をクローズするのではなく、リードを却下するために時間を費やしています（SiriusDecisionsのベンチマークデータ）。
• B2Bバイヤーは営業に連絡する前に購買意思決定のかなりの部分を完了しており（GartnerのB2Bバイヤージャーニーに関する調査）、閾値が高すぎると意思決定プロセスがすでに進んでいるリードを見逃す可能性があります。

閾値が実際に何をコントロールするか

数字に触れる前に、実際に何を調整しているかを理解することが役立ちます。

MQLの閾値はゲートです。リードの累積スコアがそれを超えると、リードはMQLからSQLに変換され、フォローアップのために営業にルーティングされます。閾値を1ポイント動かすたびに、3つのことが同時に影響を受けます。

営業に引き渡されるリードの量。 閾値を20ポイント下げると、流れるリードの数が2倍になるかもしれません。20ポイント上げると、営業は半分のリードしか受け取りませんが、それらが2倍準備ができていることを期待します。どちらも本質的に優れているわけではありません。営業キャパシティ、担当者のフォローアップ速度、各スコアバンドでのConversion Rateによります。

ハンドオフ時の平均品質。 これは営業が最も気にするものです。担当者がコンバートしないリードに時間の40%を費やしている場合、閾値はおそらく低すぎます。彼らがマーケティングから渡されるものの80%をクローズしているがボリュームについて不満を言っている場合、おそらく高すぎます。

マーケティングの生産プレッシャー。 高い閾値は、同じMQL数を生み出すためにマーケティングがより多くの生リードを生成しなければならないことを意味します。それにはメディア費用、コンテンツ、キャンペーンオーバーヘッドのコストが増えます。低い閾値はトップオブファネルの生成へのプレッシャーを緩めますが、問題をダウンストリームに移します。

これら3つは独立していません。1つを最適化すると、他のものに影響します。だからこそ閾値は設定タスクではなく、戦略的な会話なのです。

初期閾値の設定：閾値設定メソッド

閾値設定メソッドは、防御可能なMQL to SQLのスコア閾値を設定するための4ステップのデータファーストプロセスです。過去の従業員から丸い数字を引き継いだり、ベンダーのデフォルトをコピーしたりする代わりに、実際のクローズドウォンデータに閾値の決定を固定します：クローズドウォン案件を引き出し、スコア分布をプロットし、（平均ではなく）変曲点を見つけ、却下率に対して検証します。結果は推測やベンダーのデフォルトではなく、実際にクローズしたバイヤーの姿に基づいた閾値です。

ゼロから始める場合、または恣意的に設定された閾値をリセットする場合は、過去のクローズドウォンデータから始めます。これはあなたが持つ唯一の誠実なアンカーです。リード資格審査フレームワークは実際にクローズを予測する属性を教えてくれます——閾値の数字に触れる前に、それをスコアリング入力として使用してください。

ステップ1：直近12〜18か月のクローズドウォン案件を引き出す。

ウォンとしてクローズしたすべての案件をエクスポートします。必要なのは、SQLに変換された時点でのリードのスコアです。現在のスコアでも、最終的なエンリッチされたスコアでもなく、ハンドオフ時のスコアです。一部のMAPは自動的にこれをログします。そうでない場合は、アクティビティのタイムスタンプから再構築する必要があります。

ステップ2：スコア分布をプロットする。

それらのウォン案件のSQL変換時のスコアの度数ヒストグラムを作成します。通常、次のようなものが見られます：

ステップ3：平均ではなく変曲点を見つける。

ウォン案件全体の平均スコアは72かもしれません。しかし72が正しい閾値というわけではありません。分布の傾きが変わる場所、具体的にはスコアバンドあたりのウォン案件の割合が急激に上昇し始める場所を探します。上の表では、その変曲点は60〜80の間に位置しています。閾値は平均ではなく、高濃度バンドの底近くに属します。

ステップ4：却下率に対して検証する。

却下されたか一度もコンタクトされなかった案件について同じ分析を実行します。SQL変換時のスコアはどうでしたか？却下されたリードが60未満に集中している場合、60が防御可能なフロアであるという良い証拠があります。

このメソッドは正確な答えを与えません。しかし実際にクローズしたもの、直感やベンダーのデフォルトではないものに基づいた範囲を提供します。McKinseyのPipelineコンバージョンに関する調査は、高い量ではなく早期の資格審査の規律が最大のPipeline改善をもたらすと一貫して示しています。

量と品質のトレードオフ

閾値のキャリブレーションは、数字を動かした場合に何が起きるかをモデル化せずには完了しません。

閾値が低すぎる場合：

マーケティングは喜びます：MQL量が良く見えます。しかし営業はより多くのリードを却下し始めます。却下率は30%を超え、40%になります。担当者はコールをかけるよりも「適合なし」のログに多くの時間を費やします。低品質なリードに取り組む担当者はフォローアップキャパシティを無駄にし、コネクト率目標を外します。最終的に、営業はMQL指定を完全に信頼しなくなります。マーケティングが渡すものはすべてデフォルトで懐疑的に扱われます。

これが低い閾値の隠れたコストです。担当者の時間を無駄にするだけでなく、リード資格審査システムへの信頼性を損ないます。

閾値が高すぎる場合：

営業が受け取るリードは少なくなりますが、Conversion Rateは印象的に見えます。マーケティングはMQL目標を達成するのに苦労します。80%準備ができているが閾値をわずかに超えていない良いリードがナーチャープログラムで古くなり、最近性とインテントシグナルを失います。マーケティングはPipelineのギャップが自分たちのせいではないと主張し続けます。資格審査を改善する代わりに、より多くのトップオブファネルのボリュームを生み出すプレッシャーが高まります。

閾値を変更する前にトレードオフをモデル化する方法：

直近90日間のリードを引き出します。各スコアバンドについて計算します：

• そのバンドにリードが何件あったか
• 何パーセントがPipelineにコンバートしたか
• コンバートしたPipelineの何パーセントがクローズしたか

次に2つのシナリオをモデル化します：現在の閾値－15ポイントと現在の閾値＋15ポイント。それぞれのPipelineと収益への影響を推定します。これにより、マーケティングと営業の間の会話が選好ではなく具体的なものについて議論できます。

セグメント別の閾値

1つの閾値がすべてのシナリオに適合することはほとんどありません。別々の閾値を検討してください：

エンタープライズ vs. SMB： エンタープライズのリードは、SMBのリードよりも行動シグナルが遅いことが多いです。2,000名の企業のVPは、50名の企業のDirectorよりも少ないページしか訪問してからコンタクトしてきます。両方に同じ閾値を適用すると、SMBリードが系統的に過剰資格を得て、エンタープライズリードが過小資格を得ます。SMBに65、エンタープライズに45の閾値は、両方にフラット60よりもパフォーマンスが良いかもしれません。

インバウンド vs. アウトバウンド支援： フォームに到達する前にBDRがタッチしたリードは、コールドインバウンドリードとは異なるインテントプロファイルを持ちます。彼らは独立して検索していたのではなく促されていたため、行動スコアが低いかもしれません。アウトバウンド支援のコンバージョンに対してより低い閾値が適切なことが多いです。

新規顧客 vs. 拡大： 既存顧客からの拡大リードは購買サイクルが短縮され、クローズ率が高くなります。新規顧客と同じ閾値を適用すると、アカウント管理に直行すべき時に一部の拡大商談がナーチャーで滞留します。

これらは出発点です。セグメント別にクローズドウォンデータから自社のものを構築してください。

動的 vs. 固定の閾値

固定閾値は次のように言います：「スコア≥65 = SQL」。

動的またはルールベースの閾値は次のように言います：「スコア≥65、またはスコア≥45かつデモリクエスト送信済み」。

動的閾値はより精確ですが、ガバナンスが難しいです。スコアゲートに関係なくオーバーライドすべき特定の高インテントアクション（デモリクエスト、価格ページ訪問、ダイレクトチャット）がある場合に有効です。

リスクは複雑さです。動的ルールがOR条件と例外の迷路になると、誰もリードがいつトリガーするかを理解できません。特定のリードがなぜコンバートしたかしなかったかについての異議が生じます。ガバナンスが崩壊します。

現実的な中間地点：固定閾値を主要なゲートとして維持し、高インテントのオーバーライドを2つ以内にとどめます。「スコア≥60、またはデモリクエスト送信済み、またはICPに一致する会社からのダイレクトインバウンドチャット」は理解できます。10のオーバーライド条件は理解できません。

両チームに合意してもらう

閾値の会話は、マーケティングの数字に営業が従わなければならないというフレーミングで失敗します。両チームが共有KPIの共同オーナーであることを理解したときに成功します。

コンプライアンスフィルターではなくサービスレベルアグリーメントとしてフレーミングします。 マーケティングは一定の品質レベルでリードを渡すことをコミットしています。営業はそれらのリードを一定の時間枠内に取り組むことをコミットしています。閾値はそのコントラクトの品質側を定義します。MQL to SQLハンドオフプロセスは受け入れ側を定義します。

会話を却下率に固定します。 営業に「どの却下率なら許容できますか？」と尋ねます。答えが15%であれば、過去データに基づいて85%のAcceptanceを生み出す閾値から逆算します。これは議論を再フレーミングします。数字がどうあるべきかを議論する代わりに、両チームが気にするアウトカムのために解決しています。

インパクトモデリングを共有します。 会議の前に+15 / -15のシナリオモデルを構築します。各シナリオの下でPipelineボリュームとクローズ率に何が起きるかを両チームに示します。共有データで下された決定は、最も声高に主張する人物によって下された決定よりも耐久性があります。

合意を共同リードスコアリングフレームワークに文書化します。 合意したら、閾値、根拠、そしてレビューをトリガーする条件を書き留めます。Forresterのスコアリングモデルの失敗パターンに関する調査は、文書化されていない閾値をスコアリングプログラムが18か月以内に信頼性を失う最も一般的な理由の1つとして特定しています。閾値がなぜそこに設定されているかについての組織の記憶が、次の新入社員が6か月後に恣意的にそれを変更することを防ぎます。

閾値変更のテスト

グローバルに閾値を変更する前にテストしてください。A/Bパイロットは意図しない結果のリスクを軽減します。

パイロットの構成方法：

リードフローを地域、担当者チーム、またはソースチャンネルで分割します——どのパーティションが最も運用上の意味があるか。1つのグループに新しい閾値を適用し、コントロールグループには既存の閾値を維持します。6〜8週間以上実行します——テストリードの少なくとも部分的なPipelineの進行を確認するのに十分な長さです。

測定するもの：

• テスト vs. コントロールのMQL to SQLのConversion Rate
• SQLのAcceptance Rate（営業はより多く受け入れたか少なく受け入れたか？）
• 最初のコンタクトまでの時間（担当者はより条件を満たしたリードに素早く関与したか？）
• 30日と60日時点のMQL to OpportunityのRate
• 90日時点のテストコホートによる影響を受けた収益

コントロールグループ効果に注意してください。 営業がどのリードが「テスト」リードかを知っている場合、それらを異なって扱うかもしれません。CRMでその指定を見えないようにしてパイロットを実行してみてください。

レビュートリガー：いつ再検討するか

今日設定した閾値は永遠に正しいわけではありません。危機を待つのではなく、レビューのための明示的なトリガーを組み込んでください。

新製品ローンチ： 新しい製品ラインは新しい行動シグナルと新しいICPを作ります。既存のスコアリングモデルは新製品のオーディエンスのインテントシグナルをまったく捉えていないかもしれません。

新しいICPセグメント： 新しい業種や会社規模バンドに拡大する場合、その行動パターンは異なります。古い閾値を適用すると、他の誰かのデータで構築されたモデルに対して彼らを資格審査することになります。リードライフサイクルステージをレビューして、閾値が新しいセグメントの正しいトランジションポイントにあることを確認してください。

大きなキャンペーンシフト： コンテンツ重視のキャンペーンはデモプッシュキャンペーンとは異なる行動シグナルを生み出します。マーケティングがチャンネルミックスを大幅に変更した場合、Pipeline内のスコアの分布も変化します。

営業チームの変更： 新しい担当者は異なる受け入れ行動を持ちます。5名のエンタープライズ担当者を雇用したチームは、高速度SMBを運営するチームとは異なるリード品質が必要です。

却下率のスパイク： 却下率が90日ローリング期間で10ポイント以上上昇した場合、それはモデルのシグナルであり、人の問題ではありません。どちらのチームも責める前に閾値をレビューしてください。完全な診断フレームワークについてはリードスコアリングモデルの劣化の記事も参照してください。

Reworkの分析： 業界ベンチマークと閾値設定メソッドに基づき、クローズドウォンのスコア分布に閾値を固定するほとんどのB2Bチームは、15〜25%の却下率で運営しています——丸い数字を継承または推測する組織で見られる40〜60%の却下率のおよそ半分です。実際の意味：現在の却下率が35%を超えている場合、スコアリングモデルの改善よりも、自社のクローズドウォンデータを使用した閾値の再キャリブレーションがMQL to PipelineのConversion Rateをより速く改善します。ReworkのCRMとPipelineツールは、SQL変換時のスコアを自動的に追跡し、チームが手動のCRMエクスポートなしに閾値設定メソッドを実行するために必要なクローズドウォンデータセットを提供します。現在のプランの詳細はrework.com/pricingをご覧ください。

共有インフラとしての閾値

MQLの閾値はマーケティングの設定でも営業の選好でもありません。両チームが依存するインフラです。

正しくキャリブレーションされると、マーケティングは「良い」が何を意味するかを知ります。営業は何を期待するかを知ります。両チームはPipelineが健全なときに同じ数字を指し示し、そうでないときに同じ数字を診断できます。リード品質についての異議は、努力についての非難ではなく閾値についての会話になります。

これがこれを正しく行うことの実際の価値です。最適化されたConversion Rateだけではありません（それも重要ですが）。両チームが条件を満たすとは何を意味するかの共有定義で働いているということです。そして、それが得られると、マーケティングと営業のアライメントの残りの作業がずっと容易になります。

よくある質問

MQL to SQLのスコア閾値をどのように設定しますか？

過去12〜18か月のクローズドウォンデータから始めます。ウォンとしてクローズしたすべての案件をエクスポートし、SQL変換の瞬間のリードスコア——最終的なエンリッチされたスコアではなく、ハンドオフ時のスコア——をプロットします。スコアバンドあたりのウォン案件の割合が急激に上昇する分布内の変曲点を探します。高濃度バンドの底近くに閾値を設定します。これは閾値設定メソッドであり、丸い数字の推測ではなく防御可能でデータに基づいた数字を生み出します。

100の閾値が常に機能しないのはなぜですか？

100の閾値は最大スコアが最大の準備ができていることと等しいと仮定します。しかしほとんどのリードスコアリングモデルは、さまざまな行動にポイントを割り当てます。そのいくつか（メール開封、単一のコンテンツダウンロード、低インテントのページ訪問）はクローズの弱い予測因子です。低シグナルアクションを通じてゆっくりと100ポイントを積み上げたリードは、価格ページを2回訪問してデモをリクエストした70ポイントのリードよりも営業準備ができていないかもしれません。閾値は最大ポイント合計ではなく、クローズドウォン案件が実際にクラスターする場所にキャリブレーションすべきです。

正しいMQLの却下率目標は何ですか？

ほとんどの連携したチームは15〜25%のMQLの却下率を目標にしています。15%未満の却下率は閾値が高すぎることを意味するかもしれません——営業は非常に少ないリードしか受け取っておらず、マーケティングは過剰資格審査しているかもしれません。35%を超える率は、閾値が低すぎるか、スコアリングモデルが劣化している——リードが営業が条件を満たしていると認識するものに一致する前に営業に到達している——という強いシグナルです。SiriusDecisionsのベンチマークデータは連携していない組織の平均を40〜60%に置いており、これは主に無駄な営業キャパシティです。

MQLの閾値はどのくらいの頻度でレビューすべきですか？

最低限、四半期ごとです。明示的なレビュートリガーには次のものが含まれます：新製品ローンチ、ターゲットICPセグメントの変更、大きなキャンペーンミックスのシフト、重大な担当者チームの変更、または90日ローリング期間で10ポイント以上の却下率スパイク。危機が表面化するまで待つチーム——通常は四半期ビジネスレビューでのPipelineギャップの会話——は、通常、問題が表面化する6か月以上前から閾値が間違っていたことを発見します。

異なるセグメントは異なる閾値を持つべきですか？

はい、ほとんどの場合。エンタープライズのリードはSMBのリードよりも行動シグナルが遅いことが多いです。アウトバウンド支援のリードはコールドインバウンドとは異なるインテントプロファイルを持ちます。既存顧客からの拡大リードは購買サイクルが短縮されています。すべてのセグメントに適用されるフラットな閾値は、一方のグループを系統的に過剰資格審査し、もう一方を過小資格審査します。最もボリュームの多いセグメントから始め、キャリブレーションされた閾値を設定し、同じクローズドウォン分析メソッドを使用して各主要セグメントの別々の閾値をモデル化します。

閾値変更でA/Bテストを実行できますか？

はい、Pipelineの混乱なしに閾値を変更する最も安全な方法です。リードフローを地域、担当者チーム、またはソースチャンネルで分割します。1つのグループに新しい閾値を適用し、コントロールグループには既存の閾値を維持します。6〜8週間実行します。MQL to SQLのConversion Rate、SQLのAcceptance Rate、最初のコンタクトまでの時間、30日と60日時点のMQL to OpportunityのRateを測定します。テスト指定をCRMで見えないようにして、担当者がテストリードを異なって扱うことを防ぎます。

固定閾値と動的閾値の違いは何ですか？

固定閾値は単一のスコアゲートです：「スコア≥65 = SQL」。動的閾値は条件付きルールを追加します：「スコア≥65、またはスコア≥45かつデモリクエスト送信済み」。動的閾値はより精確ですが、ガバナンスが難しいです。推奨される中間地点は、2つ以下の高インテントのオーバーライド条件を持つ固定閾値を主要なゲートとして使用することです。2つ以上のオーバーライド条件はガバナンスの迷路を作り出し、誰もどのリードがトリガーするかを確実に予測できなくなり、モデルの異議の解決が難しくなります。

さらに詳しく

• 共同リードスコアリング：フィット、インテント、行動
• MQL定義フレームワーク
• リードスコアリングモデルの劣化
• MQL to SQLハンドオフプロセス
• クローズドループレポーティングの説明
• リード資格審査フレームワーク
• MQLの却下とリサイクル