MQL→SQL移行基準シート｜営業受け入れ基準の作り方とチェック項目
MQL（Marketing Qualified Lead）からSQL（Sales Qualified Lead）への移行基準は、マーケと営業のSLAの中核であり、ここが曖昧だと営業からの差し戻しが頻発します。マーケから渡されたリードに対して「これは温度感が低い」「自社のターゲットではない」と営業が判断する状態が続くと、組織内の信頼関係が崩れます。
本記事では、MQL→SQL移行基準シートを「営業視点」と「マーケ視点」の両方から設計する方法と、5ステップでの実装手順、運用後のSLA管理方法を解説します。MQL・SQLの定義と営業アラインメント を併せて読むと、より深い設計判断ができるようになります。
本記事のポイント
- MQL→SQL移行基準は、マーケと営業の摩擦を構造的に解消するためのSLA文書であり、両部門の合意形成プロセスが文書の中身より重要です。
- 基準シートは「行動条件」「属性条件」「タイミング条件」の3軸で設計し、各案件に対する判定が一意になる構造にします。
- 運用後は四半期ごとに営業フィードバックを取り入れて基準を更新する仕組みが必須で、設計だけで終わると半年で陳腐化します。
この記事で扱うテーマ
このページで答える質問
- 基準シートは何ページくらいになりますか？
- 営業との合意形成が難しい場合はどう進めればよいですか？
- MAツールに基準を実装するときの注意点は？
- 基準を変更すると過去のリードはどう扱えばよいですか？
MQL→SQL移行とは：何のための基準か
MQL→SQL移行は、マーケが育成したリードを営業が受け入れて商談化に進めるかを判定するゲートです。MQLは「マーケから見て見込みがある」という判定、SQLは「営業から見て商談化できる」という判定で、両者の認識を一致させる作業がこの基準シートの役割です。
基準が曖昧だと2つの問題が起きます。1つ目は、営業からの差し戻しです。「このリードは温度感が低いので自分たちでは追わない」と判断され、マーケに戻されると、リードが失効する確率が上がります。2つ目は、マーケKPIの形骸化です。MQL数を増やしても、SQL率が低ければマーケの努力が成果につながらない状態になります。マーケと営業のSLA の文脈で、この基準が中核ドキュメントの位置づけにあります。
基準シートは1度作って終わりではなく、運用しながら継続的に磨くドキュメントです。市場・商材・営業体制の変化に応じて、四半期ごとに見直す前提で設計します。
営業視点の基準：受け入れ可能なリード像
営業視点で見る「SQLとして受け入れ可能なリード」は、以下の3観点で定義できます。1つ目は「ターゲット適合性」。業種・企業規模・部署・役職が、自社のターゲット顧客像と一致しているか。2つ目は「ニーズの顕在度」。検討フェーズが認知ではなく比較・絞り込みに入っているか。3つ目は「タイミング」。3〜6ヶ月以内に意思決定する可能性があるか。
営業に「どんなリードを欲しいか」を直接ヒアリングして基準を作ります。「過去6ヶ月で受注に至った10件のリードに共通する条件は何か」を分析するのが具体的なアプローチです。共通項を抽出すると、属性条件と行動条件の組み合わせが見えてきます。リードスコアリング の設計と直結する作業になります。
営業視点の基準を文書化する際は、Must条件（必須）とShould条件（あれば望ましい）を分けるのが定石です。Must条件をすべて満たすリードのみSQLとし、Should条件は加点要素として扱う構造にすると、判定が機械的に進みます。
マーケ視点の基準：提供可能なリード像
マーケ視点で見る「SQLとして渡せるリード」は、現状のマーケ施策で実現可能なリード像を反映する必要があります。営業の希望基準が高すぎると、マーケが供給できるSQLがゼロになるため、両者の現実的な交差点を探る作業が必要です。
マーケ視点の基準を作る際は、過去のリード行動データを分析します。資料DLからウェビナー参加までの行動量、ナーチャリングメールへの反応率、Webサイト閲覧の深さなど、行動条件で「マーケが見込みありと判定できる根拠」を整理します。リードナーチャリング 設計と一体で考えるのが現実的です。
属性条件は、フォーム入力時の情報＋エンリッチメント（外部データベースで補完）で取得します。BtoB向けには、企業データベース（FORCAS、Salesforce等）のアカウントデータを連携することで、業種・規模・売上などを自動取得できる体制を整えると、判定の自動化が進みます。
5ステップでシートを作る
MQL→SQL移行基準シートの作成手順は5ステップです。ステップ1：過去6〜12ヶ月の受注リード分析。受注に至った20〜30件のリードについて、業種・規模・役職・行動履歴・タイミングを集計し、共通項を抽出します。
ステップ2：失注リード分析。同じ視点で失注リードも分析し、SQLに不適切な条件（除外条件）を抽出します。ステップ3：営業との合意形成。営業責任者・営業担当者数名と合同ワークショップを開催し、Must/Should条件を確定します。インサイドセールスKPI の設計と一体で進めるとスムーズです。
ステップ4：シートに落とし込み。Excel・スプレッドシートで「行動条件」「属性条件」「タイミング条件」の3軸テーブルを作り、各条件に閾値とスコアを設定します。ステップ5：MAツールへの反映。基準をMA（HubSpot・Marketo・Account Engagement等）に設定し、自動判定が走るようにします。
運用とSLA：四半期レビューが必須
基準シートを設計しても、運用が回らなければ意味がありません。SLA（Service Level Agreement）として、マーケと営業の間で次の3点を文書化することが重要です。1点目は「マーケがSQLを渡したら、営業は24時間以内にコンタクト開始する」。2点目は「営業がSQLを差し戻す場合、理由を記録する」。3点目は「四半期ごとに基準シートをレビューする」。
差し戻し理由の記録は、基準改善の最重要データです。「ターゲット規模が違う」「タイミングが早い」「ニーズが顕在化していない」など、差し戻し理由をカテゴリ化して集計すると、基準のどこを直すべきかが見えてきます。リードスコアリング導入でハマる5つの失敗 でも、差し戻し理由のフィードバックループの欠如が失敗パターンとして挙げられています。
四半期レビューでは、SQL率（MQLに対するSQL化率）・有効商談率・受注率を分析し、基準の精度を評価します。SQL率が想定より低ければ基準が厳しすぎる、有効商談率が低ければ基準が甘すぎるなど、KPIの動きと基準の関係を見ながら継続的に磨いていく流れが定石です。
よくある質問
基準シートは何ページくらいになりますか？
1〜2ページ（A4サイズ）が現実的です。10ページを超えると現場で使われなくなります。Must条件5〜10個、Should条件10〜20個に絞り、判定フロー図を1枚加える構成が定着しやすくなります。
営業との合意形成が難しい場合はどう進めればよいですか？
過去の受注データ分析から始めるのが最も効果的です。「受注した10件のリードに共通する条件は何か」をデータで示すと、感覚的な議論ではなく客観的な議論になります。営業責任者と1on1で過去案件を振り返るアプローチも有効です。
MAツールに基準を実装するときの注意点は？
条件の重複と矛盾を避けることです。複数の条件が組み合わさるとき、論理ANDかORかを明示し、優先順位を文書化しておくと運用ぶれを防げます。MAツールでテストモードを使い、過去のリードデータに対して仮判定を回して結果を確認するのが実装前のチェックとして有効です。
基準を変更すると過去のリードはどう扱えばよいですか？
基準変更日を境に、過去リードへの遡及判定はせず新規リードのみに新基準を適用するのが運用上シンプルです。過去リードを再判定すると、すでに営業が動いているリードが「基準外」と判定されるなど混乱を招くため、変更日以降の新規リードに限定する方針を推奨します。
次のアクション
本記事で扱った5ステップを実際に進めるには、行動条件・属性条件・タイミング条件の3軸で記入できる移行基準シートが起点になります。テンプレートが揃っていると、過去データ分析→営業合意形成→MAへの実装まで体系的に進められます。
そのまま使えるリードスコアリング・MQL/SQL定義シートを無料で配布しています。スコア定義の雛形・MQL→SQL移行基準テンプレ・差し戻し理由の集計シートまでを1ファイルに統合してあります。リードスコアリング・MQL/SQL定義シート（無料ダウンロード） から取得して、自社のSLA設計のたたき台として活用してください。
営業との合意形成プロセスや基準シートの初回設計に課題がある場合は、現状ヒアリングから一緒に整理する個別相談も活用してください。
