SQL(営業判定リード)とは?8年運用してわかった『成約見込み確定リードの正体』と運用の正解

「SQL(営業判定リード)」って、なんとなく「営業がフォローするリード」だと思ってませんか?

株式会社Cameen 西村温裕ことおんゆーです。

で、BtoB営業の話題で「SQLにしてから本格営業」と。いやちょっと待ってください。MQLとSQLの境界どこですか?

なんとなくのイメージはあると思います。営業が温度高いと判断したやつでしょう?と。でも「で、何をもって温度高いって判断するんですか?」と聞かれると、意外と詰まる。

これ、自分だけだと思ってませんか?BtoB営業担当の方と話すと「SQL設定してるけど、結局成約しないリードまでSQLにしてる」と。話を深掘りしていくと、ほぼ全員が「営業が温情判定」してるんですよね。

うちの事業で自社+クライアント案件含め100本超のBtoB案件管理を見てきて、SQL基準が曖昧で予測精度が落ちるパターンを本当に何度も見てきたんです。

SQLの核心は「営業フォロー」ではない

なぜ「SQL」なのか

1つ目は売上予測精度。SQL数×成約率で受注予測の精度が大きく上がる。

2つ目は営業リソース最適化。確度低い案件にリソース取られない。

3つ目はマーケへのフィードバック。SQL/MQL転換率でマーケの質を測れる。

各段階で『営業の頭の中』で何が起きているか

段階1: MQL受領

「マーケから来たリード、フォローしよう」

段階2: BANT確認

予算・決裁権・ニーズ・時期の対話。

段階3: SQL判定

「4要素揃った、SQL確定」

段階4: 提案・クロージング

正式提案・見積・契約。

段階5: 成約 or 失注

結果反映でSQL基準を継続改善。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

例えば、レストランの予約を思い浮かべてください。「予約申し込み(MQL)」と「来店・着席(SQL)」は違う。予約しても来ない人はいる。実際に座って注文する人がSQL。SQL数×注文単価で売上予測できる。

これ、まんまSQLなんです。

「ここまで来た人は確度高い」が定義できれば、事業予測精度が桁違いに上がります。

SQLの正解は『成約見込みで判定』

機能しない典型パターン3つ

うちの自社+クライアント案件100本超で運用してわかった本音

本音1: チェックリスト化が9割。営業全員が同じBANT項目で判定する仕組みが命。

本音2: SQL→成約率25%が健全。それ以下なら基準ゆるすぎ。50%以上なら基準厳しすぎでチャンスロス。

うちでクライアントBtoB営業を支援した時、最初はSQLが営業の感覚判定でバラバラだった。180度方針転換して「BANTチェックリスト+CRM必須記録」したら、売上予測精度が体感3倍、営業生産性も向上したんですよね。

今日から使える設計ステップ5つ

よくある質問(FAQ)

MQLとの違いは?

MQL=マーケ判定、SQL=営業対話後の判定。BANT確認済みかどうかが境界。

SQL成約率の目安は?

20-30%が健全。それ以下ならSQL基準が緩すぎ。

SAL(営業承諾リード)とは?

MQLとSQLの間。「営業がフォローを始めた段階」。BANT確認はまだ。

小規模事業でも分ける?

営業2人以上なら分けるべき。1人体制なら手動管理でOK。

いつ初回コンタクト?

MQL化から5分以内が黄金。1時間超えると成約率半減。

業界平均

項目	水準
SQL成約率	20-30%
初回コンタクト遅延の影響	1時間超で成約率-50%

まとめ

で、結局SQLとは、こういうことです。

1. 正体は「営業フォロー」ではなく「成約見込み確定リード」
2. BANT等の客観基準で判定
3. 成約率20-30%・マーケと月次連動

ではでは。