SQLの基準はどう決める？商談化につながる見極め方

リードは取れている。
資料ダウンロードもある。
セミナー参加者も増えている。
問い合わせもゼロではない。

それなのに、なぜか商談が増えない。

BtoBマーケティングをやっていると、この悩みにかなりの確率でぶつかります。

マーケティング側としては、頑張ってリードを集めている。
広告も出している。
ホワイトペーパーも作っている。
ウェビナーも開催している。
MAやCRMにもデータを入れている。

でも営業からは、こんなことを言われることがあります。

「このリード、温度感が低いですね」
「資料を落としただけで、まだ商談にはならないです」
「この会社はターゲット外じゃないですか」
「追っても全然つながらないです」
「結局、商談にならないリードが多いです」

こう言われると、マーケティング担当者としては正直つらいです。

こちらとしては、リードを増やすためにかなり動いている。
なのに、営業からは評価されない。
MQL数は増えているのに、商談数は増えない。
レポート上は良く見えるのに、現場の手応えがない。

こういう状態になると、だんだん何を基準にリードを営業へ渡せばいいのかわからなくなります。

「資料請求したらSQLでいいのか」
「スコアが一定以上なら営業に渡していいのか」
「問い合わせだけをSQLにすべきなのか」
「営業が追いたいリードの条件は、どこまで聞けばいいのか」
「SQLの基準はどう決めれば、商談化につながるのか」

このあたりで迷う会社は多いと思います。

私自身も、広告代理店でプランナーをしていた時、BtoCの会社でマーケターをしていた時、そして今のように大手町の企業でBtoBマーケターとして仕事をしている中で、リードの質と営業連携には何度も悩んできました。

特にBtoBでは、リード数だけを増やしても成果にはつながりません。

大事なのは、営業が本当に動くべきリードを見極めることです。

結論から言うと、SQLの基準は、マーケティング側だけで決めてはいけません。
また、スコアリングの点数だけで決めても危険です。
資料ダウンロードやページ閲覧だけを見て決めるのも不十分です。

SQLの基準は、次のような情報を組み合わせて考える必要があります。

・ターゲット企業に合っているか
・担当者の部署や役職が検討に関係しているか
・課題やニーズが具体的に見えているか
・導入時期や検討タイミングがあるか
・予算感や投資余力がありそうか
・料金ページや導入事例など、検討度の高い行動があるか
・営業が追った時に、商談化する可能性があるか
・過去の受注リードと似た特徴があるか

つまり、SQLは「興味がありそうな人」ではありません。
SQLは、営業が今動くべき理由があるリードです。

ここを間違えると、マーケティングと営業の関係が悪くなります。

マーケティングは「リードを渡しているのに追ってくれない」と感じます。
営業は「商談にならないリードばかり渡される」と感じます。
その結果、MQLやSQLという言葉だけが残り、実際の運用はうまく回らなくなります。

この記事では、SQLの基準の決め方を、できるだけ実務に近い形で整理していきます。

具体的には、次の流れで見ていきます。

・SQLとは何か
・MQLとSQLの違い
・SQL基準が曖昧だと何が起きるのか
・SQL基準を決める前に整理すべきこと
・SQL基準に入れるべき項目
・行動データの見方
・営業とマーケティングで合意する方法
・よくある失敗
・改善のために見るべき指標
・運用に落とし込む方法
・見直すタイミング
・実践チェックリスト

この記事を読むと、SQLの基準の決め方がかなり具体的になります。

単に「スコアが高い人を営業に渡す」ではなく、商談化につながるリードをどう見極めるかがわかります。
営業から「このリードは追う意味がありますね」と言われる基準を作りやすくなります。
マーケティング施策の評価も、リード数だけではなく、商談や受注につながる形で見られるようになります。

SQLの基準は、一度作れば終わりではありません。
運用しながら、営業の声とデータを見て改善していくものです。

最初から完璧な基準を作ろうとしなくて大丈夫です。
ただし、曖昧なまま運用し続けるのは危険です。

まずは、自社にとっての「営業が動くべきリード」とは何か。
そこから一緒に整理していきましょう。

SQLの基準を決める前に理解しておきたい基本

SQLの基準を決める前に、まず言葉の意味をそろえておく必要があります。

なぜなら、同じSQLという言葉を使っていても、人によってイメージが違うことがあるからです。

マーケティング担当者は「一定以上の反応があるリード」と考えている。
営業は「今すぐ商談になりそうなリード」と考えている。
経営層は「売上につながる見込みが高いリード」と見ている。

この状態でSQLの基準を決めようとすると、必ずズレます。

まずは、SQLとは何か。
MQLとどう違うのか。
誰が決めるべきなのか。

この基本をそろえることが、SQL基準づくりの出発点です。

SQLとは営業が対応すべき確度の高いリードのこと

SQLとは、営業が対応すべき確度の高いリードのことです。

もう少しわかりやすく言うと、マーケティング活動などで獲得したリードの中から、営業が具体的にアプローチする価値があると判断された相手です。

資料をダウンロードしただけの人。
セミナーに参加しただけの人。
メールを開封しただけの人。

これらは、すべてSQLとは限りません。

もちろん、そうした行動は興味のサインではあります。
でも、営業がすぐ動くべきかどうかは別の話です。

たとえば、学生が資料をダウンロードしているかもしれません。
競合企業の担当者が情報収集しているかもしれません。
ターゲット外の小規模企業が興味本位で資料を見ているかもしれません。
導入予定がまったくない人が、勉強目的でウェビナーに参加しているだけかもしれません。

このようなリードをすべて営業に渡すと、営業の工数が足りなくなります。
そして、営業から「マーケティングリードは追っても意味がない」と思われやすくなります。

SQLは、単に行動した人ではありません。
営業が動く理由がある人です。

だから、SQLの基準を決める時は、興味の強さだけでなく、営業対応の優先度を考える必要があります。

・自社のターゲットに合っているか
・課題が見えているか
・検討タイミングがあるか
・営業が接点を作れる相手か
・商談化する可能性があるか

このような条件を見ながら、SQLとして渡すべきかを判断します。

SQLの基準を決めるということは、営業に渡すリードの線引きを決めることです。
この線引きが曖昧だと、営業とマーケティングの連携はかなり不安定になります。

MQLとSQLの違いを曖昧にすると商談化率が下がる

MQLとSQLの違いが曖昧なままだと、商談化率は下がりやすくなります。

MQLは、マーケティング活動の中で一定の興味や見込みがあると判断されたリードです。
たとえば、資料をダウンロードした、ウェビナーに参加した、メールを何度もクリックした、サイトを複数回訪問したなどです。

一方でSQLは、営業が対応すべきリードです。

この2つは似ていますが、役割が違います。

MQLは、マーケティング側が「この人は見込みがありそう」と判断した状態です。
SQLは、営業側も含めて「この人は商談に向けて動く価値がある」と判断した状態です。

ここを曖昧にすると、マーケティングはMQLを増やすことに集中します。
そして、MQLをそのまま営業へ渡してしまいます。

しかし営業から見ると、その中にはまだ追うには早いリードも含まれています。
課題が浅い。
導入時期が見えない。
部署や役職が違う。
ターゲット企業ではない。
ただ情報収集しているだけ。

こうしたリードが増えると、商談化率は下がります。

すると営業は、マーケティングから来たリードを信頼しなくなります。
結果として、せっかく良いリードが混ざっていても、追われにくくなります。

MQLとSQLを分ける目的は、営業を厳しく管理するためではありません。
マーケティングと営業が、同じ基準で見込み客を見られるようにするためです。

MQLは興味のサイン。
SQLは営業が動くべきサイン。

この違いをはっきりさせるだけでも、SQL基準の決め方はかなり整理しやすくなります。

SQLの基準はマーケティングだけで決めてはいけない

SQLの基準は、マーケティングだけで決めてはいけません。

これはかなり大事です。

マーケティング側だけで基準を作ると、どうしても行動データに寄りやすくなります。
資料を何回ダウンロードしたか。
メールを何回開封したか。
料金ページを見たか。
ウェビナーに参加したか。

もちろん、これらは重要です。
ただ、営業が実際に話した時に商談になるかどうかは、行動データだけではわかりません。

営業は、顧客の温度感を直接見ています。
どんな課題なら商談になりやすいか。
どんな役職なら話が進みやすいか。
どんな会社規模なら受注につながりやすいか。
どんな問い合わせ内容は冷やかしに近いか。

この感覚は、SQL基準に必ず入れた方がいいです。

一方で、営業の肌感だけで決めるのも危険です。
営業が追いやすいリードだけをSQLにすると、新しい市場や中長期の見込み客を見落とすことがあります。
また、声の大きい営業担当者の意見だけが基準になってしまうこともあります。

だから、SQL基準は営業とマーケティングで一緒に作る必要があります。

・マーケティングは行動データや獲得背景を見る
・営業は商談化しやすい条件や現場感を見る
・両者で受注実績を確認する
・合意した基準を運用しながら見直す

この流れが理想です。

SQL基準は、マーケティングが営業にリードを押しつけるためのものではありません。
営業が動きやすくなり、マーケティング施策の質も高めるための共通ルールです。

商談化につながるSQLは「興味がある人」ではなく「営業が動くべき人」

商談化につながるSQLを考える時、一番大事なのは「興味がある人」と「営業が動くべき人」を分けることです。

興味がある人はたくさんいます。
資料を読む人。
セミナーを見る人。
メルマガをクリックする人。
サイトを何度も訪問する人。

でも、その全員が営業対応すべき人とは限りません。

営業が動くべき人には、もう少し具体的な理由があります。

・ターゲット企業に合っている
・課題が明確になっている
・導入検討に関わる立場である
・比較や検討の動きが見える
・一定の予算や導入余地がある
・営業が話すことで前に進む可能性がある

このような条件があるリードは、SQLとして扱う価値があります。

逆に、興味はあっても、まだ営業が動くには早いリードもあります。
その場合は、無理にSQL化するより、ナーチャリングした方がいいです。
メール、セミナー、事例、比較資料などを通じて、検討度を高めていく方が自然です。

ここを混ぜると、営業もマーケティングも苦しくなります。

営業は、まだ早い人を追わされます。
マーケティングは、渡したリードが商談にならず評価されません。
リード側も、まだ相談する気がないのに営業から連絡が来て、少し嫌な気持ちになるかもしれません。

SQLは、興味の有無だけで決めるものではありません。

営業が今動くことで、商談化する可能性が高まるか。

この視点で見ると、SQLの基準は実務に近づきます。

SQLの基準が曖昧なまま運用されると起きる問題

SQLの基準が曖昧なままでも、最初はなんとなく運用できてしまいます。

資料請求があったら営業に渡す。
スコアが高くなったら営業に通知する。
問い合わせがあれば優先対応する。
営業が気になったものだけ追う。

このように、なんとなく回ることはあります。

ただ、リード数が増えたり、営業人数が増えたり、施策が増えたりすると、曖昧さは必ず問題になります。

営業に渡すリードの質が安定しない

SQLの基準が曖昧だと、営業に渡すリードの質が安定しません。

ある日は、確度の高い問い合わせが渡される。
別の日は、資料を見ただけの温度感が低いリードが渡される。
担当者によって、SQLにする判断が違う。
キャンペーンによって、基準が変わる。

こうなると、営業はマーケティングリードを信頼しにくくなります。

営業からすると、毎回リードの質が違うのはかなり負担です。
どれを優先すればいいのかわからない。
追っても商談にならないことが続く。
結果として、後回しにされます。

マーケティング側は「せっかく渡しているのに追ってくれない」と感じます。
でも営業側からすると「追うべきかどうか判断できないリードが多い」と感じています。

このズレをなくすには、SQL基準を明確にする必要があります。

・どんな条件ならSQLにするのか
・どんな条件ならまだナーチャリングするのか
・営業に渡す時に何を添えるのか
・優先度をどう分けるのか

このあたりを決めるだけで、営業の受け取り方は変わります。

SQLの基準は、営業に渡すリードの品質管理のようなものです。
毎回品質がバラバラだと、営業は安心して動けません。

営業がマーケティングリードを追わなくなる

SQL基準が曖昧なまま運用されると、営業がマーケティングリードを追わなくなることがあります。

これは、かなり危険な状態です。

一度「マーケティングから来るリードは質が低い」と思われると、信頼を戻すのに時間がかかります。
たとえ良いリードが混ざっていても、優先順位を下げられてしまいます。

営業には、日々やることがたくさんあります。
既存顧客対応。
提案準備。
商談。
見積もり作成。
社内調整。
受注後のフォロー。

その中で、確度がわからないリードを丁寧に追うのは簡単ではありません。

だからこそ、マーケティングから渡すSQLには、営業が動く理由が必要です。

・この会社はターゲットに合っています
・料金ページを複数回見ています
・導入事例を閲覧しています
・問い合わせ内容に具体的な課題があります
・過去の受注企業と似た特徴があります

こうした情報があると、営業は動きやすくなります。

逆に、ただ「スコアが高いです」「資料をダウンロードしました」だけだと、優先されにくいです。

SQL基準は、営業を動かすための共通言語でもあります。
営業が納得できる基準にしないと、SQLは名前だけのものになります。

MQL数は増えているのに商談数が増えない

SQL基準が曖昧な会社では、MQL数は増えているのに商談数が増えないことがあります。

マーケティング施策としては、一見うまくいっているように見えます。

リード数が増えた。
資料ダウンロード数が増えた。
ウェビナー参加者が増えた。
MQL数も増えた。

でも、商談数が増えない。
受注も増えない。

この状態は、リード獲得と営業成果の間にズレがあるということです。

原因はいくつか考えられます。

・ターゲット外のリードが多い
・情報収集だけの人が多い
・営業に渡すタイミングが早すぎる
・CTAが軽すぎて温度感が低い
・営業が必要な情報を受け取れていない
・SQL基準が商談化ではなく行動量だけで決まっている

MQL数が増えること自体は悪いことではありません。
ただ、商談につながらないMQLばかり増えると、マーケティングの評価が難しくなります。

本来、BtoBマーケティングはリード数だけを増やす仕事ではありません。
営業が商談を作りやすくなる状態を作ることが大事です。

そのためには、MQLからSQLへの基準を見直す必要があります。

どのMQLを営業に渡すのか。
どのMQLは育成を続けるのか。
どの条件なら商談化しやすいのか。

ここを整理しないと、リード数は増えても成果につながりにくくなります。

受注につながらないリード対応に営業工数が奪われる

SQL基準が甘すぎると、営業の工数が受注につながらないリード対応に奪われます。

これは、現場ではかなり大きな問題です。

営業が一件のリードを追うには時間がかかります。
電話する。
メールする。
過去の接点を見る。
会社情報を調べる。
必要なら商談設定を試みる。

これを何十件も対応するとなると、かなりの工数です。

もしその多くがターゲット外だったり、検討タイミングがなかったり、課題が浅かったりすると、営業の時間がもったいないです。

本来なら、もっと確度の高い見込み客に使えた時間です。
既存商談の提案精度を上げる時間に使えたかもしれません。
受注に近い顧客へのフォローに使えたかもしれません。

SQL基準は、営業の時間を守るためにも重要です。

営業工数は無限ではありません。
だからこそ、営業が動くべきリードを見極める必要があります。

マーケティング側としても、営業に負担をかけるだけのリードを渡し続けると、信頼を失います。
営業が追いやすく、成果につながりやすいリードを渡すことが、長期的にはマーケティングの評価にもつながります。

SQL基準は、リードを増やすためではなく、営業の時間を成果につなげるためにあります。

マーケティング施策の評価がリード数だけに偏る

SQL基準が曖昧だと、マーケティング施策の評価がリード数だけに偏りやすくなります。

リード数が多い施策が良い。
資料ダウンロード数が多い施策が良い。
獲得単価が安い施策が良い。

一見、わかりやすい評価です。

でも、BtoBではリード数だけで施策を評価すると危険です。

たくさんリードが取れても、ターゲット外が多ければ意味が薄いです。
獲得単価が安くても、商談化しなければ成果にはつながりません。
資料ダウンロード数が多くても、営業が追うべき人でなければ売上にはなりにくいです。

マーケティング施策は、リード数だけではなく、その後の質まで見る必要があります。

・SQL化率
・商談化率
・受注率
・受注単価
・営業の評価
・商談までの期間

このような指標まで見ると、本当に成果につながる施策が見えてきます。

SQL基準が明確になると、マーケティング施策の評価も変わります。
単にリードを集める施策ではなく、商談につながるリードを生む施策を評価できるようになります。

これは、マーケティング担当者にとっても大事です。

リード数だけで評価されると、どうしても数を追いたくなります。
でもSQL基準があると、質も含めて施策を改善できます。

SQLの基準を決める時に最初に整理すべきこと

SQL基準を作る時、いきなり項目を決めようとすると失敗しやすいです。

企業規模をどうするか。
役職をどう見るか。
スコアは何点以上にするか。
料金ページを見たら加点するか。

こうした項目はもちろん大事です。

ただ、その前に整理すべきことがあります。

それは、自社にとって商談化しやすいリードとは何か。
さらに、受注につながりやすい商談とは何かです。

ここを見ずに基準を作ると、形だけのSQL基準になります。

自社にとっての「良い商談」を定義する

まずは、自社にとっての良い商談を定義することが大切です。

良いリードを考える前に、良い商談を考えます。

なぜなら、SQLの目的は商談化だからです。
さらに言えば、受注につながる商談を増やすことだからです。

良い商談とは、単にアポイントが取れた商談ではありません。

たとえば、次のような商談は良い商談と言いやすいです。

・自社のターゲット企業である
・相手に明確な課題がある
・検討に関わる担当者が参加している
・導入時期がある程度見えている
・予算や投資の余地がある
・競合比較や社内検討が進んでいる
・提案後に次のアクションが決まりやすい

逆に、アポイントは取れても、ターゲット外で、課題も曖昧で、導入時期もなく、情報収集だけなら、商談としての優先度は下がります。

もちろん、すぐ受注しない商談にも意味はあります。
将来の見込み客になることもあります。
ただ、SQL基準を作る時は、まず営業が優先して動くべき商談像を明確にする必要があります。

自社にとっての良い商談が曖昧だと、良いSQLも決まりません。

営業とマーケティングで、まず次の問いを話すとよいです。

・どんな商談は受注につながりやすいか
・どんな商談は途中で止まりやすいか
・どんな企業は導入後も相性が良いか
・どんな課題なら自社が強く解決できるか

ここを言語化することが、SQL基準づくりの土台になります。

受注につながったリードの共通点を洗い出す

SQL基準を作る時は、過去に受注したリードの共通点を見ることが重要です。

感覚で「こういうリードが良さそう」と決めるより、実際に受注したリードを見る方が精度が上がります。

見るべきポイントはいくつかあります。

・どの業種が多いか
・どの企業規模が多いか
・どの部署から問い合わせが来ているか
・どの役職が商談に参加しているか
・最初に見たコンテンツは何か
・資料ダウンロードから商談までの期間はどれくらいか
・導入前にどんな課題を話していたか
・どのチャネルから獲得したリードか

こうした情報を並べると、受注につながりやすいパターンが見えてきます。

たとえば、資料ダウンロードだけでは弱いけれど、料金ページを見た後に問い合わせたリードは商談化しやすいかもしれません。
ウェビナー参加者の中でも、参加後に事例ページを見ている人は温度感が高いかもしれません。
大企業よりも、中堅企業の特定部署の方が受注率が高いかもしれません。

こうした発見は、SQL基準に反映できます。

大事なのは、受注リードを一件ずつ見ることです。
数字だけで集計するのも大事ですが、実際の商談メモや営業のコメントを見ると、より具体的なヒントがあります。

私も実務では、受注した案件の入り口を振り返ることがかなり大事だと感じます。
どの施策がきっかけだったのか。
最初の課題は何だったのか。
どのタイミングで営業につながったのか。

ここを見ると、SQL基準はかなり現実的になります。

失注や未商談化リードの特徴も確認する

SQL基準を作る時は、受注リードだけでなく、失注や未商談化リードも見た方がいいです。

なぜなら、避けるべき条件が見えてくるからです。

受注リードだけを見ると、良い条件は見えます。
でも、なぜ商談にならなかったのか、なぜ失注したのかを見ないと、SQL基準が甘くなることがあります。

たとえば、次のような特徴があるかもしれません。

・ターゲット外の業種だった
・部署が検討に関係していなかった
・予算がまったくなかった
・導入時期が未定だった
・問い合わせ内容が抽象的だった
・競合調査だけだった
・学生や個人の情報収集だった
・営業が連絡しても反応がなかった

こうした特徴が多いなら、SQL基準に除外条件や注意条件を入れるべきです。

特にBtoBでは、見た目だけ良さそうなリードがあります。
大企業名が入っている。
有名企業から資料請求がある。
役職名が高い。
ページ閲覧数が多い。

でも、実際には商談にならないこともあります。

だからこそ、失注や未商談化リードを見ることが大事です。

うまくいかなかったリードを責めるためではありません。
次に営業へ渡す基準をよくするためです。

受注リードは、増やすべき条件を教えてくれます。
失注リードは、気をつけるべき条件を教えてくれます。

両方を見ることで、SQL基準は強くなります。

営業が本当に追いたいリード条件を言語化する

SQL基準を作る時は、営業が本当に追いたいリード条件を言語化する必要があります。

営業に「どんなリードが欲しいですか」と聞くと、最初はふわっとした答えが返ってくることがあります。

「温度感が高いリードがいいです」
「決裁者に近い人がいいです」
「ちゃんと検討している人がいいです」
「ターゲットに合う会社がいいです」

どれも正しいです。
ただ、このままだと基準には落とし込めません。

さらに具体化する必要があります。

温度感が高いとは、どんな行動がある状態なのか。
決裁者に近いとは、どの部署や役職なのか。
検討しているとは、導入時期や予算の話がある状態なのか。
ターゲットに合うとは、業種、規模、課題のどれを見るのか。

ここまで聞くと、SQL基準に使える言葉になります。

営業に聞く時は、抽象的な理想ではなく、過去の具体例を聞くとよいです。

・最近、良かったリードはどれか
・なぜ良かったと感じたのか
・逆に、追いにくかったリードはどれか
・何が足りなかったのか
・最初からわかっていたら助かった情報は何か

このように聞くと、営業が本当に見ている条件が見えてきます。

マーケティング側が想像で決めるより、営業の言葉をそのまま拾った方が実務に合います。

ただし、営業の意見をそのまますべて採用する必要はありません。
データと照らし合わせて、再現性があるかを見ることが大切です。

商談化率だけでなく受注率まで見て基準を考える

SQL基準を決める時は、商談化率だけでなく受注率まで見た方がいいです。

商談化率が高いリードは、一見良さそうに見えます。
営業につながりやすい。
アポイントが取りやすい。
会話が始まりやすい。

でも、その後に受注しないなら、基準を見直す必要があります。

たとえば、資料請求後すぐに商談化するリードが多いとします。
しかし、実際には情報収集だけで、受注率が低いかもしれません。

逆に、商談化まで少し時間はかかるけれど、受注率が高いリードもあります。
たとえば、複数回サイトを訪問し、事例を読み、ウェビナーにも参加してから問い合わせるようなリードです。

SQL基準では、目先の商談化だけでなく、最終的に受注につながるかを見た方がいいです。

もちろん、受注まで見るには時間がかかります。
すぐに判断できないこともあります。
それでも、定期的に振り返ることが大切です。

・SQLから商談化したか
・商談から提案に進んだか
・提案から受注したか
・受注単価はどうだったか
・導入後の相性はどうだったか

ここまで見ると、本当に価値のあるSQL基準が見えてきます。

SQLは商談数を増やすためだけのものではありません。
受注につながる商談を増やすための基準です。

SQL基準に入れるべき基本項目

SQL基準には、いくつか入れておきたい基本項目があります。

ただし、全部を厳しくしすぎると、SQLがほとんど出なくなります。
逆に甘くしすぎると、営業が追うべきではないリードまでSQLになります。

大事なのは、自社の商材や営業体制に合わせて、どの項目を必須にするか、どの項目を加点にするかを決めることです。

ここでは、代表的な項目を見ていきます。

企業規模や業種がターゲットに合っているか

まず見るべきなのは、企業規模や業種がターゲットに合っているかです。

BtoBでは、どの会社でも受注できるわけではありません。
商材によって、合う企業規模や業種があります。

たとえば、大企業向けのサービスなのに、従業員数がかなり少ない会社ばかりSQLにしても、商談化や受注は難しいかもしれません。
逆に、中堅企業向けのサービスなのに、大企業の複雑な要件に対応しきれない場合もあります。

業種も同じです。

製造業に強いサービス。
IT企業に向いているサービス。
小売や店舗ビジネスに合うサービス。
BtoB企業向けのサービス。

自社が価値を出しやすい業種はどこかを見ておく必要があります。

企業規模や業種は、SQL基準の土台になります。
ここが大きくズレていると、どれだけ行動データが良くても商談化しにくいです。

ただし、ターゲット外だから絶対に無視するという意味ではありません。
新しい可能性がある場合もあります。

大事なのは、優先度を分けることです。

・主ターゲットなので優先して営業へ渡す
・近いターゲットなので条件次第で営業へ渡す
・ターゲット外なのでナーチャリングに回す
・明らかに対象外なので除外する

このように整理すると、営業も動きやすくなります。

部署や役職が導入検討に関係しているか

次に見るべきなのは、部署や役職です。

同じ会社からのリードでも、誰が反応しているかによって意味が変わります。

導入検討に関わる部署の人なのか。
実際に使う現場の人なのか。
予算を持つ責任者なのか。
情報収集だけの担当者なのか。
決裁者に近い人なのか。

ここを見ることで、営業がどう動くべきかが変わります。

たとえば、マーケティング支援サービスなら、マーケティング部門、営業企画、事業部門などは検討に関係しやすいです。
一方で、まったく関係のない部署からの資料ダウンロードなら、SQLとしての優先度は下がるかもしれません。

役職も重要です。

現場担当者が情報収集している場合もあります。
課長や部長が具体的な課題を持っている場合もあります。
経営層が直接見ている場合もあります。

ただ、役職が高ければ必ず良いとは限りません。
現場担当者がかなり具体的に比較していて、そこから上司に上げるケースもあります。

だから、部署や役職は単独で見るのではなく、課題や行動と合わせて見ます。

・検討に関係する部署か
・導入に影響を持つ立場か
・現場課題を理解している人か
・決裁者や上司につなげられそうか

ここを確認すると、SQL判断の精度が上がります。

課題やニーズが具体的に見えているか

SQL基準でかなり大事なのが、課題やニーズの具体性です。

どれだけターゲット企業に合っていても、課題が見えていなければ商談化は難しいです。

たとえば、問い合わせフォームに「詳しく知りたいです」とだけ書かれている場合。
これは興味はありますが、課題はまだ見えません。

一方で、「リードは増えているが商談化率が低く、営業連携を見直したい」と書かれていれば、かなり具体的です。
営業も話を始めやすくなります。

課題が具体的なリードは、営業が提案しやすいです。
相手の状況を理解しやすく、初回接点でも会話が進みやすいからです。

課題の具体性を見る時は、次のような点を確認します。

・何に困っているのかがわかる
・なぜ今検討しているのかが見える
・現状の課題が言葉になっている
・解決したい状態がある程度見える
・自社サービスで支援できる可能性がある

資料ダウンロードだけでは課題が見えない場合もあります。
その場合は、閲覧した資料のテーマや、その後の行動から推測します。

たとえば、SQL基準に関する資料を何度も見ているなら、営業連携やリード評価に悩んでいる可能性があります。
料金ページや導入事例も見ているなら、比較検討に進んでいる可能性があります。

課題が具体的に見えるほど、SQLとしての優先度は高くなります。

導入時期や検討タイミングが明確か

導入時期や検討タイミングも、SQL基準では重要です。

どれだけ課題が明確でも、導入時期がまったく未定だと、今すぐ営業が動くべきかは判断が分かれます。

もちろん、将来の見込み客として大事に育てるべきです。
ただ、営業がすぐ商談化を目指すリードかというと、別の判断が必要です。

導入時期が明確なリードは、営業が動きやすいです。

・今期中に導入したい
・来期予算に向けて情報収集している
・半年以内に比較検討したい
・既存ツールの更新時期が近い
・社内プロジェクトが始まっている

このような情報があると、営業は提案の進め方を考えやすくなります。

逆に、「いつか検討したい」「今は情報収集だけ」という状態なら、ナーチャリングの方が合う場合もあります。

導入時期は、問い合わせフォームやアンケートで聞くこともできます。
ウェビナー後のアンケートでも確認できます。
営業が初回接点で聞いた情報をCRMに残すことも大事です。

SQL基準では、導入時期を必須にするか、加点条件にするかを考えます。

商材によっては、導入時期が見えないと営業対応しにくいことがあります。
一方で、単価が高く検討期間が長い商材では、早めに営業が関係を作った方がいい場合もあります。

自社の営業プロセスに合わせて判断しましょう。

予算感や投資余力があるか

予算感や投資余力も、SQL判断で見たい項目です。

どれだけニーズがあっても、予算がまったくない場合、すぐに受注するのは難しいです。
特に高単価のBtoB商材では、予算の有無は商談の進み方に大きく関わります。

ただし、最初から明確な予算があるとは限りません。

まだ情報収集段階の人は、予算を決める前に資料を見ていることもあります。
現場担当者が必要性を感じていて、これから上司に相談する場合もあります。
来期予算に向けて、相場を調べている場合もあります。

だから、予算が明確でないからといって、すぐにSQLから外す必要はありません。

見るべきなのは、投資余力や検討可能性です。

・過去に同じ領域へ投資していそうか
・企業規模的に導入余地があるか
・課題の大きさに対して投資が妥当か
・予算化のタイミングが近いか
・上司や関係者を巻き込めそうか

予算感を確認するには、フォームで選択式にする方法もあります。
ただし、最初から細かく聞きすぎると、フォーム離脱が増えることもあります。

そのため、資料ダウンロード時には軽く聞き、問い合わせや相談時に詳しく聞くなど、段階を分けるのも有効です。

SQL基準では、予算は大事ですが、見えないことも多い項目です。
だからこそ、企業規模、課題、導入時期と合わせて判断するのが現実的です。

決裁者や関与者との接点があるか

BtoBでは、決裁者や関与者との接点も重要です。

実際の導入では、ひとりの担当者だけで決まることは少ないです。
現場担当者、上司、部門責任者、情報システム、経理、経営層など、複数の人が関わることがあります。

そのため、SQLとして営業に渡す時には、誰と接点があるのかを見る必要があります。

たとえば、現場担当者からの問い合わせでも、上司に提案するための資料を探しているなら良いリードです。
部長クラスが導入事例を見ているなら、検討が進みやすいかもしれません。
複数名が同じ会社から資料を見ているなら、社内で関心が高まっている可能性があります。

決裁者本人でなくても、関与者との接点があれば営業は動きやすくなります。

SQL基準では、次のような点を見るとよいです。

・決裁者本人か
・導入検討に関わる部署か
・上司や関係者に共有する立場か
・同じ会社から複数人の接点があるか
・過去に営業接点がある会社か

特に同じ会社から複数の行動がある場合は、注意して見る価値があります。
一人の興味ではなく、組織として検討が始まっている可能性があるからです。

営業に渡す時は、「誰が」「何を見て」「どんな行動をしたのか」を伝えると動きやすくなります。

行動データからSQLを見極めるポイント

BtoBマーケティングでは、行動データもSQL判断に使えます。

資料ダウンロード。
ページ閲覧。
メールクリック。
ウェビナー参加。
再訪問。
問い合わせ。

こうした行動は、相手の興味や検討度を知るヒントになります。

ただし、行動データを過信してはいけません。
行動したからといって、必ず営業が動くべきとは限らないからです。

資料ダウンロードだけでSQLにしない

資料ダウンロードは重要な行動です。

自社の情報に興味を持ってくれたサインではあります。
ただ、資料ダウンロードだけでSQLにするのは少し危険です。

なぜなら、資料ダウンロードの目的は人によって違うからです。

・情報収集したい
・勉強したい
・社内資料の参考にしたい
・競合調査をしている
・たまたまテーマが気になった
・今すぐ導入検討している

同じ資料ダウンロードでも、温度感は大きく違います。

特にノウハウ系の資料は、潜在層も多く集まります。
これは悪いことではありません。
ただ、すべてをSQLとして営業へ渡すと、商談化率は下がりやすくなります。

資料ダウンロードをSQL判断に使うなら、他の情報と組み合わせましょう。

・ターゲット企業に合っているか
・部署や役職が合っているか
・ダウンロードした資料のテーマが具体的か
・その後に料金ページや事例ページを見ているか
・複数回接触しているか
・問い合わせや相談につながっているか

このように見ると、資料ダウンロードの意味がわかりやすくなります。

資料ダウンロードは、SQLのきっかけにはなります。
でも、それだけでSQLと決めるのではなく、検討度を見極める材料として使う方が現実的です。

料金ページや導入事例の閲覧を重視する

行動データの中でも、料金ページや導入事例の閲覧は重視したいポイントです。

料金ページを見る人は、少なくとも費用感に関心があります。
導入事例を見る人は、自社に近い会社がどう使っているかを知りたい可能性があります。

これは、単なる情報収集よりも一歩進んだ行動です。

もちろん、料金ページを見たら必ずSQLというわけではありません。
ただ、検討度が高いサインとして見る価値はあります。

特に次のような行動は注目です。

・料金ページを複数回見ている
・導入事例を複数見ている
・同じ業種の事例を見ている
・サービス紹介ページと料金ページを行き来している
・資料ダウンロード後に料金ページを見ている
・メールクリック後に事例ページを見ている

こうした動きがあると、ユーザーは比較や検討に入っている可能性があります。

営業に渡す時も、単に「スコアが高いです」より、「料金ページと導入事例を見ています」と伝えた方が動きやすいです。

営業は、その情報をもとに初回接点の話題を作れます。

「料金感を確認されていたので、費用対効果の考え方からお話しできます」
「同じ業界の事例をご覧になっていたので、近いケースをご紹介できます」

このように、行動データは営業の会話にも使えます。

複数回の接触や再訪問を評価に入れる

一度だけの行動より、複数回の接触や再訪問は重要です。

人は、本当に気になっているものを何度も見ます。
一度資料を見て終わりではなく、後日またサイトを見る。
メールをクリックする。
別の資料もダウンロードする。
ウェビナーにも参加する。

こうした行動が積み重なると、検討度が高まっている可能性があります。

SQL基準では、単発の行動だけでなく、行動の積み重ねを見ることが大切です。

たとえば、次のようなリードは注目です。

・一度資料を見た後、数日後に再訪問している
・複数の資料をダウンロードしている
・ウェビナー参加後にサービスページを見ている
・メールを複数回クリックしている
・同じ会社から複数人が接触している

こうした行動は、興味が一時的ではない可能性を示しています。

ただし、回数だけを見ても不十分です。
何を何回見ているのかが大事です。

ノウハウ記事だけを何度も見ているのか。
料金や事例を見ているのか。
問い合わせページまで来ているのか。

行動の量と質を合わせて見ることで、SQL判断の精度が上がります。

ウェビナー参加後の行動変化を見る

ウェビナー参加は、BtoBマーケティングでよくあるリード獲得施策です。

ただ、ウェビナーに参加しただけでSQLにするのは早い場合があります。

ウェビナー参加者にも、いろいろな人がいます。

・テーマに興味があった人
・勉強目的の人
・競合調査の人
・今後の参考にしたい人
・本気で導入検討している人

だから、ウェビナー参加後の行動を見ることが大切です。

たとえば、参加後にサービスページを見ている。
料金ページを見ている。
導入事例を見ている。
アンケートで具体的な課題を書いている。
個別相談を希望している。

このような行動があれば、SQLとしての優先度は上がります。

逆に、参加だけしてその後の行動がない場合は、すぐに営業が強く追うよりも、フォローメールや追加資料で育成した方が合うこともあります。

ウェビナー後は、参加したかどうかだけでなく、参加後に何が変わったかを見ることが大事です。

ウェビナーはゴールではなく、検討度を見るきっかけです。

参加後の動きまで追うことで、SQL化の判断がしやすくなります。

問い合わせ内容の具体性を確認する

問い合わせはSQLになりやすい行動です。

ただし、問い合わせにも温度差があります。

「資料が欲しいです」
「詳しく知りたいです」
「一度話を聞きたいです」

こうした問い合わせは、興味はありますが、課題の具体性はまだ見えにくいです。

一方で、次のような問い合わせはSQLとしてかなり強いです。

・現在使っているツールに課題がある
・導入時期が決まっている
・比較しているサービスがある
・上司に提案するための情報が欲しい
・予算化に向けて相談したい
・具体的な業務課題が書かれている

問い合わせ内容が具体的だと、営業は初回から深い話がしやすくなります。

SQL基準では、問い合わせの有無だけでなく、中身を見ることが重要です。

フォームに自由記述欄がある場合は、そこに書かれた言葉を丁寧に見ましょう。
短い文章でも、課題の深さが出ることがあります。

営業に渡す時は、問い合わせ内容をそのまま共有するだけでなく、「なぜSQLと判断したのか」も添えるとよいです。

たとえば、次のように伝えます。

・導入時期の記載があります
・現行ツールの課題が具体的です
・比較検討中と書かれています
・同業界の事例ページも閲覧しています

こうすると、営業はかなり動きやすくなります。

BtoBマーケティングで使いやすいSQL基準の作り方

SQL基準は、複雑にしすぎると運用されません。

一方で、簡単にしすぎると精度が下がります。

大事なのは、実務で使える形にすることです。

営業もマーケティングも理解できる。
CRMやMAに落とし込める。
見直しができる。
そして、商談化率や受注率の改善につながる。

このバランスが大切です。

属性情報と行動情報を組み合わせて判断する

SQL基準では、属性情報と行動情報を組み合わせることが大切です。

属性情報とは、そのリードがどんな会社や人かという情報です。

・企業規模
・業種
・部署
・役職
・地域
・既存顧客との類似性

行動情報とは、そのリードが何をしたかという情報です。

・資料ダウンロード
・ページ閲覧
・料金ページ閲覧
・導入事例閲覧
・ウェビナー参加
・問い合わせ
・メールクリック
・再訪問

どちらか一方だけでは不十分です。

属性が合っていても、行動が弱ければ今すぐ営業が動くには早いかもしれません。
行動が強くても、ターゲット外なら受注につながりにくいかもしれません。

たとえば、ターゲット企業の部長が料金ページを複数回見ているなら、SQLとして優先度は高いです。
一方で、ターゲット外の個人が資料を何度も見ていても、営業対応の優先度は低いかもしれません。

このように、属性と行動を掛け合わせて見ます。

SQLの基準を作る時は、単純に点数だけを見るのではなく、「どんな人が、どんな行動をしたのか」を見ることが大切です。

属性は相性を示します。
行動は温度感を示します。
この両方がそろうと、SQLとして判断しやすくなります。

スコアだけでなく営業判断も入れる

MAを使っていると、リードスコアリングでSQLを判断したくなります。

スコアが一定以上になったらSQL。
料金ページを見たら加点。
メールをクリックしたら加点。
資料をダウンロードしたら加点。

この仕組みは便利です。

ただ、スコアだけでSQLを決めるのは危険です。

スコアは行動を数字にできます。
でも、その行動の意味までは完全には判断できません。

たとえば、資料をたくさん見ている人がいても、競合調査かもしれません。
メールをよくクリックしていても、単に勉強熱心なだけかもしれません。
料金ページを見ていても、ターゲット外かもしれません。

だから、スコアは判断材料のひとつとして使い、営業判断も入れる方が現実的です。

営業判断とは、営業が見て「このリードは追う価値がある」と判断する視点です。

・過去の商談経験から見て相性が良さそうか
・問い合わせ内容に商談化の可能性があるか
・会社情報を見ると導入余地がありそうか
・過去の受注企業と似ているか
・今営業が接触すると前に進みそうか

こうした視点は、スコアだけでは拾いきれません。

理想は、スコアで候補を出し、営業とマーケティングで基準を磨くことです。

スコアは自動化のために使う。
営業判断は精度を上げるために使う。

この役割分担ができると、SQL運用はかなり安定します。

「必須条件」と「加点条件」を分けて設計する

SQL基準を作る時は、必須条件と加点条件を分けると使いやすくなります。

必須条件とは、SQLにするために最低限必要な条件です。
加点条件とは、あると優先度が上がる条件です。

この2つを分けないと、基準が混乱します。

たとえば、ターゲット企業であることは必須条件かもしれません。
部署が検討に関係していることも必須に近いかもしれません。
一方で、料金ページを見た、導入事例を見た、複数回訪問したという行動は加点条件にできます。

例としては、次のように整理できます。

・必須条件はターゲット企業である
・必須条件は連絡可能な担当者情報がある
・必須条件は明らかな対象外ではない
・加点条件は料金ページ閲覧がある
・加点条件は導入事例閲覧がある
・加点条件は問い合わせ内容が具体的である
・加点条件は同じ会社から複数人の接点がある

このように分けると、運用しやすくなります。

すべてを必須にすると、SQLが少なくなりすぎます。
すべてを加点にすると、ターゲット外でもSQLになってしまうことがあります。

だから、まずは最低限外せない条件を決めます。
その上で、優先度を上げる条件を加えていきます。

SQL基準は、厳しすぎても甘すぎても使いにくいです。

必須条件と加点条件を分けることで、現実的な基準になります。

すぐ営業に渡すリードとナーチャリング対象を分ける

SQL基準では、すぐ営業に渡すリードと、ナーチャリング対象を分けることが大切です。

ナーチャリングとは、今すぐ営業が動くには早いリードに対して、情報提供を続けながら検討度を高めることです。

すべてのリードをすぐ営業に渡す必要はありません。
むしろ、まだ早いリードを営業に渡しすぎると、営業の負担が増えます。

たとえば、次のようなリードはナーチャリング対象かもしれません。

・ターゲットには合うが、導入時期が未定
・資料ダウンロードだけで行動が少ない
・課題はありそうだが具体性が低い
・担当者は関心を持っているが、社内検討前
・ウェビナー参加のみで、その後の行動がない

こうしたリードは、無理に営業が追うより、メールやセミナー、事例紹介で育てた方がよい場合があります。

一方で、次のようなリードはすぐ営業に渡すべきです。

・問い合わせ内容が具体的
・導入時期が見えている
・料金や事例を複数見ている
・ターゲット企業で役職も合っている
・同じ会社から複数の接点がある

このように分けることで、営業の優先順位が明確になります。

SQLにしないリードを放置するのではありません。
適切なタイミングまで育てるのです。

SQL化しないことは、捨てることではありません。
今は営業ではなく、マーケティングで育てるという判断です。

最初から完璧な基準を作ろうとしない

SQL基準を作る時、最初から完璧なものを作ろうとしすぎると進みません。

どの点数が正しいのか。
どの行動を重視すべきか。
どの条件を必須にすべきか。
営業全員が納得する基準は何か。

考えることが多く、決めきれなくなります。

でも、SQL基準は一度で完成させるものではありません。
運用しながら改善するものです。

最初は仮の基準で構いません。

たとえば、まずは次のように始めてもよいです。

・ターゲット企業である
・検討に関係する部署である
・具体的な行動がある
・営業が対応する価値がある
・明らかな対象外ではない

このくらいから始めて、運用しながら精度を上げていきます。

大事なのは、基準を作った後に必ず振り返ることです。

実際に商談化したか。
営業の評価はどうだったか。
受注につながったか。
基準が甘すぎたか。
厳しすぎたか。

この振り返りを続ければ、SQL基準は少しずつ良くなります。

最初から完璧を狙うより、まず合意して回す。
そして、データと現場の声で直す。

これが実務では一番進めやすいです。

SQL基準を営業とマーケティングで合意する方法

SQL基準は、作ることよりも合意することが難しいです。

マーケティング側は、リード獲得の背景を知っています。
営業側は、商談化や受注の現場を知っています。

どちらか一方だけでは、良い基準にはなりません。

大事なのは、営業とマーケティングが同じテーブルで話すことです。

営業が追いたくなる条件を具体的に聞く

まずは、営業が追いたくなる条件を具体的に聞くことです。

ただし、「どんなリードが欲しいですか」と聞くだけでは不十分です。

営業は忙しいので、抽象的な答えになりやすいです。
「温度感が高いリード」
「決裁者に近いリード」
「ちゃんと検討しているリード」

これでは基準に落とし込めません。

具体的に聞くことが大切です。

・最近、商談化しやすかったリードはどれか
・なぜ追いやすかったのか
・最初にどんな情報があったか
・逆に追いにくかったリードはどれか
・どんなリードなら優先順位を上げるか
・営業に渡す時に、どんな情報があると助かるか

こう聞くと、営業の考えが具体的になります。

営業が本当に知りたいのは、単なるスコアではないことが多いです。

どんな課題を持っているのか。
今どの段階なのか。
誰が問い合わせているのか。
なぜ今アプローチすべきなのか。

この情報があると、営業は動きやすくなります。

SQL基準を合意する時は、営業が追いたくなる条件を、言葉にして残しましょう。

マーケティング側のリード獲得背景も共有する

営業の意見を聞くだけでなく、マーケティング側のリード獲得背景も共有する必要があります。

営業から見ると、リードは急にCRMに入ってきたものに見えることがあります。

でも実際には、その前にいろいろな接点があります。

広告を見た。
記事を読んだ。
資料をダウンロードした。
ウェビナーに参加した。
メールをクリックした。
事例ページを見た。

この流れを営業に共有すると、リードの見え方が変わります。

たとえば、ただの資料請求に見えていたリードが、実は数週間前から何度もサイトを訪問していたかもしれません。
ウェビナー参加だけに見えていたリードが、その後に料金ページを見ていたかもしれません。

こうした背景を共有すると、営業は優先順位をつけやすくなります。

マーケティング側は、リードを渡す時に次の情報を添えるとよいです。

・どの施策から来たリードか
・どの資料を見たか
・どのページを見ているか
・過去にどんな接点があるか
・SQL化した理由は何か
・想定される課題は何か

営業は、背景があるとアプローチしやすくなります。

SQL基準は、営業にリードを渡す線引きだけではありません。
営業が初回接点を作るための情報整理でもあります。

商談化しなかった理由を営業から回収する

SQL基準を改善するには、商談化しなかった理由を営業から回収することが大切です。

営業に渡したSQLが商談にならなかった。
その時に、なぜ商談にならなかったのかを確認します。

ここを見ないと、基準は良くなりません。

商談化しなかった理由には、いろいろあります。

・連絡がつかなかった
・情報収集だけだった
・導入時期が未定だった
・予算がなかった
・ターゲット外だった
・部署が違った
・すでに他社で決まっていた
・課題が浅かった

この理由を分類すると、SQL基準のどこを直すべきかが見えてきます。

たとえば、連絡がつかないリードが多いなら、フォーム情報やフォロータイミングを見直す必要があります。
情報収集だけのリードが多いなら、SQL化が早すぎるかもしれません。
ターゲット外が多いなら、広告配信やフォーム条件を見直す必要があります。

営業からのフィードバックは、責めるために集めるものではありません。
基準を改善するために集めるものです。

マーケティング側も、営業側も、同じ目的で振り返ることが大切です。

商談化しなかった理由は、SQL基準を磨くための材料です。

定例会でSQLの質を振り返る

SQL基準を運用するなら、定例会でSQLの質を振り返ることをおすすめします。

一度基準を作って終わりにすると、だんだん現場とズレていきます。

市場が変わる。
商材が変わる。
営業体制が変わる。
獲得チャネルが増える。
ターゲットが変わる。

こうした変化があると、SQL基準も見直す必要があります。

定例会では、単に件数を見るだけでは不十分です。

・SQL数
・商談化率
・受注率
・チャネル別の質
・営業の評価
・商談化しなかった理由
・基準を見直すべき点

このような内容を確認します。

営業とマーケティングが一緒に見ることで、ズレが早く見つかります。

マーケティングは、どの施策が良いリードを生んでいるかを把握できます。
営業は、どんなリードなら追いやすいかを伝えられます。
お互いに、感覚ではなくデータと事例で話せます。

定例会は、長くなくてもいいです。
大事なのは、継続して見ることです。

月に一度でも、SQLの質を振り返る場があるだけで、運用はかなり変わります。

基準変更の判断を感覚ではなくデータで行う

SQL基準を変える時は、感覚だけで判断しないことが大切です。

営業から「最近リードの質が悪いです」と言われる。
マーケティング側は「でも件数は増えています」と感じる。
このままだと、議論が感覚のぶつかり合いになります。

だから、データを見る必要があります。

商談化率は下がっているのか。
受注率は変わっているのか。
特定のチャネルだけ悪いのか。
特定の資料から来たリードが悪いのか。
ターゲット外の割合が増えているのか。
導入時期未定のリードが増えているのか。

こうしたデータを見ると、基準をどこで変えるべきかが見えてきます。

もちろん、営業の感覚も大切です。
現場の違和感は、早い段階で変化を教えてくれることがあります。

ただ、その感覚をデータで確認することが重要です。

感覚で基準を厳しくしすぎると、SQL数が減りすぎることがあります。
逆に、リード数を増やしたいからと基準を甘くすると、営業の負担が増えます。

SQL基準は、営業の声とデータの両方で見直しましょう。

SQL基準を決める時によくある失敗

SQL基準を作る時には、よくある失敗があります。

どれも、実務では起きやすいです。

資料請求をすべてSQLにする。
スコアだけで判断する。
営業の肌感だけに寄せる。
大企業名だけで高評価する。
基準を作って放置する。

こうした失敗を避けるだけでも、SQL運用はかなり改善します。

資料請求したらすべてSQLにしてしまう

よくある失敗が、資料請求したらすべてSQLにしてしまうことです。

資料請求は確かに重要です。
でも、資料請求の温度感は人によって違います。

今すぐ比較している人もいます。
来期に向けて情報収集している人もいます。
勉強目的の人もいます。
競合調査の人もいます。
ターゲット外の人もいます。

それをすべてSQLにすると、営業に渡すリードの質がバラバラになります。

特にノウハウ資料は、多くの人にとってダウンロードしやすいです。
その分、今すぐ商談化する人ばかりではありません。

資料請求をSQLにする場合は、他の条件と組み合わせましょう。

・ターゲット企業か
・部署や役職が合っているか
・資料のテーマが商材に近いか
・その後に料金ページや事例ページを見たか
・問い合わせ内容が具体的か

資料請求は、SQLの入口です。
でも、それだけでSQLと決めるのは早い場合があります。

スコアリングの点数だけで判断してしまう

スコアリングの点数だけでSQLを判断するのも、よくある失敗です。

スコアは便利です。
大量のリードを整理できます。
優先度を見える化できます。
営業通知も自動化しやすくなります。

ただ、点数は万能ではありません。

たとえば、メールをたくさんクリックしているから点数が高い。
資料を複数ダウンロードしているから点数が高い。
ページ閲覧数が多いから点数が高い。

でも、その人がターゲット外ならSQLとしては弱いです。
導入権限がない人なら、営業の進め方が変わります。
情報収集だけなら、まだナーチャリングが必要です。

スコアは行動量を示します。
ただし、商談化の確度を完全に示すわけではありません。

だから、スコアは属性情報や営業判断と組み合わせる必要があります。

点数が高いからSQL。
点数が低いから対象外。

このように単純に決めるのではなく、点数の中身を見ましょう。

何で点数が上がったのか。
どの行動があったのか。
ターゲットに合っているのか。
営業が動く理由があるのか。

ここまで見ると、スコアリングはかなり使いやすくなります。

営業の肌感だけに寄せすぎる

営業の声はとても大切です。

ただし、営業の肌感だけに寄せすぎるのも注意が必要です。

営業は現場を知っています。
どんなリードが商談になりやすいかを肌で感じています。
これはSQL基準に必ず活かすべきです。

でも、営業の感覚だけで基準を作ると、偏りが出ることがあります。

たとえば、営業が今すぐ商談化しやすいリードだけを求めると、将来の見込み客を拾えなくなるかもしれません。
特定の営業担当者の経験だけで決めると、他の営業には合わない基準になるかもしれません。
過去の成功パターンに寄せすぎると、新しい市場を開拓しにくくなるかもしれません。

だから、営業の声はデータとセットで見る必要があります。

営業が良いと言ったリードは、本当に商談化しているか。
受注率は高いか。
どのチャネルから来ているか。
共通点はあるか。

このように確認すると、営業の肌感を再現性のある基準に変えられます。

営業の声を無視してはいけません。
でも、営業の声だけで決めてもいけません。

営業の現場感と、マーケティングのデータを合わせることが大切です。

ターゲット外の大企業リードを過大評価してしまう

大企業からリードが来ると、つい期待してしまいます。

有名企業のメールアドレス。
大きな会社名。
役職のある担当者。

これを見ると、「これは良いリードかもしれない」と思いたくなります。

でも、大企業だからといって必ず良いSQLとは限りません。

自社サービスの対象ではない部署かもしれません。
情報収集だけかもしれません。
競合調査かもしれません。
導入までのプロセスが長すぎて、今すぐ営業が動くには早いかもしれません。

もちろん、大企業リードは大事です。
ただし、会社名だけで過大評価するのは危険です。

見るべきなのは、ターゲットとの相性です。

・自社が価値を出せる業種か
・導入できる規模や体制があるか
・部署や役職が検討に関係しているか
・課題が具体的か
・行動データに検討度が見えるか
・営業が接点を作れる可能性があるか

会社名だけでSQLにすると、営業が追った時に空振りすることがあります。

逆に、知名度はそこまで高くなくても、課題が明確で、導入時期があり、担当者が本気で検討しているリードの方が商談化しやすいこともあります。

SQL基準では、企業名の印象ではなく、受注につながる条件を見ることが大切です。

基準を作った後に見直さず放置してしまう

SQL基準は、作って終わりではありません。

ここを放置すると、だんだん現場とズレていきます。

最初はうまくいっていた基準でも、時間が経つと合わなくなることがあります。

ターゲット市場が変わる。
商材が変わる。
価格が変わる。
競合環境が変わる。
広告チャネルが増える。
営業体制が変わる。

このような変化があると、SQL基準も見直す必要があります。

たとえば、以前は資料請求から商談化しやすかったけれど、最近はノウハウ資料の流入が増えて温度感が下がっているかもしれません。
以前は特定業種が強かったけれど、新しい事例が増えて別業種でも受注しやすくなっているかもしれません。

基準を放置すると、マーケティングと営業のズレが大きくなります。

SQL基準は、定期的に振り返りましょう。

月次でも四半期でも構いません。
大事なのは、商談化率、受注率、営業の声を見ながら調整することです。

SQL基準は、完成品ではなく運用品です。

SQLの基準を改善するために見るべき指標

SQL基準を改善するには、見るべき指標があります。

感覚だけで「良いリード」「悪いリード」と判断すると、議論がずれやすいです。

数字を見ることで、どこに問題があるのかがわかります。

ただし、見る数字はSQL数だけでは不十分です。
SQLから先の数字まで見る必要があります。

SQLから商談化した割合を見る

まず見るべきなのは、SQLから商談化した割合です。

SQLとして営業に渡したリードのうち、どれくらいが実際に商談になったかを見ます。

この割合が低い場合、SQL基準が甘い可能性があります。
または、営業への渡し方やフォロータイミングに問題がある可能性もあります。

商談化率が低い時は、すぐに基準を厳しくするのではなく、原因を分けて見ましょう。

・ターゲット外が多いのか
・連絡がつかないのか
・課題が浅いのか
・導入時期がないのか
・営業対応が遅れているのか
・SQL化した理由が営業に伝わっていないのか

同じ商談化率の低下でも、原因によって改善策は違います。

ターゲット外が多いなら、獲得チャネルやフォーム条件を見直します。
連絡がつかないなら、フォロータイミングや連絡手段を見直します。
課題が浅いなら、ナーチャリングに回す基準を作ります。

SQLから商談化した割合は、SQL基準の精度を見る最初の指標です。

SQLから受注まで進んだ割合を見る

次に見るべきなのは、SQLから受注まで進んだ割合です。

商談化率が高くても、受注率が低い場合があります。
これは、商談にはなるけれど、最終的には自社と相性が悪いリードが多い可能性があります。

たとえば、検討意欲はある。
営業との会話も進む。
でも予算が合わない。
課題が自社サービスで解決しきれない。
競合に負けやすい。
導入条件が合わない。

このような場合、SQL基準を見直す必要があります。

SQL基準は、商談を作るためだけではなく、受注につながる商談を作るためにあります。

受注率を見る時は、リードの入口まで戻って確認しましょう。

・どのチャネルから来たか
・どの資料を見たか
・どのページを見ていたか
・どんな企業属性だったか
・どんな課題を持っていたか
・どの営業プロセスで止まったか

ここを見ると、受注につながりやすいSQLの特徴が見えてきます。

受注まで見るには時間がかかります。
でも、定期的に見る価値は大きいです。

営業対応後の失注理由を分類する

SQL基準を改善するには、営業対応後の失注理由を分類することが大事です。

失注理由が曖昧だと、改善できません。

「温度感が低かった」
「合わなかった」
「検討見送り」

このような記録だけでは、次に何を直せばいいかわかりません。

もう少し分類すると、改善につながります。

・予算が合わなかった
・導入時期が未定だった
・決裁者に接点がなかった
・課題が自社サービスと合わなかった
・競合に決まった
・情報収集だけだった
・連絡がつかなかった
・ターゲット外だった

この分類を続けると、SQL基準の弱点が見えます。

たとえば、予算が合わない失注が多いなら、予算感や企業規模の基準を見直す必要があります。
情報収集だけが多いなら、SQL化が早すぎるかもしれません。
ターゲット外が多いなら、広告配信や獲得施策を見直す必要があります。

失注理由は、営業のためだけの情報ではありません。
マーケティングがSQL基準を改善するための重要な材料です。

リード獲得チャネル別にSQLの質を比較する

SQLの質は、獲得チャネルによって変わります。

広告。
自然検索。
ウェビナー。
展示会。
紹介。
比較サイト。
ホワイトペーパー。

それぞれ、集まるリードの質は違います。

リード数が多いチャネルが、必ず良いチャネルとは限りません。
SQL化しやすいチャネル。
商談化しやすいチャネル。
受注しやすいチャネル。
それぞれ違うことがあります。

たとえば、広告はリード数が多いけれど、商談化率が低いかもしれません。
ウェビナーはリード数は少ないけれど、課題理解が深く商談化しやすいかもしれません。
自然検索は時間がかかるけれど、ニーズが明確なリードが多いかもしれません。

チャネル別に見ると、マーケティング施策の改善にもつながります。

・どのチャネルがSQLを生みやすいか
・どのチャネルが商談化しやすいか
・どのチャネルが受注につながりやすいか
・どのチャネルはナーチャリング前提で見るべきか

このように整理すると、予算配分や施策設計も変わります。

SQL基準は、チャネル別の質を見ることでさらに磨かれます。

SQL化までの期間と商談化までの期間を見る

SQL化までの期間と、商談化までの期間も見ておきたい指標です。

リードを獲得してから、どれくらいでSQLになるのか。
SQLになってから、どれくらいで商談になるのか。

この期間を見ると、リードの育ち方がわかります。

たとえば、問い合わせ経由のリードはすぐSQL化し、すぐ商談化するかもしれません。
ホワイトペーパー経由のリードは、SQL化まで時間がかかるかもしれません。
ウェビナー参加者は、参加後のフォロー次第で商談化までの期間が変わるかもしれません。

この違いを見ずに、すべて同じ基準で判断するとズレます。

SQL化まで時間がかかるチャネルは、ナーチャリング設計が重要です。
SQL化後に商談化まで時間がかかるなら、営業フォローのタイミングや内容を見直す必要があります。

期間を見ることで、どこで詰まっているのかが見えます。

・リードは取れているがSQLにならない
・SQLにはなるが商談にならない
・商談にはなるが受注しない
・SQL化のタイミングが早すぎる
・営業フォローが遅れている

SQL基準は、点ではなく流れで見ることが大切です。

SQL基準を運用に落とし込む方法

SQL基準は、決めるだけでは意味がありません。

実際の運用に落とし込む必要があります。

CRMやMAに反映する。
営業に渡すタイミングを決める。
SQL化した理由を共有する。
フォロー期限を決める。
SQLにならなかったリードの育成導線を作る。

ここまでやって、はじめてSQL基準は機能します。

CRMやMAにSQL判定項目を設定する

SQL基準を運用するには、CRMやMAに判定項目を設定する必要があります。

頭の中で基準を持っているだけでは、運用が属人化します。
担当者によって判断が変わります。
営業にも伝わりにくくなります。

CRMやMAには、SQL判断に必要な項目を入れておきましょう。

・企業規模
・業種
・部署
・役職
・リード獲得チャネル
・閲覧ページ
・ダウンロード資料
・問い合わせ内容
・導入時期
・予算感
・SQL化理由
・営業対応状況

すべてを最初から完璧に入れる必要はありません。
ただ、営業が動くために必要な情報は見えるようにしておくべきです。

特に重要なのは、SQL化理由です。

なぜこのリードをSQLにしたのか。
何を見て営業に渡す判断をしたのか。

これがわからないと、営業は優先順位をつけにくくなります。

CRMやMAは、データをためるためだけのものではありません。
営業とマーケティングが同じ情報を見るための場所です。

営業に渡すタイミングを明確にする

SQL基準を作ったら、営業に渡すタイミングも決める必要があります。

タイミングが曖昧だと、せっかく良いリードでも対応が遅れます。

BtoBでも、リードの温度感にはタイミングがあります。
問い合わせ直後。
料金ページ閲覧直後。
ウェビナー参加後。
資料ダウンロード後に再訪問した時。

こうしたタイミングを逃すと、相手の関心が下がることがあります。

営業に渡すタイミングは、リードの種類によって変えてもよいです。

・問い合わせは即時で営業通知
・料金ページ複数回閲覧は優先確認
・ウェビナー後の個別相談希望は即対応
・資料ダウンロードのみはナーチャリング
・スコア上昇リードは一定条件で確認

このようにルール化すると、対応漏れが減ります。

営業に渡すタイミングを決める時は、営業の対応可能時間も考える必要があります。
通知だけ増えても、対応できなければ意味がありません。

SQL化したら誰が見るのか。
何時間以内に対応するのか。
対応できない場合はどうするのか。

ここまで決めると、運用が安定します。

SQL化した理由を営業に伝える

SQLを営業に渡す時は、SQL化した理由を伝えることが大切です。

ただ「SQLになりました」と通知するだけでは、営業は動きにくいです。

営業が知りたいのは、なぜ今追うべきなのかです。

たとえば、次のように理由を伝えます。

・ターゲット企業で、料金ページを複数回閲覧しています
・導入事例を見た後に問い合わせしています
・ウェビナー参加後に個別相談を希望しています
・問い合わせ内容に具体的な課題があります
・同じ会社から複数名が資料をダウンロードしています

こうした情報があると、営業は初回アプローチの内容を考えやすくなります。

「資料を見ていただきありがとうございます」だけではなく、相手の関心に合わせて話せます。

SQL化理由は、営業の行動を後押しする情報です。

マーケティング側としても、なぜSQLにしたのかを言葉にすることで、基準の妥当性を確認できます。

もし理由がうまく説明できないなら、そのSQL化は少し早いかもしれません。

営業に渡す時は、リードだけでなく、営業が動く理由も一緒に渡しましょう。

フォロー期限や対応ルールを決める

SQLを営業に渡した後は、フォロー期限や対応ルールも決める必要があります。

SQL化しても、対応が遅れると商談化の可能性は下がります。
特に問い合わせや相談希望のリードは、早い対応が重要です。

ルールがないと、担当者によって対応がバラバラになります。

すぐ連絡する人もいれば、数日後になる人もいます。
メールだけ送る人もいれば、電話もする人もいます。
対応結果をCRMに残す人もいれば、残さない人もいます。

これでは、SQL基準の改善もできません。

最低限、次のようなルールを決めるとよいです。

・SQL化後、何時間以内に初回対応するか
・電話とメールのどちらを使うか
・何回までフォローするか
・つながらない場合はどうするか
・対応結果をどこに記録するか
・商談化しなかった理由をどう残すか

営業に負担をかけすぎない範囲で、対応ルールを決めることが大切です。

SQL基準は、営業に渡すところで終わりではありません。
渡した後の対応まで含めて、成果につながります。

SQLにならなかったリードの育成導線を作る

SQLにならなかったリードも、大事な見込み客です。

今すぐ営業に渡さないだけで、将来商談になる可能性はあります。

そのため、SQLにならなかったリードの育成導線を作ることが重要です。

たとえば、資料ダウンロードだけのリードには、関連する事例を送る。
ウェビナー参加後に行動がない人には、録画や補足資料を送る。
導入時期が未定の人には、比較ポイントやチェックリストを送る。
課題が浅い人には、課題整理に役立つコンテンツを送る。

このように、リードの状態に合わせて情報提供を続けます。

ナーチャリングの目的は、無理に売り込むことではありません。
相手が検討を進められるように、必要な情報を届けることです。

SQLにならなかったリードを放置すると、せっかく獲得した接点が無駄になります。
一方で、適切に育成できれば、後からSQL化することがあります。

SQL基準を作る時は、SQLにする条件だけでなく、SQLにならなかったリードをどう扱うかまで考えましょう。

SQL基準を見直すタイミング

SQL基準は、一度作ったら終わりではありません。

運用しながら見直す必要があります。

ただ、いつ見直せばいいのかわからないこともあります。

ここでは、SQL基準を見直すべきタイミングを整理します。

商談化率が下がった時

SQLから商談化する割合が下がった時は、基準を見直すタイミングです。

商談化率が下がるということは、営業に渡しているリードが商談につながりにくくなっている可能性があります。

原因はいくつか考えられます。

・SQL基準が甘くなっている
・獲得チャネルが変わった
・ターゲット外のリードが増えた
・営業対応が遅れている
・訴求と実際のサービスにズレがある
・ナーチャリングが不十分

まずは、どこで落ちているのかを見ます。

SQL数は増えているのか。
商談化率だけ下がっているのか。
特定チャネルだけ悪いのか。
特定の資料経由だけ弱いのか。

原因を分けることで、SQL基準を直すべきか、施策側を直すべきか、営業対応を直すべきかが見えてきます。

商談化率が下がった時は、焦って基準を厳しくする前に、データと営業の声を確認しましょう。

営業からリードの質に不満が出た時

営業からリードの質に不満が出た時も、SQL基準を見直すべきです。

営業の不満は、現場で何かズレが起きているサインです。

ただし、不満をそのまま受け止めるだけではなく、具体的に分解することが大切です。

「質が悪い」と言われたら、何が悪いのかを確認します。

・ターゲット外が多いのか
・連絡がつかないのか
・課題が浅いのか
・導入時期がないのか
・予算がないのか
・部署や役職が違うのか
・情報収集だけなのか

このように分解すると、改善すべき点が見えます。

営業の不満は、マーケティングへの攻撃ではありません。
SQL基準を改善するための材料です。

マーケティング側も、防御的になりすぎないことが大切です。
「リードは渡しています」と言いたくなる気持ちはわかります。
でも、営業が追いにくいなら、基準や渡し方を見直す余地があります。

営業の声をデータと合わせて見れば、SQL基準はかなり改善できます。

新しいターゲット市場を狙い始めた時

新しいターゲット市場を狙い始めた時も、SQL基準の見直しが必要です。

これまでの基準が、新しい市場にそのまま当てはまるとは限りません。

業種が変わる。
企業規模が変わる。
導入に関わる部署が変わる。
検討期間が変わる。
予算の持ち方が変わる。
刺さる課題が変わる。

このような変化があると、SQL基準も変える必要があります。

たとえば、これまでマーケティング部門向けに売っていたサービスを、営業部門向けにも広げる場合。
見るべき部署や課題が変わります。
コンテンツの反応も変わります。
営業が聞くべき情報も変わります。

新しい市場では、最初から完璧なSQL基準は作れません。
仮説を置いて、商談化や受注の結果を見ながら調整する必要があります。

新しいターゲット市場を狙う時は、これまでの成功パターンに引っ張られすぎないことが大切です。

商材や価格帯が変わった時

商材や価格帯が変わった時も、SQL基準を見直しましょう。

価格が上がれば、検討に関わる人が増えるかもしれません。
決裁者の関与が必要になるかもしれません。
予算確認の重要度が上がるかもしれません。

逆に、低価格の商材なら、より早いタイミングで営業対応してもよい場合があります。
または、営業を介さずにオンラインで完結する導線を強める方が合うかもしれません。

商材が変わると、良いSQLの条件も変わります。

・必要な企業規模
・関与する部署
・決裁者のレベル
・検討期間
・必要な予算
・営業が介在すべきタイミング

これらを見直す必要があります。

以前の基準のまま運用すると、今の商材に合わないリードをSQLにしてしまうことがあります。

商材や価格帯が変わった時は、受注しやすい条件をもう一度確認しましょう。

リード獲得チャネルが増えた時

リード獲得チャネルが増えた時も、SQL基準の見直しが必要です。

新しい広告媒体を始めた。
ウェビナーを始めた。
展示会に出た。
比較サイトに掲載した。
SEO記事からの流入が増えた。

こうした時、入ってくるリードの質は変わります。

チャネルによって、ユーザーの温度感は違います。
検索から来た人は課題が明確かもしれません。
SNS広告から来た人は、まだ潜在層かもしれません。
展示会リードは名刺交換だけで温度感に差があるかもしれません。

すべて同じ基準でSQL化すると、ズレが出ます。

チャネルごとに、SQL化の条件を少し変えることも考えましょう。

たとえば、展示会リードはアンケート内容や会話メモを重視する。
ウェビナーリードは参加後の行動を見る。
SEOリードは流入キーワードや閲覧ページを見る。
広告リードは資料テーマとその後の行動を見る。

チャネルが増えた時は、SQL基準もそれに合わせて調整する必要があります。

SQL基準を作るための実践チェックリスト

最後に、SQL基準を作る時のチェックリストを整理します。

ここまで読んできた内容を、実務で確認しやすい形にします。

新しくSQL基準を作る時にも、既存の基準を見直す時にも使えます。

ターゲット企業の条件が明確になっているか

まず確認すべきなのは、ターゲット企業の条件です。

SQLにする前に、その企業が自社のターゲットに合っているかを見ます。

業種。
企業規模。
地域。
事業内容。
導入余地。
過去の受注企業との近さ。

ここが曖昧だと、SQLの質は安定しません。

ターゲット企業の条件は、営業とマーケティングで合意しておきましょう。

「なんとなく良さそう」ではなく、「この条件なら優先する」と言える状態にします。

ターゲット外のリードをすべて除外する必要はありません。
ただし、優先度を分けることは必要です。

担当者の役職や部署を見ているか

次に、担当者の役職や部署を見ているかを確認します。

同じ企業でも、誰が反応しているかで意味が変わります。

導入検討に関係する部署か。
現場課題を持っている人か。
上司や決裁者に近い人か。
情報収集だけの人か。

ここを見ると、営業がどう動くべきかがわかります。

役職が高いから良い、低いから悪いという単純な話ではありません。
大事なのは、導入検討にどう関わる人なのかです。

部署や役職をSQL基準に入れると、営業が追いやすくなります。

課題の具体性を確認できているか

SQL基準では、課題の具体性も確認しましょう。

リードが何に困っているのか。
なぜ今情報を見ているのか。
どんな状態を解決したいのか。

ここが見えるほど、営業は会話を始めやすくなります。

課題の具体性は、問い合わせ内容、フォーム回答、閲覧ページ、ダウンロード資料、ウェビナーアンケートなどから見えます。

もし課題がまったく見えないなら、すぐSQLにするのではなく、ナーチャリングで情報を集めるのも一つです。

SQLは、営業が動くべきリードです。
営業が動くには、会話のきっかけになる課題が必要です。

導入時期や予算感を判断材料に入れているか

導入時期や予算感も、判断材料に入れましょう。

いつ頃検討しているのか。
今期なのか。
来期なのか。
時期未定なのか。
予算はあるのか。
これから予算化するのか。

こうした情報があると、営業の優先度がつけやすくなります。

ただし、最初からすべてのリードで予算が明確に見えるわけではありません。
その場合は、企業規模や課題の大きさ、導入時期の情報と合わせて判断します。

導入時期や予算感を聞く場合は、フォームで聞きすぎて離脱を増やさないように注意も必要です。

行動データを過信していないか

資料ダウンロードやページ閲覧などの行動データは重要です。

ただし、行動データだけでSQLを決めるのは危険です。

資料を見たからといって、今すぐ商談したいとは限りません。
料金ページを見たからといって、ターゲットに合っているとは限りません。
メールをクリックしたからといって、予算があるとは限りません。

行動データは、温度感を見るヒントです。
でも、営業が動くべきかを決めるには、属性情報や課題感と合わせて見る必要があります。

行動データは過信せず、組み合わせて判断しましょう。

営業とマーケティングで合意できているか

SQL基準は、営業とマーケティングで合意できているかが重要です。

マーケティングだけが納得していても、営業が動かなければ意味がありません。
営業だけの感覚で決めても、施策改善につながりにくくなります。

合意すべき内容は、次のようなものです。

・SQLにする条件
・SQLにしない条件
・営業に渡すタイミング
・営業に渡す時の情報
・フォロー期限
・商談化しなかった理由の戻し方
・見直しの頻度

ここまで決めると、運用が安定します。

SQL基準は、営業とマーケティングの共通言語です。
合意がないまま運用すると、必ずズレます。

商談化率と受注率で定期的に見直しているか

最後に、商談化率と受注率で定期的に見直しているかを確認しましょう。

SQL数だけを見ていても、基準が良いかどうかはわかりません。

SQLから商談になっているか。
商談から受注につながっているか。
どのチャネルの質が高いか。
どの条件のSQLが受注しやすいか。

ここまで見ることで、SQL基準は改善できます。

見直しは、月次や四半期で構いません。
大事なのは、放置しないことです。

SQL基準は、作った瞬間が完成ではありません。
運用しながら、営業の声とデータで磨いていくものです。

まとめ：SQLの基準は営業が動きやすく、商談化につながる形で決める

SQLの基準をどう決めるかは、BtoBマーケティングにおいてとても大事です。

リード数を増やすことは重要です。
でも、リード数だけを追っても、商談や受注につながらなければ成果とは言い切れません。

マーケティングが集めたリードを、どのタイミングで営業に渡すのか。
どんな条件なら営業が動くべきなのか。
どんなリードはまだナーチャリングすべきなのか。

この線引きがSQL基準です。

SQLはリード数を増やすためではなく商談化率を高めるためにある

SQLは、リード数を増やすための言葉ではありません。

むしろ、リードの中から営業が動くべき相手を見極めるための基準です。

資料をダウンロードした人をすべて営業に渡す。
スコアが高い人をすべてSQLにする。
問い合わせがあれば中身を見ずにSQLにする。

このような運用では、営業の工数が増え、商談化率が下がる可能性があります。

SQLの目的は、営業が成果につながるリードに集中できるようにすることです。

営業が動く理由があるリードを渡す。
まだ早いリードは育成する。
対象外のリードは無理に追わない。

この整理ができると、営業とマーケティングの連携はかなり良くなります。

SQLは、数を増やすためではなく、商談化率を高めるためにあります。

この考え方を持つだけで、基準の決め方は変わります。

属性情報、行動情報、課題感を組み合わせて判断する

SQL基準では、ひとつの情報だけに頼らないことが大切です。

企業規模や業種などの属性情報。
資料ダウンロードやページ閲覧などの行動情報。
問い合わせ内容やフォーム回答から見える課題感。

この3つを組み合わせて判断します。

属性が合っていても、行動がなければまだ早いかもしれません。
行動が強くても、ターゲット外なら優先度は下がります。
課題が具体的なら、営業は動きやすくなります。

SQLの基準を決める時は、次のように考えるとわかりやすいです。

・この会社は自社のターゲットに合っているか
・この人は導入検討に関係しているか
・何に困っているのかが見えるか
・今営業が動く理由があるか
・商談化や受注につながる可能性があるか

この問いに答えられる状態を作ることが、SQL基準づくりの基本です。

営業とマーケティングの合意がSQL基準の精度を高める

SQL基準は、営業とマーケティングの合意があって初めて機能します。

マーケティングだけで決めた基準は、営業にとって追いにくいものになることがあります。
営業だけで決めた基準は、マーケティング施策の広がりを狭めることがあります。

だから、両方の視点が必要です。

マーケティングは、リード獲得の背景や行動データを持っています。
営業は、商談化や受注の現場感を持っています。

この2つを合わせることで、SQL基準は強くなります。

営業からのフィードバックを集める。
商談化しなかった理由を分類する。
受注したリードの共通点を見る。
定例会でSQLの質を振り返る。
必要に応じて基準を変える。

この流れを作ることで、SQL基準は現場に合ったものになります。

SQL基準は、営業とマーケティングを分けるためのものではありません。
むしろ、同じ方向を見るためのものです。

基準は一度作って終わりではなく、運用しながら改善する

SQL基準は、一度作って終わりではありません。

最初から完璧な基準を作るのは難しいです。
運用してみて、初めてわかることがあります。

思ったより商談化しない。
特定チャネルの質が高い。
営業が追いやすいリードに共通点がある。
受注につながるリードの条件が見えてくる。
逆に、失注しやすいパターンも見えてくる。

こうした学びを基準に反映していくことが大切です。

SQL基準を改善する時は、感覚だけでなく、データと現場の声を使いましょう。

商談化率を見る。
受注率を見る。
失注理由を見る。
チャネル別の質を見る。
営業の評価を聞く。

この積み重ねで、SQL基準は少しずつ強くなります。

SQLの基準作りに悩んでいるなら、まずは完璧を目指さなくて大丈夫です。

最初にやるべきことは、自社にとっての良い商談を定義することです。
次に、受注リードと失注リードの特徴を見ることです。
そのうえで、営業とマーケティングで合意できる仮の基準を作ることです。

そこから運用しながら、少しずつ改善していけばいいです。

SQLの基準は、営業が動きやすく、商談化につながる形で決める。

この考え方を持てば、リード数だけを追うマーケティングから一歩進めます。

マーケティングが集めたリードを、営業が信頼して追えるようになる。
営業が動いた結果を、マーケティング施策に戻せるようになる。
商談化率や受注率を見ながら、基準を磨けるようになる。

そうなると、SQLはただの管理項目ではなくなります。
営業とマーケティングをつなぎ、売上につながるリードを見極めるための大事な仕組みになります。

リード数はあるのに商談が増えない。
営業からリードの質を指摘される。
MQLとSQLの違いが曖昧になっている。
スコアリングはあるけれど、本当に営業に渡すべきか迷う。

そんな状態なら、まずSQLの基準を見直してみてください。

いきなり大きな仕組みを作らなくても大丈夫です。
今ある受注リードを見直す。
営業に良いリードの条件を聞く。
資料請求だけでSQLにしていないか確認する。
商談化しなかった理由を分類する。

この一歩だけでも、かなり見えるものが変わります。

SQLの基準が整うと、営業もマーケティングも動きやすくなります。
そして、リード獲得が単なる数の勝負ではなく、商談と受注につながる活動に変わっていきます。

#SQL #SQL基準 #リード獲得 #リードナーチャリング #BtoBマーケティング #マーケティング #営業支援 #インサイドセールス #フィールドセールス #MQL #商談化 #商談化率 #リード管理 #MA運用 #CRM運用 #デマンドジェネレーション #営業マーケ連携 #BtoB営業 #マーケター #営業戦略