SQL基準の作り方｜営業が受け入れるリード条件の設計手順
SQL（営業が受け入れるリード）の基準をどう定義し、営業と合意し、運用で見直すか。定義の粒度、判定項目、差し戻しルール、レビューの回し方を表とチェックリストで整理した実務手順の解説です。
公開 2026年9月26日
結論：SQLの基準は「営業が差し戻せる条件」まで書いて初めて機能する
SQLの基準づくりで最初に決めるのは、受け入れる条件ではなく差し戻せる条件です。受け入れ条件だけを列挙した基準は、判断が担当者の感覚に委ねられ、結局「使われないリード」が積み上がります。
基準の設計は3段階で進めます。①属性と状況の必須項目を決める、②各項目の判定根拠（誰が、何を見て判断するか）を決める、③差し戻し理由を有限のリストにする。この3つが揃うと、マーケと営業の会話が「多い・少ない」から「どの条件が満たされていないか」に変わります。
SQLは一度決めて終わりではありません。プロダクトの提供価値やターゲットが変われば、基準も変わります。四半期ごとの見直しをあらかじめ運用に組み込んでおきます。
※本記事は2026年9月時点の情報をもとに作成しています。
SQLとは：MQLとの違いを「誰の判断か」で分ける
SQLとは、営業が商談化の対象として受け入れたリードを指します。Sales Qualified Leadの略で、マーケティング側の基準で選別されたMQL（Marketing Qualified Lead）を、営業側の基準で再評価した結果として生まれます。
違いは判断の主体です。MQLはマーケが行動データと属性から判定します。SQLは営業が会話や追加情報を踏まえて判定します。同じリードでも、判断する立場が違えば結論が変わるのは自然なことです。
ここで混乱しやすいのが、SALとSQLの区別です。SAL（Sales Accepted Lead）は「営業が受け取ることに同意した」段階、SQLは「商談として追う価値があると判断した」段階を指す使い分けが一般的です。両者を分けるか一段階にまとめるかは組織の規模次第で構いませんが、社内で呼び方を一つに揃えることが前提になります。
定義する範囲
- 対象となる企業の条件（業種・規模・地域など）
- 対象となる人物の条件（役割・関与度）
- 状況の条件（課題の有無、検討時期、予算の所在）
- 除外条件（競合、学生、既存顧客の別部門など）
判定項目の設計：4カテゴリに分けて必須と任意を決める
判定項目は、企業属性・人物属性・課題状況・タイミングの4カテゴリに分けると抜けが減ります。すべてを必須にすると通過するリードが極端に絞られるため、必須と任意を分けます。
以下は項目カテゴリごとの設計の考え方です。
| カテゴリ | 代表的な項目 | 必須にする基準 | 判定根拠の取り方 |
|---|---|---|---|
| 企業属性 | 業種、従業員規模、拠点 | プロダクトが構造的に合わない場合は必須 | フォーム入力、企業データベース照合 |
| 人物属性 | 役割、関与の立場 | 決裁や推進に関わらない場合は要注意 | フォーム入力、会話ログ |
| 課題状況 | 解決したい業務課題、現行の手段 | 課題が言語化されていない場合は任意 | ヒアリング、資料閲覧の文脈 |
| タイミング | 検討開始時期、社内の動き | 時期未定でも除外しない設計が無難 | 会話、問い合わせ内容 |
企業属性は自動判定しやすく、課題状況は自動判定しにくい項目です。この非対称を理解せずに「課題が明確なリードだけをSQLにする」と決めると、判定が属人化します。
必須項目は多くても4〜5個にとどめます。必須を増やすほど基準は厳密になりますが、フォーム項目の追加で入力の負荷が上がり、そもそも情報が集まらなくなります。
差し戻しルール：理由コードを有限にする
差し戻しの理由は、自由記述ではなくコード化します。自由記述にすると集計できず、基準の改善に使えないためです。
理由コードは、マーケ側が対処できる分類で設計します。「対象外」の一語で片づけず、何が対象外なのかまで分けます。
| 理由コード | 内容 | 次のアクション |
|---|---|---|
| 属性不一致 | 企業規模・業種が対象外 | ターゲティング条件の見直し |
| 関与不足 | 情報収集のみで推進の意思がない | ナーチャリングへ戻す |
| 時期不一致 | 検討時期が先 | 再アプローチ日を設定して戻す |
| 情報不足 | 判断に必要な項目が欠けている | 追加ヒアリングの設計を見直す |
| 重複・既存 | 既存商談や既存顧客と重複 | 名寄せルールの修正 |
重要なのは、「ナーチャリングへ戻す」の行き先を具体化しておくことです。戻し先が決まっていない差し戻しは、実質的な破棄になります。
差し戻し期限も決めます。営業が一定日数以内に判定しない場合は自動でSQLとみなすのか、マーケに戻すのか。どちらでも構いませんが、決めておかないと滞留します。この期限設計はMQLから営業への引き継ぎSLAの考え方と一体で整理します。
合意形成の手順：3回のミーティングで決め切る
基準は会議で決めますが、長引かせないために回数を先に区切ります。
1回目：現状の棚卸し 直近に営業へ渡したリードを一定数サンプリングし、営業に「受けた／受けなかった」とその理由を口頭で説明してもらいます。このとき基準の話はしません。事実だけを集めます。
2回目：項目の仮決め 1回目で出た理由を分類し、必須項目と任意項目の案を作ります。営業には「この条件で落とすと、今の何割が落ちるか」を数字ではなく感触で確認します。合意の対象は項目であって、件数の見込みではありません。
3回目：運用ルールの確定 判定期限、理由コード、レビューの頻度、基準を変えるときの手続きを決めます。ここまで決めて文書にし、双方の責任者が承認します。
合意時のチェックリスト
- 必須項目が5個以内に収まっているか
- 各項目に判定根拠（誰が何を見るか）が書かれているか
- 差し戻し理由が有限のリストになっているか
- 差し戻し後の行き先が定義されているか
- 判定期限と、期限超過時の扱いが決まっているか
- 基準の見直し時期と手続きが書かれているか
運用後のレビューで見る3点
基準は運用しながら調整します。確認するのは、①理由コードの分布に偏りがあるか、②同じ理由コードが繰り返し出ていないか、③判定期限を超えるリードが増えていないか、の3点です。
「属性不一致」に偏る場合は、獲得チャネルかターゲティング条件の問題です。基準ではなく入口を直します。「情報不足」に偏る場合は、引き継ぎ時の情報設計の問題です。判定期限の超過が増えているときは、営業側のキャパシティの問題かもしれず、渡す量の調整を先に検討します。
レビューは月次で数字の確認だけ、四半期で項目そのものの見直し、という二段構えが扱いやすい形です。
よくある失敗のパターン
基準づくりでつまずく形は、いくつかの型に分かれます。
スコアだけで決めてしまう スコアリングは便利ですが、点数の内訳が見えないと営業は納得しません。スコアは優先順位づけに使い、SQLの判定条件は項目で書きます。
マーケだけで作って通達する 営業が判定プロセスに関わっていない基準は、現場で無視されます。作成の段階から営業を巻き込むのが前提です。
基準を厳しくしてリードが枯れる 差し戻しが多いと、基準を厳しくする方向に流れがちです。しかし厳しくすれば、渡る件数は減ります。厳しくする前に、獲得チャネルの構成を見直します。
差し戻し理由が「見込みなし」で統一される 理由が集計できず、改善の手がかりが残りません。理由コードを選択式にし、自由記述は補足に限定します。
一度決めて更新されない プロダクトやターゲットが変わっても基準が残り、実態とずれていきます。見直し時期を運用ルールに含めます。
判定結果がマーケに戻ってこない 営業が判定してもマーケに共有されなければ、改善のループが閉じません。戻す経路をツール上で確保します。
この進め方が向いていないケース
SQL基準の厳密な設計が適さない状況もあります。無理に導入すると運用負荷だけが残ります。
リードの絶対数が少ない場合 月あたりの流入が限られる段階では、全件を営業が見たほうが早く、基準による選別のコストが上回ります。
営業チームが少人数で、担当が固定されている場合 判断が一人か二人に集中しているなら、文書化された基準より日々の会話のほうが速く機能します。
プロダクトのターゲットが探索中の場合 誰に売るかが定まっていない段階で基準を固めると、探索の幅を自ら狭めます。この段階では基準を作らず、受注・失注の傾向を記録することを優先します。
トップダウンで案件を作る営業モデルの場合 アウトバウンド主体で、マーケからの引き継ぎが商談の主経路でないなら、SQL基準の優先度は下がります。
組織変更の直前 体制が変わると判定主体も変わります。落ち着いてから着手するほうが手戻りが少なくなります。
よくある質問
MQLとSQLの基準は同じ項目で作るべきですか。
項目は重なっても構いませんが、判定主体と判定タイミングは分けて書きます。MQLは行動データ中心、SQLは会話で得た情報を含む、という違いを明示しておくと運用が安定します。
基準を満たさないリードはどう扱いますか。
差し戻し理由ごとに行き先を決めます。時期不一致なら再アプローチ日を設定して戻す、情報不足なら追加のヒアリング導線に乗せる、といった形です。行き先のない差し戻しは破棄と同義になります。
営業が基準を守らない場合はどうしますか。
守られない基準は、多くの場合、実務に合っていません。守らせる前に、どの項目で判断が食い違うのかを個別に聞き取ります。そのうえで項目を減らすか、判定根拠の取り方を変えます。
スコアリングは不要ですか。
不要ではありません。優先順位づけには有効です。ただしSQLの合否判定をスコアの閾値だけに委ねると、営業から見て判断の根拠が見えなくなります。
基準はどのくらいの頻度で見直しますか。
月次で理由コードの分布を確認し、四半期で項目そのものを見直す形が扱いやすいと考えられます。プロダクトやターゲットの変更があった場合は、時期に関わらず見直します。
まとめ
SQLの基準は、受け入れ条件と差し戻し条件をセットで書いて初めて運用に耐えます。判定項目は企業属性・人物属性・課題状況・タイミングの4カテゴリに分け、必須は絞り込みます。差し戻し理由は有限のコードにし、それぞれに行き先を定義します。
合意形成は3回のミーティングで区切り、文書化して責任者が承認します。運用後は理由コードの分布を見ながら、入口を直すのか基準を直すのかを切り分けます。
関連する設計として、引き継ぎ時の情報の持たせ方や、獲得段階での情報取得の設計もあわせて整理すると全体が噛み合います。BtoB LPのCVRが頭打ちになるときやナレッジ記事の一覧も参考にしてください。
なお、UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、そのやり取りの文脈を付けて担当者へ引き継ぐAIです。