SQL（Sales Qualified Lead）とは？営業へ引き渡す条件とSLAの決め方

マーケティングの資料に「SQL」と書かれていたら、データベースの操作言語ではなく Sales Qualified Lead を指します。営業が引き取り、商談として追う価値があると判断したリードのことです。ところが「どこからがSQLか」に業界共通の数値はなく、各社がマーケティングと営業の合意で線を引きます。線が曖昧なままだと、マーケティングは渡した数を、営業は受けた数を数えて、同じリードの評価が食い違う。ここで整理するのは、SQLの定義、判定条件の作り方、そして引き渡しの取り決め（SLA）に何を書くかの3点です。

まとめ：SQL（Sales Qualified Lead）の要点

• SQLはSales Qualified Leadの略で、営業が「商談として追う」と判断したリードを指す。マーケティングが選別したMQLの次の段階にあたる。
• 標準的な流れはMQL（マーケティングが選別）→SAL（営業が受理）→SQL（営業が商談化可能と判定）。SALを挟むことで、渡した／受け取っていないの食い違いが記録に残る。
• SQLの判定条件は自社で決める。予算・決裁権・課題・時期の4条件（BANT）が最小の型になる。
• 取り決め（SLA）には、営業対応可能なリードの要件と、営業が定められた時間内に取る手順の両方を書く。SiriusDecisionsは初回フォローについて24時間以内をベストプラクティス、72営業時間以内が上限としている。
• 個人から買い手グループ単位への転換は2017年のDemand Unit Waterfallで済んでおり、Forresterは2021年5月4日にその後継としてB2B Revenue Waterfallを発表した。旧来の段階名を使い続けるかは設計判断になる。
• MQLとSQLの違いそのものを詳しく比べたい場合はMQLとSQLの違いを徹底解説：ビジネスでの重要性とはで扱っている。

SQL（Sales Qualified Lead）の定義と、営業が引き取る条件

営業が「商談として追う」と判断した段階がSQL

SQLは、マーケティングから渡されたリードを営業が精査し、直接アプローチする価値があると認めた状態を指します。資料をダウンロードした、価格ページを何度も見た、といった行動でマーケティング側が選別した段階はMQL（Marketing Qualified Lead）にとどまります。SQLはその先で、営業が接触して確度を確かめたうえで置く印です。

この区別が実務で効くのは、責任の所在が変わるからです。MQLまではマーケティングが数と質に責任を持ち、SQLに変わった時点で商談化の責任は営業へ移ります。したがってSQLの定義を作る作業は、用語を揃える作業ではなく、どこから営業の数字になるかを決める作業です。マーケティング側の選別基準をどう作るかはMQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順で扱っています。

BANTを最小の型にした判定条件の自社化

SQLの判定条件に業界標準の数値はありません。出発点として使えるのがBANTです。Budget（予算の有無と規模）、Authority（決裁に関与する立場か）、Need（自社の製品で解ける課題があるか）、Timeline（導入時期が具体的か）の4条件で、この4つが営業ヒアリングで確認できていればSQLとする、という置き方ができます。

4条件をすべて満たすことを必須にすると、SQLがほとんど生まれません。予算が未確定でも決裁者が課題を認識していれば商談は進むためです。実務では「NeedとTimelineは必須、BudgetとAuthorityはどちらか」のように、自社の受注実績に合わせて重みを変えてください。判定を行動スコアで自動化するなら、スコア設計の手順はリードスコアリングとは？その基本的な概要と役割についてにあります。

マーケティングのSQLとデータベースのSQLは別物

SQLという略語は、マーケティングの Sales Qualified Lead と、データベース操作言語の Structured Query Language で完全に衝突しています。後者はISO/IEC 9075として標準化された言語で、SELECT name FROM leads WHERE status = 'qualified' のような文でデータを取り出すためのものです。読み方も「エスキューエル」「シークェル」と分かれ、略語だけでは判別できません。

取り違えが起きやすいのは次の場面です。検索で「SQL とは」と調べると上位はほぼデータベース言語の解説で埋まるため、マーケティング文脈の情報にたどり着けません。求人票の「SQL経験必須」も、営業職の募集でない限りデータベースの読み書きを指します。MAツールやCRMの画面で「SQL」と表示されていれば、リード管理の項目名なのか抽出条件の設定欄なのかを確認してから触ってください。

判別の目安は文脈にあります。MQL・リード・商談・ナーチャリングといった語が周囲にあればSales Qualified Lead、テーブル・クエリ・データベース・SELECTがあればStructured Query Languageです。社内文書では初出時に「SQL（Sales Qualified Lead）」と正式名称を併記すると、この混乱は起きません。

MQL・SAL・SQLの順序と、SALを挟む理由

3段階の所有者と移行条件

MQLとSQLの間には、SAL（Sales Accepted Lead）という段階が置かれることがあります。営業がリードを正式に受理したことを記録する段階です。SiriusDecisions（2019年にForresterへ統合）のデマンドウォーターフォールで定義されたもので、Forrester（旧SiriusDecisions）のブログ（2012年8月2日、Jay Gaines）では、SALをインサイドセールス・フィールドセールス・チャネル営業がリードを受理する正式なプロセスと説明し、取り決めには営業対応可能なリードの要件と、営業が定められた時間内に取る手順を書くべきだとしています。

3段階を条件ごとに突き合わせて比べたい場合は、MQLとSQLの違いを徹底解説：ビジネスでの重要性とはで扱っています。本記事が扱うのはSQL側の定義と引き渡しです。

SALを省くとどうなるかを考えると、この段階の役割が分かります。MQLから直接SQLへ飛ばす運用では、営業が手を付けなかったリードと、手を付けたが商談にならなかったリードが同じ「SQLにならなかったMQL」として集計されてしまう。前者はマーケティングの責任ではなく引き渡し運用の問題ですが、数字の上では区別できません。SALは、この二つを切り分けるための記録です。

Forrester現行モデル（2021年）での段階名の変更点

MQL・SAL・SQLという段階名は、いまも多くの企業で使われる一方、提唱元では更新されています。個人のリードではなく買い手グループ（デマンドユニット）を単位に置く転換は、2017年に発表されたSiriusDecisions Demand Unit Waterfallで済んでいます。Forresterは2021年5月4日、その後継として「B2B Revenue Waterfall」を発表しました。買い手グループを対象にしたうえで既存顧客の需要まで計画に含め、更新・クロスセル・アップセルを目標機会の段階に機会タイプとして追加し、受注した案件を再び上流の機会として戻す循環を組み込んでいます。

実務への影響は、指標の置き方に出ます。B2Bの購買が複数人の合議で決まる以上、一人のMQLが立った時点を商談の起点として数えると、同じ企業から複数のMQLが立って重複計上が避けられません。買い手グループ単位に寄せるなら、企業単位で機会を束ねる集計を先に用意する必要があります。判断の目安はこうです。新規にCRMを設計するなら買い手グループ単位に寄せる。既存レポートが個人単位で回っているなら段階名は据え置き、企業単位の集計だけを併設するほうが安く済みます。

MQLからSQLへの引き渡し設計（SLA・ルーティング・差し戻し）

取り決め（SLA）に書く項目

引き渡しの取り決めで最低限決めるのは4点です。第一に、営業が受理する要件（どの属性・どのスコア・どの行動を満たしたリードか）。第二に、営業が着手するまでの時間。前掲のブログは初回フォローについて、24時間以内をベストプラクティス、72営業時間以内を上限として示しています。第三に、受理しない場合の差し戻し理由の分類。第四に、これらを記録する場所とレポートの頻度です。

差し戻し理由は、同ブログが3つに限るべきだとしています。ルーティングを誤って別の担当者に届いた手続き上の不備、レコードが不完全または不正確という事務上の不備、対象市場・活動・リードレベルの閾値を満たさない定義上の不一致の3つです。理由を自由記述にすると集計できず、改善の打ち手も決まりません。

要件だけ決めて時間を決めない取り決めは形だけになります。出典が要件と手順の両方に触れているのはこのためで、「営業対応可能なリード」の定義があっても、いつまでに何をするかがなければ、リードは受信箱に置き去りになる。上の24時間・72営業時間は出発点として使い、自社の初回接触から受注までの実績を見て補正してください。

ルーティングと差し戻しの経路

要件が決まったら、条件に合ったリードが自動で担当者へ届く経路を作ります。担当割り当ての基準（地域・業種・企業規模・既存取引の有無）と、割り当て後に通知が飛ぶ仕組みまで含めて設計します。落とし穴はツール間の接続部分にあり、MAツール側でリードの担当者を判定しても、CRMのレコード所有者が切り替わらなければ営業の画面には現れません。割り当て条件の判定と、CRM側の所有者変更までを一続きで同期させます（マーケティングオートメーション（MA）とは？その定義と基本的な考え方）。

もう一つ必要なのが、SQLにならなかったリードを育成へ戻す経路です。時期が合わなかっただけのリードを営業が失注扱いで閉じてしまうと、獲得にかけた費用がそこで消えます。差し戻し理由が定義上の不一致や時期尚早であればナーチャリングの対象に戻し、次の検討期に再度立ち上がる経路を残してください。育成側で何が得られるかはリードナーチャリングによって得られる具体的なメリットとはにまとめています。

SQL件数の単独KPI化で起きる劣化と併読指標

SQLを営業のKPIに置くと、件数は簡単に増やせます。判定条件を緩めればよいからです。BANTのうち必須条件を減らす、初回接触前にSQLとみなす、といった変更で数字は動きますが、商談化率と受注率は同時に下がります。件数を単独で追う限り、この劣化は指標に現れません。

そのため、SQL件数は必ずSQLから商談化した率、商談から受注した率と並べて見ます。件数が増えて商談化率が下がっているなら、判定が緩んだサインです。逆に商談化率が高いまま件数が伸びないなら、判定が厳しすぎて営業が確実な案件しか受理していない可能性があります。

マーケティング側にも同じ罠があります。MQL数だけを目標にすると、獲得単価の安いリードを集める方向に力が向き、営業が受理しないMQLが積み上がる。1件あたりの獲得費用の見方はコストパーエムキューエル（CPMQL）とは何かをわかりやすく解説を参照してください。部門をまたぐ指標設計としては、マーケティングはSALの受理率、営業は対応期限の遵守率を互いの評価に入れると、数合わせの動機が消えます。

よくある質問

SQLは何の略で、どう読みますか

マーケティング文脈ではSales Qualified Leadの略で、「エスキューエル」と読みます。データベース言語のSQL（Structured Query Language）と綴りも読みも同じで、文脈でしか判別できません。

MQLとは何の略ですか

Marketing Qualified Leadの略で、SQLの一つ手前の段階です。判定基準の作り方はMQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順で扱っています。

TQLやSGLとは何ですか

どちらもデマンドウォーターフォールで使われるリードの呼称です。TQLはTeleprospecting Qualified Leadで、インサイドセールスがテレプロスペクティング（電話中心の接触）で確度を確認したリードを指します。SGLはSales Generated Leadで、マーケティング経由ではなく営業自身が発掘したリードです。MQLを経由しないため、マーケティング起点のリードとは別系統で集計します。

SQLの定義はマーケティングと営業のどちらが決めるのですか

片方では決められません。判定するのは営業ですが、その要件を満たすリードを供給するのはマーケティングです。片側だけで決めた定義は、渡す側と受け取る側で期待がずれます。両部門が合意した取り決めとして文書化し、受注実績を見て見直す形が現実的です。

却下（リジェクト）と失格（ディスクオリファイ）は何が違うのですか

判断の時点が違います。却下は営業が見込み客に接触する前の判断で、ルーティングの誤り・レコードの不備・定義上の不一致を理由にリードを受理しないことを指します。失格は営業が接触したうえで、関心・課題・予算が無いと確認した後の判断です。両者を同じ扱いにすると、引き渡し運用の問題と見込み客側の事情が混ざり、どちらの改善もできません。

関連記事

• MQLとSQLの違いを徹底解説：ビジネスでの重要性とは
• MQLの判定基準とは？属性・行動スコアで決めるリード選定の基準と設計手順
• リードスコアリングとは？その基本的な概要と役割について
• リードナーチャリングによって得られる具体的なメリットとは
• マーケティングオートメーション（MA）とは？その定義と基本的な考え方