SQLは完成形ではない ――マーケが渡した“仮の検討度”を、営業接点で修正するという考え方
目次
はじめに
マーケティングがSQL（Sales Qualified Lead）を営業に引き渡したあと、現場でこのような会話が交わされた経験はないでしょうか。
「アクションはあるが、温度感が全然違った」
「まだ検討以前の段階で、社内の合意も取れていない」
「スコアは高いが、具体的な話ができる状態ではない」
マーケ側は「行動データに基づき、基準を超えたから渡した」と言い、営業側は「実態と数字が乖離している」と不満を抱く。このズレは、どちらかが間違っているから起きるわけではありません。そもそも、SQLを“完成形”として扱っている前提に無理があるのです。
本記事では、SQLを「未完成の仮説」と定義し、営業接点で“修正”されることで初めて真の価値を持つという考え方を整理します。
マーケが見ているのは「検討の内実」ではなく「行動の結果」
まず、マーケティングが定義するSQLの正体を再確認しましょう。多くの場合、SQLは以下のような「デジタル上の足跡」を根拠にしています。
- Webサイトの閲覧履歴、特定のページの滞在時間
- ホワイトペーパーのダウンロード
- メールの開封・クリック
- ウェビナーの参加履歴
- 理解度： 顧客が自社の課題をどこまで言語化できているか
- 未整理事項： 導入にあたって何がボトルネックになっているか
- 意思決定： 誰がキーマンで、社内の合意形成はどの段階か
なぜ営業接点で「検討度合い」は非連続に変化するのか
検討度合いは、資料を読んだ量に比例して直線的に進むものではありません。現実は、「人と話した瞬間」に、検討のフェーズが非連続にジャンプ、あるいは後退します。
観測の場としての営業接点
- どの言葉に反応し、どこで説明を求められるか
- 既存システムとの整合性をどう考えているか
- 予算確保の優先順位はどの程度か
「修正」をネガティブに捉えない組織文化
ここで重要なのは、営業が行うのは「マーケの仕事の否定」ではなく、「仮説の現実への上書き」であるという共通認識です。
| 捉え方 | 修正を「失敗」と見なす組織 | 修正を「プロセス」と見なす組織 |
| SQLの定義 | 確度の高い「完成品」 | 精度を高めていく「中間成果物」 |
| 営業の役割 | 渡されたリードを捌く | 仮説を検証し、事実をフィードバックする |
| 関係性 | 責任の押し付け合いが発生 | 共通の「顧客理解」を深めるパートナー |
「SQL＝完成品」という構図で捉えてしまうと、修正が発生するたびにマーケと営業の関係は歪みます。
「修正」の精度を上げる4つの分解軸
修正を単なる「ホット / コールド」といった1軸の温度感の付け替えにしてしまうと、戦略的なフィードバックになりません。実務上は、検討度合いを以下の4つの軸で分解して扱うことを推奨します。
| 項目 | マーケの仮説（行動データ） | 営業による修正（対話事実） |
| 課題の言語化 | 資料DLから「課題あり」と推定 | 明確 ／ 曖昧 ／ 未整理 |
| 解決手段の理解 | 特定ページ閲覧から「理解あり」 | 具体的 ／ 比較中 ／ 未理解 |
| 意思決定構造 | 役職名から「決裁者」と推定 | 単独 ／ 合議 ／ 不明 |
| タイムライン | スコア上昇から「今期」と推定 | 今期 ／ 来期 ／ 未定 |
営業が接点でこれらの項目を「事実」として上書きすることで、CRM上のデータは初めて「生きた情報」へと進化します。
修正が回ると、マーケティングが変わる
この修正プロセスがCRMに蓄積されると、マーケティング施策に劇的な変化が起きます。
「特定の施策からのSQLは、解決手段の理解で必ずつまずいている」
「来期検討の層が想定以上に多いので、中長期のナーチャリングを強化しよう」
「営業が何度も説明している共通の不明点を、コンテンツで解消しよう」
これらは行動データだけでは見えなかった「市場の構造」です。営業による修正は、単なる後処理ではなく、次のマーケティング投資を最適化するための最上質な「一次情報」になります。
おわりに｜修正を前提にすると、連携は強くなる
検討度合いとは、測定して固定する数値ではなく、対話によって更新され続ける仮説です。
- マーケは「幻想的な成熟度」を追うのをやめる。
- 営業は「属人的な感覚」ではなく「事実の上書き」に注力する。
- CRMは「修正の履歴」として組織の資産になる。