「SQLは定義しているはずなのに、営業から“このリードはまだ早い”と言われる」
「資料請求したユーザーをどこまで営業へ渡してよいのか分からない」
——そんな悩みを抱えるインサイドセールスは少なくありません。
最近は、広告施策やMA活用によってリード獲得数が増えた一方で、“営業へ渡すタイミング”の判断基準が曖昧になりやすくなっています。その結果、営業との認識ズレが起きたり、商談化率が下がったりするケースも増えています。
特に現場では、「反応があったからSQLにする」「一旦営業へ渡してみる」といった運用になってしまい、営業側で「まだ検討段階では？」と感じられることも少なくありません。
この記事では、インサイドセールスにおけるSQLの判断基準をテーマに、営業に嫌がられやすいリードの特徴や、現場で起きやすい失敗、営業とズレないSQL設計の考え方を整理していきます。単なる用語解説ではなく、「営業へ渡してよい状態をどう見極めるか？」という実務視点で解説します。
Contents
インサイドセールスでSQLが問題になりやすい理由
営業とインサイドセールスでSQLの認識が違う
インサイドセールスでSQL運用が難しくなる理由のひとつが、営業とインサイドセールスで“営業へ渡せる状態”の認識がズレやすいことです。
インサイドセールス側では、資料請求後に接触できたことや、ウェビナー参加後の反応を見て「温度感が高い」と判断することがあります。一方で営業側は、「まだ課題が整理されていない」「比較検討フェーズに入っていない」と感じているケースも少なくありません。
つまり、同じリードを見ていても、「今営業が動くべき状態なのか」の基準が揃っていないのです。
この状態が続くと、営業側では「また浅いSQLが来た」という空気が生まれやすくなります。逆にインサイドセールス側も、「せっかく渡しているのに評価されない」と感じるようになり、部門間の温度差が大きくなっていきます。
SQL運用では、単にリードを渡すことではなく、“営業が次の会話を進めやすい状態になっているか”を揃える必要があります。
「資料請求したからSQL」が危険な理由
SQL運用でよくあるのが、資料請求したリードをそのまま営業へ渡してしまうケースです。
もちろん、資料請求は興味関心を示す行動のひとつです。ただ、資料請求したユーザー全員が、すでに導入検討フェーズに入っているわけではありません。
実際には、まだ情報収集段階のケースも多くあります。
社内共有のために一旦資料を集めていることもあれば、競合比較のために幅広く情報収集していることもあります。
こうした状態のまま営業へ渡してしまうと、営業側では「まだ商談化できる状態ではない」と感じやすくなります。その結果、営業側でSQLへの信頼感が下がり、本来優先して追うべきリードまで埋もれやすくなります。
特に、MQL数や営業パス数を重視する運用では、“反応したリードを早く渡す”流れになりやすいため注意が必要です。
判断材料になるのは、反応の有無ではありません。
営業が具体的な会話を進められる状態になっているかがポイントです。
SQLの定義が曖昧なまま運用されている
SQL運用がうまくいかない企業では、そもそもSQLの定義そのものが曖昧になっているケースも少なくありません。
担当者によって、「架電できたらSQL」「課題感があればSQL」「BANTが見えたらSQL」など判断基準がバラバラになっていることがあります。
この状態では、インサイドセールス担当者ごとにSQL品質に差が出やすくなります。営業側から見ても、「なぜこのリードがSQLなのか」が分からず、認識ズレが起きやすくなります。
特に現場では、「何を確認できたら営業へ渡してよいのか」が言語化されていないケースが多く見られます。そのため、担当者ごとの感覚でSQL判断されてしまい、運用が属人化しやすくなるのです。
SQL運用では、定義を作るだけでは不十分です。
現場で迷わず判断できるレベルまで基準を具体化できているかがポイントになります。
「とにかく渡す運用」で商談化率が下がる
営業案件を増やしたいあまり、「まずは営業へ渡そう」という運用になってしまう企業も少なくありません。
特に、営業パス数そのものがKPIになっている場合は、“質”より“件数”が優先されやすくなります。
その結果、まだ比較検討段階に入っていないリードまで営業へ渡され、どの案件から対応すべきか判断しづらくなります。
こうした状態が続くと、営業側でも「また浅いSQLではないか」という感覚が強くなり、SQL自体の信頼度が下がっていきます。すると、本来すぐ追うべきリードまで後回しにされやすくなり、最終的には商談化率そのものが落ちていきます。
インサイドセールスでは、「どれだけ渡したか」が評価されやすい場面もあります。ただ、件数だけを追えばよいわけではありません。
営業が“今追いたい”と思える状態で渡せているかが、SQL運用の質を左右します。
インサイドセールスにおけるSQLの判断基準とは？
そもそも「営業に渡せる状態」とは？
SQL判断では、単に「興味を持っているか」だけでは十分ではありません。
本来のSQLとは、営業が次の具体的なアクションを取りやすい状態になっているリードを指します。
たとえ問い合わせや資料請求があっても、
「なぜ今検討しているのか」
「どんな課題があるのか」
「導入した場合に何を改善したいのか」
といった背景が見えていなければ、営業側でも会話を進めにくくなります。
逆に、検討背景や課題感がある程度整理されているリードは、営業側でも提案やヒアリングを深めやすくなります。
つまりSQL判断では、“反応したか”よりも、“営業が次の会話を進めやすい状態か”を見ることが重要です。
SQL判断で見られる主なポイント
SQL判断では、スコアや行動履歴だけでなく、「商談につながる情報が見えているか」が重要になります。
特に現場では、課題感・検討背景・導入イメージ・優先度などを総合的に見ながら判断されるケースが多くなっています。
課題が顕在化している
SQL判断では、相手自身が課題を認識できているかを確認したいところです。
営業管理の属人化や、問い合わせ対応の遅れ、リード対応の負荷など、「何に困っているのか」が整理されているリードは、営業側でも会話を進めやすくなります。
一方で、「なんとなく情報収集している」段階では、まだ比較検討フェーズに入っていないことも少なくありません。
特にBtoB商材では、課題認識が曖昧なままでは商談が進みにくいため、SQL判断でも確認しておきたい項目です。
導入背景が整理できている
SQLでは、「なぜ今検討しているのか」が見えているかも判断材料になります。
例えば、営業人数の増加によって管理が追いつかなくなっていたり、展示会後のリード対応に限界を感じていたりすると、営業側でも提案の方向性を考えやすくなります。
逆に、背景が見えない状態では、営業側でも「どこから会話を始めればよいのか」が分かりにくくなります。
ツール比較だけが先行しているケースもあります。そのため、単なる興味関心ではなく、“なぜ今動いているのか”まで確認できているかが判断材料になります。
具体的な運用イメージが見えている
SQLでは、導入後のイメージがある程度見えているかも判断材料になります。
営業とマーケで情報共有したいのか、問い合わせ対応を効率化したいのか、それともSQL判断を標準化したいのか。改善したい内容が整理されているリードは、比較的商談につながりやすい傾向があります。
逆に、「何ができるのかを知りたい」という状態では、まだ情報収集フェーズに近い可能性があります。
もちろん、最初から詳細な運用設計まで固まっている必要はありません。
ただ、少なくとも「導入後にどんな状態を目指したいのか」が見えているかは確認しておきたいポイントです。
時期感・優先度が確認できている
SQLでは、導入時期や優先度も重要な判断材料になります。
ただし、ここで重要なのは「今すぐ導入するか」だけではありません。
最近は、すぐに導入を決める企業ばかりではありません。
社内で課題整理や比較検討を進めながら、数か月かけて意思決定するケースもあります。
そのため、「今すぐ客かどうか」だけで判断しないことが大切です。
営業側としては、「今どれくらい検討が進んでいるのか」が分かるだけでも、対応優先順位を決めやすくなります。
逆に、時期感や優先度が全く見えない状態では、営業側でもどこまで深く提案すべきか判断しづらくなります。
SQLでは、“今すぐ客かどうか”ではなく、“どれくらい検討が進んでいるか”を見ることが大切です。
BANTはどこまで必要なのか
SQL判断では、BANTをどこまで確認すべきか悩む企業も少なくありません。
BANTとは、予算・決裁権・必要性・導入時期を整理する考え方です。
ただ、最近のBtoB営業では、最初の接触段階でこれらがすべて揃うケースはそこまで多くありません。
担当者レベルでは予算が未確定なこともありますし、決裁者がまだ見えていないこともあります。
そのため、「BANTが全部揃わないとSQLではない」と考えすぎると、逆に有望リードを逃してしまうケースがあります。
BANTをすべて満たしているかどうかだけで判断する必要はありません。
営業側が次の会話を進めるうえで、どこまで情報が見えているか。その状態を整理できているかが重要です。
特に最近は、比較検討初期から情報収集を進める企業も増えています。そのため、完全な条件一致よりも、“営業が会話を深められる状態か”を重視する企業が増えています。
「温度感が高い」だけで判断してはいけない理由
インサイドセールスでは、「反応が良かった」「会話が盛り上がった」という理由で営業へ渡したくなることがあります。
ただ、実際には“温度感が高い”と“商談化しやすい”は必ずしも一致しません。
話自体は盛り上がっていても、まだ社内課題が整理されていないケースもあります。逆に、反応自体は落ち着いていても、比較検討がかなり進んでいるケースもあります。
営業側が必要としているのは、“会話の盛り上がり”ではなく、“次の提案につながる情報”です。
そのため、反応の良さだけで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化するよりも、ナーチャリングを通じて比較検討フェーズへ引き上げた方が成果につながることもあります。
導入時期や運用イメージが見えていない
営業側で対応優先度を決めにくいのが、導入時期や運用イメージが全く見えていないリードです。
まだ「情報を見始めたばかり」という段階では、営業側でもどこまで具体的に提案すべきか判断しづらくなります。
特にBtoB商材では、導入までに社内調整や比較検討期間が必要になるケースも多くあります。そのため、「いつ頃を想定しているのか」「どんな運用をイメージしているのか」がある程度見えているだけでも、ヒアリングの入口から探る必要が出てきます。
逆に、この部分が全く整理されていない状態では、商談が進む前に止まってしまいやすくなります。
インサイドセールスでは、単に興味度を見るだけではなく、“導入後のイメージがどれくらい具体化しているか”も重要な判断材料になります。
「とりあえず問い合わせ」が目的化している
最近は、「まずは問い合わせしてみる」という行動自体のハードルが下がっています。
そのため、まだ検討が進んでいない段階でも、とりあえず資料請求や問い合わせをするケースは珍しくありません。
ただ、この段階では、
「社内課題が整理されていない」
「比較検討の軸が決まっていない」
「誰が導入判断するかも決まっていない」
といった状態になっていることもあります。
この状態で営業へ渡してしまうと、営業側でも会話が深まりづらく、「まだ早いリード」という印象になりやすくなります。
特に、“問い合わせがあった＝営業案件”として扱ってしまう運用では、SQL品質が不安定になりやすくなります。
問い合わせ自体は重要なシグナルです。ただ、本当に見るべきなのは、“問い合わせ後にどこまで検討が進んでいるか”です。
SQL判断で失敗する企業の共通課題
営業フィードバックが機能していない
SQL運用がうまくいかない企業では、営業からのフィードバックが止まっているケースがあります。
営業側では「このSQLはまだ浅い」と感じていても、具体的な理由が共有されないまま終わっていることも少なくありません。
すると、インサイドセールス側では「何が悪かったのか」が分からず、同じようなSQLを渡し続けてしまいます。
逆に営業側でも、「どうせ改善されない」という感覚が強くなると、フィードバック自体が減っていきます。
この状態が続くと、営業とインサイドセールスの間で認識ズレがどんどん大きくなっていきます。
SQL運用では、単にリードを渡すことよりも、“営業がどう感じたか”を継続的に共有できる状態が重要です。
インサイドセールスごとに基準が違う
SQL運用でよくあるのが、担当者ごとに判断基準が変わってしまうケースです。
ある担当者は「反応が良ければSQL」と判断していても、別の担当者は「導入背景まで確認できないと渡さない」と考えていることがあります。
この状態では、営業側から見てもSQL品質にバラつきが出やすくなります。
特に、会話内容を個人の感覚で判断している企業では、属人化が起きやすくなります。
インサイドセールスでは、コミュニケーション能力が高い担当者ほど、“なんとなく良さそう”で判断してしまうこともあります。
ただ、SQL運用では感覚だけに頼るのではなく、「どこまで確認できたら営業へ渡すのか」を共通化することが重要です。
スコアリングだけで判断している
MAツールやSFAを活用している企業では、スコアリングをSQL判断に使っているケースもあります。
もちろん、行動履歴を可視化すること自体は重要です。ただ、スコアだけでSQL判断してしまうと、実際の検討状況とズレることがあります。
例えば、複数回サイト訪問していても、まだ情報収集段階のケースはあります。逆に、行動数自体は少なくても、社内検討がかなり進んでいるケースもあります。
特にBtoBでは、単純な行動量だけで検討温度を測りきれないことも少なくありません。
そのため、SQL判断ではスコアだけを見るのではなく、会話内容や課題感、検討背景まで含めて見ることが重要になります。
「渡した件数」が評価軸になっている
SQL運用が崩れやすい企業では、「どれだけ営業へ渡したか」が評価指標になっていることがあります。
この状態では、どうしても“質”より“件数”が優先されやすくなります。
その結果、まだ比較検討が進んでいないリードまで営業へ渡され、営業側では「本当に追うべき案件」が埋もれやすくなります。
インサイドセールス側としても、件数を求められると「まずは営業へ渡そう」という判断になりやすくなります。
ただ、本来重要なのは“何件渡したか”ではありません。
営業側で実際に商談化できているのか。その後の受注につながっているのか。そこまで含めて見ないと、SQL運用は改善しにくくなります。
SQL化率と商談化率を分けて見れていない
SQL運用では、SQL化率だけを見てしまう企業も少なくありません。
確かに、どれだけSQLへ引き上げられたかは把握しておきたい指標です。
ただ、それだけでは“営業に渡す質”までは見えてきません。
SQL件数が増えていても、その後の商談化率が下がっている場合、営業へ渡すタイミングが早すぎる可能性があります。
逆に、SQL数は少なくても商談化率が高い場合は、判断基準が整理されているケースもあります。
SQL件数だけでは運用の良し悪しは判断できません。
営業が実際に前へ進められる状態で渡せているかまで確認することが大切です。
SQL運用では、件数だけでなく、その後の商談化率まで含めて確認したいところです。
営業とズレないSQL基準を作る方法
営業が「追いたい」と思う条件を書き出す
SQL基準を整理するうえで最初に重要なのが、「営業がどんな状態なら追いたいと思うのか」を言語化することです。
インサイドセールス側では、「反応が良かった」「興味を持っていそうだった」という感覚で判断していても、営業側では別のポイントを重視していることがあります。
例えば、営業側では、
- 課題感が整理されている
- 比較検討が始まっている
- 導入背景が見えている
といった情報を重視しているケースがあります。
逆に、温度感が高く見えても、まだ社内検討が進んでいない状態では「今は優先度が低い」と判断されることもあります。
大切なのは、“一般論のSQL”ではなく、自社に合った基準を作ることです。
実際に営業が「この状態なら追いやすい」と感じる条件を整理することで、営業とインサイドセールスの認識ズレを減らしやすくなります。
失注理由から逆算してSQL条件を見直す
SQL基準を作る際は、「商談化した案件」だけを見るのではなく、失注理由も重要なヒントになります。
営業側で、
「まだ検討段階だった」
「課題が整理されていなかった」
「導入時期が遠かった」
と感じる案件が多い場合、営業へ渡すタイミングが早すぎる可能性があります。
逆に、「もっと早く接触したかった」という声が多い場合は、SQL条件が厳しすぎるケースもあります。
SQL運用では、“どれだけ渡したか”より、“なぜ進まなかったのか”を見ることが重要です。
特に現場では、営業とインサイドセールスで感覚的にズレているケースも多いため、失注理由を整理すると改善ポイントが見えやすくなります。
SQL基準を定期的にアップデートする
SQL基準は、一度決めたら終わりではありません。
営業体制や商材、ターゲット企業が変わると、「営業へ渡すべき状態」も変わっていきます。
例えば、新サービス立ち上げ時は比較的広めにSQL化していた企業でも、営業リソース不足によって基準を厳しく見直すケースがあります。
逆に、インサイドセールス体制が整ってきたことで、以前より早い段階から営業連携する企業もあります。
また、最近は比較検討期間が長くなっている業界も多く、以前の基準が現場に合わなくなっているケースも少なくありません。
SQL運用では、「今の営業現場に合っているか」を継続的に見直していく視点が欠かせません。
運用を固定化するのではなく、現場の状況に合わせて調整し続ける視点が必要になります。
営業・マーケ・ISで共通認識を持つ
SQL運用では、営業だけでも、インサイドセールスだけでも改善しきれません。
特に現場で起きやすいのが、
マーケ：「反応しているリードを増やしたい」
IS：「営業へ渡せる件数を増やしたい」
営業：「商談化しやすい案件だけ追いたい」
という、それぞれのKPIのズレです。
どれも間違っているわけではありません。ただ、この状態が続くと、「どんな状態をSQLとするか」の認識がズレやすくなります。
結果として、営業側では「質が低い」と感じ、インサイドセールス側では「せっかく渡しているのに評価されない」と感じるようになります。
SQL運用では、営業・マーケ・ISが同じ基準で判断できる状態を作ることが欠かせません。
会話ログを活用してSQL判断を標準化する
SQL運用が属人化しやすい企業では、「なんとなく良さそう」という感覚で判断されているケースがあります。
ただ、この状態では担当者によってSQL品質に差が出やすくなります。
そこで効果的なのが、会話ログの活用です。
どんな課題を話していたのか、どこに興味を示していたのか、比較検討は進んでいるのか。こうした情報を蓄積できるようになると、「どの状態をSQLとするか」が整理しやすくなります。
会話履歴や行動履歴をSFA・CRM上で共有する企業もあります。
営業側でも過去の会話内容を把握できるようになるため、「なぜこのリードがSQLなのか」が見えやすくなります。
SQL運用では、担当者の感覚だけに頼るのではなく、“会話内容をもとに判断基準を揃えること”が重要です。
インサイドセールスでSQL管理を効率化する方法
SQL判断を属人化させないポイント
SQL運用では、担当者ごとに判断基準がズレてしまうケースが少なくありません。
会話が上手い担当者ほど、「感覚的に良さそう」という判断で営業へ渡してしまうこともあります。
ただ、属人化した状態では、営業側から見てもSQL品質が安定しなくなります。
そのため重要なのは、「どんな情報が確認できたら営業へ渡すのか」を整理しておくことです。
課題感、導入背景、比較検討状況、優先度など、営業が必要とする情報を共通化しておくことで、担当者ごとの差が出にくくなります。
SQL運用では、個人の経験や勘だけに頼るのではなく、“誰が対応しても一定品質で判断できる状態”を作ることが重要です。
会話ログ・スコア・行動履歴を一元管理する
SQL判断では、「どんな会話をしたのか」だけでなく、「その後どんな行動を取ったのか」も重要になります。
例えば、資料閲覧履歴やウェビナー参加状況、メール反応などを確認できると、検討状況を把握しやすくなります。
ただ、会話履歴と行動履歴が分断されていると、営業側でも全体像を把握しづらくなります。
特に現場では、「インサイドセールスは状況を知っていたのに、営業側に共有されていなかった」というケースも少なくありません。
会話ログ・スコア・行動履歴を一元管理できるようになると、「なぜこのリードがSQLなのか」を営業側でも理解しやすくなります。
その結果、営業との認識ズレも減らしやすくなります。
営業との情報共有をスムーズにする
SQL運用では、「どんなリードを渡すか」だけでなく、“どう共有するか”も重要です。
営業側でよくある不満のひとつが、「背景が分からないまま案件だけ渡される」という状態です。
どんな課題を感じていたのか、何に興味を持っていたのか、どこまで比較検討が進んでいるのか。こうした情報が整理されていないと、会話の切り口を見つけにくくなります。
特に最近は、問い合わせ前の段階でかなり情報収集が進んでいるユーザーも増えています。
そのため、営業側で毎回ゼロからヒアリングを始めてしまうと、ユーザー側でも「また同じ説明をするのか」と感じやすくなります。
営業連携では、単にリードをパスするのではなく、“営業が次の会話に入りやすい状態まで情報共有できているか”が重要です。
AIを活用したリード整理・優先順位付け
AIを活用した運用も選択肢のひとつになっています。
特にインサイドセールスでは、対応リード数が増えるほど、「どのリードを優先すべきか」が分かりにくくなります。
すべてのリードを同じ熱量で追うのは現実的ではありません。そのため、会話内容や行動履歴をもとに、優先順位を整理する仕組みが重要になります。
最近のAI機能では、
- 会話内容の要約
- 検討温度の整理
- 行動履歴の分析
- 優先度の可視化
などをサポートできるツールも増えています。
特に、担当者ごとの感覚差を減らしたい企業では、AIを活用して判断基準を整理するケースも増えています。
SQL運用では、「とにかく件数を増やす」のではなく、“今どのリードを優先すべきか”を整理できる状態が重要です。
よくある質問（FAQ）
SQLとMQLは何が違いますか？
MQLは、マーケティング施策によって興味関心が高まったリードを指します。
一方でSQLは、営業が具体的なアプローチを進めやすい状態まで進んだリードです。
つまり、MQLは“育成対象”、SQLは“営業接続対象”というイメージに近くなります。
ただし、実際の現場では明確な線引きが難しいことも多く、営業体制や商材によって判断基準が変わるケースもあります。
BANTが揃わないとSQLではありませんか？
最近は、初回接触の段階でBANTがすべて揃うケースの方が少なくなっています。
課題感や検討背景が見えていれば、営業側でヒアリングを深められることもあります。
そのため、BANTをすべて満たしているかどうかだけでSQL判断する企業はそれほど多くありません。
SQL化率の目安はありますか？
SQL化率は業界や商材によって大きく変わるため、「何％なら良い」という共通の基準はありません。
むしろ見るべきなのは、その後の商談化率や受注率です。SQL数が増えていても商談につながっていなければ、判断基準を見直す必要があります。
営業から「質が悪い」と言われた時はどうすればいいですか？
営業から「質が悪い」と言われた場合は、まず具体的な理由を確認してみましょう。
課題感が浅かったのか、比較検討が進んでいなかったのか、優先度が見えていなかったのかによって改善ポイントは変わります。
「質が悪い」という言葉だけで終わらせず、営業がどんな状態なら追いやすいのかを擦り合わせることが大切です。
SQL判断は誰が決めるべきですか？
SQL判断は、インサイドセールスだけで決めるものではありません。
営業・マーケ・インサイドセールスの3部門で共通認識を持つことが大切です。
特に現場では、営業側とインサイドセールス側で「営業へ渡すべきタイミング」の感覚がズレやすくなります。
そのため、定期的に失注理由や商談化率を振り返りながら、基準を調整していくことが重要です。
まとめ｜SQL判断を見直すと営業との連携は変わる
インサイドセールスにおけるSQL運用では、「どれだけ営業へ渡したか」だけでなく、“営業が次の会話を進めやすい状態か”を見ることが重要です。
資料請求や反応だけで判断してしまうと、営業側との認識ズレが起きやすくなります。その結果、「また浅いSQLではないか」という不信感につながり、本来追うべきリードまで埋もれてしまうことがあります。
重要なのは、課題感・検討背景・優先度などを整理しながら、“営業が追いたいと思える状態”を作ることです。
また、SQL運用は一度決めたら終わりではありません。営業体制や市場状況に合わせて、継続的に見直していくことが重要です。
営業・マーケ・インサイドセールスが共通認識を持ちながら運用できるようになると、商談化率や営業効率も改善しやすくなります。
インサイドセールスのSQL管理なら、サスケ
SQL判断では、「どこまで確認できたら営業へ渡すべきか」が曖昧になりやすく、担当者ごとの差も出やすくなります。
特に、会話履歴・行動履歴・検討状況が分散している状態では、営業側との認識ズレも起きやすくなります。
クラウドサービス サスケは、リード情報・行動履歴・会話ログを一元管理しながら、営業とインサイドセールスの連携をスムーズにできるSFA/CRM/MAツールです。
AI機能も搭載されており、リードの優先順位整理や情報共有の効率化もサポートできます。
「営業へ渡すべきタイミングが分からない」
「SQL判断を標準化したい」
「営業との認識ズレを減らしたい」
そんな企業は、SQL運用の見直しとあわせて、管理体制そのものを整理してみるのもおすすめです。
投稿者
- サスケ(saaske)マーケティングブログは、新規営業支援ツール「クラウドサービス サスケ」のオウンドメディアです。筆者はサスケのマーケティング担当です。SFA、CRM、MA、テレアポ、展示会フォローなど、営業支援のSaaSツールにまつわる基礎知識や実践方法などをお伝えしていきます。
