MQL→SQL転換がうまくいかない企業の共通課題
マーケと営業が納得できる転換基準を設計し、転換率を改善するために必要なのは、マーケと営業が合意した明確な基準を設計し、MAツールで自動判定した上で、定期的な振り返りで基準を調整するサイクルを回すことです。
MQL（Marketing Qualified Lead） とは、マーケティング活動で獲得し、スコアリング等により営業に渡す価値があると判断された見込み顧客を指します。一方、SQL（Sales Qualified Lead） とは、営業・インサイドセールスがBANT等のヒアリングで商談化可能と判断したリードのことです。
MQL→SQL転換率の理想値は約13%とされています（グローバルSaaS/IT系BtoBを前提としたベンチマーク）。ただし、この数値は業種・商材単価・営業体制により大きく変動するため、自社の状況に合わせて評価する必要があります。
多くのBtoB企業で「MQLを営業に渡しても商談化しない」「マーケと営業の間でリードの質について対立が起きている」という課題が発生しています。なぜこのような問題が起きるのでしょうか。その原因の多くは、転換基準の設計と運用にあります。
この記事で分かること
- MQL・SQL・BANTの定義と違い
- MQL→SQL転換基準の設計方法
- スコアリング項目と配点の具体例
- 転換基準を定着させる運用サイクル
- 合意形成のためのチェックリスト
MQL・SQL・BANTの基礎知識
MQL→SQL転換を成功させるには、まず用語の定義を正確に理解し、マーケと営業で認識を揃えることが出発点です。
MQLとSQLの定義と違い
MQLは、マーケティング部門がスコアリングやセグメンテーションにより「営業に渡す価値がある」と判断したリードです。資料ダウンロードやセミナー参加など、一定の行動を取った見込み顧客が該当します。
SQLは、営業・インサイドセールスがヒアリングを通じて「商談化可能」と判断したリードです。MQLがマーケティング側の判断であるのに対し、SQLは営業側の判断で決まるという点が大きな違いです。
BANTによる商談化判定の考え方
BANTとは、Budget（予算）、Authority（決裁権）、Need（ニーズ）、Timeframe（導入時期）の4項目でリードを評価するフレームワークです。
BANT4項目のうち3項目以上の充足をSQL判定基準とするケースが「相場」とされています。ただし、商材や営業体制によって適切な基準は異なるため、自社の商談データを分析して判断することが重要です。
リードスコアリングとは、リードの属性（業種・規模・役職）と行動（資料DL・セミナー参加等）にスコアを付与し、営業優先度を判定する手法です。属性スコアと行動スコアの2軸で設計するのが標準的なアプローチです。
MQL→SQL転換基準の設計方法
MQL→SQL転換を成功させるには、マーケと営業が合意できる転換基準を設計することが不可欠です。
よくある失敗パターンとして、スコアリング基準をマーケ部門だけで決め、営業に共有しないまま運用するケースがあります。この考え方では成果が出ません。結果として営業が受け取ったリードを信頼せず、せっかくの仕組みが形骸化してしまいます。
SLA（Service Level Agreement） とは、MQL引き渡し後の対応時間など、マーケと営業間で合意するサービス水準のことです。転換基準と併せてSLAを設定することで、リードが適切なタイミングでフォローされる仕組みを作ることができます。
日本BtoBでは属性＋行動スコアの合計50〜80点以上をMQL閾値とする設計が一般的とされています。ただし、この数値は一般的な相場感であり、自社の商談データで検証・調整が必要です。
マーケと営業の合意形成プロセス
MQL/SQLの定義は営業と文書化して合意し、定期的に見直すことが定着の鍵です。以下のステップで進めることをおすすめします。
- 過去の商談データを分析し、成約に至ったリードの共通点を抽出する
- マーケと営業で合同ミーティングを開催し、MQL/SQLの定義案を議論する
- 合意した定義を文書化し、全員がアクセスできる場所に保管する
- 月次または四半期でレビューし、必要に応じて基準を調整する
スコアリング設計の実践ポイント
スコアリングは、属性スコア（企業規模・役職）と行動スコア（資料DL・セミナー参加）の2軸で設計するのが標準的なアプローチです。
MAツールのAIスコアリング機能を活用する場合、一定量のデータが必要です。たとえば、HubSpotのAIスコアリング自動生成には、転換済み25件＋未転換25件＝最低50件のコンタクトデータが必要とされています。
属性スコアと行動スコアの設計例
以下は、スコアリング項目と配点の一般的な設計例です。自社の商材や営業プロセスに合わせて調整してください。
【比較表】スコアリング項目と配点例
| カテゴリ | 項目 | 配点例 |
|---|---|---|
| 属性スコア | 従業員数100名以上 | +15点 |
| 属性スコア | 従業員数50〜99名 | +10点 |
| 属性スコア | 従業員数50名未満 | +5点 |
| 属性スコア | 役職: 部長以上 | +20点 |
| 属性スコア | 役職: 課長・マネージャー | +15点 |
| 属性スコア | 役職: 担当者 | +5点 |
| 属性スコア | 業種: ターゲット業種 | +10点 |
| 行動スコア | 資料ダウンロード | +10点 |
| 行動スコア | セミナー参加 | +15点 |
| 行動スコア | 料金ページ閲覧 | +20点 |
| 行動スコア | 問い合わせフォーム到達 | +25点 |
| 行動スコア | メール開封 | +3点 |
| 行動スコア | メールクリック | +5点 |
※ 閾値（50〜80点）は一般的な相場感であり、自社データで検証・調整が必要です。
MQL→SQL転換の運用定着と改善サイクル
転換基準を設計しただけでは成果は出ません。運用を定着させ、継続的に改善するサイクルを回すことが成功の鍵です。
SLAの設定とモニタリング
MQL→営業への引き渡し後、24時間以内に初回コンタクトを行うのが標準的なSLAとされています。このルールをマーケ・営業間で合意しておくことで、リードが放置されるリスクを軽減できます。
SLAのモニタリングには、以下の指標を追跡することをおすすめします。
- MQL引き渡しから初回コンタクトまでの時間
- MQL→SQL転換率
- SQL→商談化率
- 営業からのフィードバック（リードの質に関する評価）
定期レビューによる基準の改善
営業からのフィードバック（受注/失注理由）をスコアリング改善に反映するPDCAサイクルが重視されています。
ある企業では、スコアリング最適化によりMQLからの商談化率が30%超に向上した事例があります（マクロミル紹介事例）。また、SQL定義の見直しにより商談化率18%→36%に改善した事例も報告されています（マクロミル紹介事例、SaaS企業A社）。ただし、これらは特定企業の結果であり、自社での効果を保証するものではありません。
【チェックリスト】MQL→SQL転換基準の合意形成チェックリスト
- MQLの定義を文書化した
- SQLの定義を文書化した
- BANT項目のうち何項目でSQL判定するか決めた
- 属性スコアの項目と配点を決めた
- 行動スコアの項目と配点を決めた
- MQL閾値（合計点数）を設定した
- マーケ・営業間でMQL/SQL定義を合意した
- MQL引き渡し後のSLA（対応時間）を設定した
- MAツールでスコアリング設定を完了した
- SFAとの連携設定を完了した
- MQL→SQL転換率のモニタリング方法を決めた
- 営業からのフィードバック収集方法を決めた
- 定期レビューの頻度（月次/四半期）を決めた
- レビュー時の基準調整プロセスを決めた
- 関係者への周知を完了した
まとめ｜MQL→SQL転換は基準設計と運用サイクルで成果が決まる
MQL→SQL転換を成功させるポイントを振り返ります。
- MQLとSQLの定義を明確にし、マーケと営業で合意する
- スコアリングは属性と行動の2軸で設計する
- BANT項目を活用してSQL判定基準を設計する
- MQL引き渡し後のSLAを設定し、モニタリングする
- 営業フィードバックを活用して定期的に基準を改善する
MQL→SQL転換を成功させるには、マーケと営業が合意した明確な基準を設計し、MAツールで自動判定した上で、定期的な振り返りで基準を調整するサイクルを回すことが成功の鍵です。
本記事で紹介したチェックリストを活用して、自社のMQL→SQL転換基準を見直してみてください。