この記事の要約
「リードが増えているのに商談が増えない」という報告の裏側には、たいてい部門ごとに違う「リード」の定義が隠れています。マーケが名刺獲得の時点でリードとカウントし、インサイドセールスは電話がつながった時点でカウントし、営業は初回訪問を終えた時点でようやくカウントする。同じ言葉を使いながら、実は誰も同じものを数えていない状態です。
本記事では、リードから顧客に至るまでの各段階（ステージ）をどう定義し、部門間で共通言語として運用するかを、MQL・SQL・商談化・受注といった実務上の区切りに沿って整理します。
読後は、自社のリード定義のズレがどこで発生しているかを特定し、SFA・CRM上でステージを再設計するための具体的な手順と判断基準を持ち帰ることができます。抽象的な「連携強化」ではなく、定義の言葉と数値基準そのものを揃える方法にフォーカスした内容です。
この記事でわかること
- リードの定義が部門間でズレる典型的な原因と、その発生メカニズム
- MQL・SQL・商談・受注という各ステージに必要な「移行条件」の設計方法
- ステージ定義をSFA・CRM上のフィールドや自動化ルールに落とし込む具体的な手順
- 定義をそろえた後も形骸化させないための運用・見直しの仕組み
- 定義統一プロジェクトを進める際に、マーケ・インサイドセールス・営業の間で起きやすい対立とその調整方法
はじめに
月次のパイプラインレビューで、マーケ責任者が「今月はリードが150件増えました」と報告した直後に、営業責任者が「そんなに増えている実感はまったくない」と返す。こうしたやり取りに覚えはないでしょうか。実はこの食い違い、どちらかが嘘をついているわけでも、数字を盛っているわけでもありません。
単に「リード」という言葉が指すものが、部門ごとに違うだけなのです。フォームを送信した人をリードと呼ぶ部署もあれば、実際に商談の見込みがあると判断された人だけをリードと呼ぶ部署もあります。この定義のズレを放置したまま追いかけるKPIは、いくら精緻に見えても組織の意思決定を誤らせます。本記事では、この「見えない翻訳のズレ」を解消するための、顧客段階（ステージ）設計の具体的な進め方を解説します。
なぜ「リード」の数え方は部門ごとに割れるのか
結論から言うと、リード定義のズレは悪意や怠慢ではなく、各部門が自分の業務プロセスの起点を「リード」と呼んでいるために起こります。マーケにとってのリードは「獲得した見込み客リスト」であり、インサイドセールスにとってのリードは「架電すべき対象」であり、営業にとってのリードは「商談化して初めて意味を持つ案件」です。
それぞれの定義自体は、その部門の業務に照らせば間違っていません。問題は、この三者が同じ「リード数」という言葉を共有ダッシュボード上で並べてしまうことにあります。
部門ごとの「リード」が指すものの違い
具体的には、次のような違いが典型的です。
| 部門 | リードと呼ぶ対象 | カウントのタイミング |
|---|---|---|
| マーケティング | フォーム送信・資料DL・イベント来場者 | 接点発生時点 |
| インサイドセールス | 電話・メールで接触に成功した相手 | 初回コンタクト成立時点 |
| 営業 | ニーズを確認し商談に進めた相手 | 商談設定時点 |
この表を見て「うちも同じだ」と感じた担当者は少なくないはずです。マーケは母数として広く数え、営業は絞り込んだ後の質で数える。どちらも自部門のKPIとしては合理的な行動ですが、経営層がこの数字をそのまま「パイプラインの健全性」として比較すると、実態とかけ離れた判断につながります。
定義のズレが引き起こす3つの実害
このズレを放置すると、単なる用語の混乱にとどまらず、実務上の損失が発生します。
- マーケの成果が正しく評価されない：リード数は増えているのに商談化率が低く見え、施策の効果測定を誤る
- 営業がマーケ由来のリードを軽視する：定義が甘いリードを何度も追わされた経験から、営業側がマーケ経由の情報を疑うようになる
- 経営会議の数字が部門間で矛盾する：同じ月のリード数について、資料によって数字が異なり、意思決定の土台自体が揺らぐ
これらはすべて、ツールの性能や個人の能力の問題ではなく、定義という「共通言語」が組織内に存在しないことが原因です。ここを直さない限り、SFAやCRMをどれだけ高度化しても数字の食い違いは再発します。
顧客段階（ステージ）をどう区切るか：基本設計の考え方
定義をそろえるには、まず「リードから顧客まで、何段階に区切るか」という設計そのものを決める必要があります。段階が細かすぎれば運用が形骸化し、粗すぎれば部門間の実態を反映できません。
基本となる5段階モデル
多くのBtoB企業で機能しやすいのは、次のような5段階の設計です。
- リード（Lead）：何らかの接点が発生した状態
- MQL（Marketing Qualified Lead）：マーケティング基準で見込みありと判定された状態
- SQL（Sales Qualified Lead）：営業基準で見込みありと判定された状態
- 商談（Opportunity）：具体的な検討プロセスに入った状態
- 顧客（Customer）：契約・受注が確定した状態
重要なのは、この名称そのものよりも、各段階の間に明確な「移行条件」が存在するかどうかです。名称だけ整えても、移行条件が曖昧なままでは元の木阿弥になります。
移行条件は「行動」と「属性」の掛け合わせで設計する
移行条件を設計する際、担当者がよく陥る失敗は、属性情報（役職・企業規模・業種など）だけで判定しようとすることです。属性が合致していても、その人が今まさに検討段階にあるとは限りません。逆に行動（資料DL・価格ページ閲覧・複数回訪問など）だけで判定すると、単なる情報収集目的の閲覧者まで拾ってしまいます。
そこで実務上有効なのが、属性条件×行動条件の掛け合わせで移行条件を組む方法です。例えば、MQLへの移行条件を次のように設計します。
- 属性条件：従業員数50名以上、かつ決裁関与が想定される部署の役職者
- 行動条件：直近30日以内に価格ページを2回以上閲覧、または資料を2件以上ダウンロード
このように条件を組み合わせることで、「なんとなく見込みがありそう」という感覚的な判定から、再現性のある基準へと移行できます。
SQL以降の移行条件は「営業活動の事実」で設計する
MQLからSQL、SQLから商談への移行条件は、マーケ由来の属性・行動データだけでは判定しきれません。この段階では、営業担当者が実際に接触して得た一次情報を条件に組み込む必要があります。例えば次のような条件です。
- SQLへの移行条件：初回商談で予算・決裁プロセス・導入時期のいずれかが具体的に語られている
- 商談への移行条件：次回アクション（見積提示・稟議資料の共有など）が双方合意のもとで設定されている
ここで避けたいのは、「営業が主観で良さそうと思ったらSQL」という運用です。主観的な判定は担当者ごとにブレが生じやすく、定義をそろえた意味が薄れます。判定根拠を選択式の項目としてCRMに残す設計にしておくと、後から「なぜこの案件がSQLになったのか」を検証できるようになります。
段階の境界を部門間の引き渡しとして設計する考え方は、次の記事で整理しています。
定義をそろえる実務プロセス：合意形成から運用まで
ステージ設計の理屈が整理できても、それを部門横断で「合意」させる作業がなければ絵に描いた餅で終わります。ここからは、実際に定義をそろえるための進め方を段階的に解説します。
ステップ1：現状の定義を可視化する
最初にやるべきことは、新しい定義を作ることではなく、今すでに各部門が使っている定義を洗い出すことです。マーケ・インサイドセールス・営業それぞれに、「あなたたちが今、リード・MQL・SQL・商談と呼んでいるものは、具体的にどんな条件を満たした状態か」をヒアリングします。この段階で驚くほど条件が言語化されていないケースが多く、「なんとなく感覚で判断している」という回答が返ってくることも珍しくありません。
ステップ2：ギャップを一覧化し、優先度の高いズレから着手する
洗い出した定義を並べると、どこにギャップがあるかが見えてきます。すべてのギャップを一度に解消しようとすると合意形成が長期化するため、商談化率やパイプライン報告に直結するギャップから優先的に着手するのが現実的です。特に、マーケとインサイドセールスの間にある「リード→MQL」の境界と、インサイドセールスと営業の間にある「MQL→SQL」の境界は、多くの企業で最も摩擦が大きい箇所です。
ステップ3：仮運用期間を設けて条件を検証する
新しい移行条件は、いきなり本運用に切り替えるのではなく、1〜2か月の仮運用期間を設けて実データで検証することをおすすめします。仮運用中は、旧定義と新定義の両方でリードをカウントし、数値のブレ幅を確認します。この段階で、条件が厳しすぎて商談化すべきリードを取りこぼしていないか、逆に緩すぎて営業の負荷が増えていないかをチェックします。
ステップ4：SFA・CRM上に定義を実装する
検証を経た定義は、口頭やドキュメントの合意だけで終わらせず、SFA・CRM上のステータスフィールドと自動化ルールとして実装します。具体的には次のような実装が考えられます。
| 実装項目 | 内容 |
|---|---|
| ステータスフィールドの標準化 | リード・MQL・SQL・商談・顧客の各ステータスを全社共通の選択肢として定義 |
| 自動昇格ルール | 属性条件×行動条件を満たした時点で自動的にMQLへ昇格させるワークフロー |
| 手動判定の記録項目 | 営業が「SQL」と判定した根拠を選択式で入力させ、感覚的な判定を防ぐ |
| ステージ滞留アラート | 一定期間ステータスが動かないリードを自動検知し、担当者に通知 |
ここで意識したいのは、システム実装が先ではなく、定義の合意が先という順序です。合意なきままシステムだけ整備すると、現場は入力ルールを守らなくなります。
部門間の役割分担も同時に明文化する
ステージ定義だけを整えても、「誰がその移行を判定し、誰がフォローするのか」という役割分担が曖昧なままでは、結局は現場の裁量に戻ってしまいます。定義とセットで、次のような責任分担表を作成しておくことをおすすめします。
| ステージ | 主な担当部門 | 判定・更新の責任者 | 次アクションの起点 |
|---|---|---|---|
| リード〜MQL | マーケティング | マーケ担当者 | 自動昇格ルールによる通知 |
| MQL〜SQL | インサイドセールス | インサイドセールス担当者 | 架電・ヒアリング結果の入力 |
| SQL〜商談 | 営業 | 営業担当者 | 初回商談後のステータス更新 |
| 商談〜顧客 | 営業・契約関連部門 | 営業マネージャー | 見積・契約プロセスの進行 |
この表を作る過程で、境界線の判定者が誰なのか誰も決めていなかった事実が発覚することも珍しくありません。定義と役割は、常にセットで設計するという意識が、運用を安定させる鍵になります。
マーケティングから営業へ渡す基準と差し戻しの運用は、次の記事を参照してください。
定義を「形骸化」させないための運用設計
定義をそろえるプロジェクトが最も失敗しやすいのは、初期導入時ではなく、導入から数か月後の運用フェーズです。担当者の異動や業務多忙を理由に、いつの間にか元の感覚的な判断に戻ってしまうケースが後を絶ちません。
定期的な定義レビューの場を設ける
四半期に一度など、定義そのものを見直す会議体を設けることが有効です。市場環境や商材の変化に応じて、MQLやSQLの条件も変化して当然だからです。定義は一度決めたら固定するものではなく、事業の実態に合わせて更新し続けるものという前提を、関係者間で共有しておく必要があります。
現場からの「違和感」を吸い上げる仕組み
営業やインサイドセールスの現場では、「この条件でSQLに上がってくる案件、正直あまり質が良くない」といった違和感が日常的に発生します。こうした声を拾い上げず放置すると、現場は正式なルールを無視して独自の判断基準に戻ってしまいます。定義変更の提案を受け付ける簡易的なフォームやSlackチャンネルを用意し、違和感を正規のフィードバックとして扱う導線を作っておくことが、形骸化を防ぐ実務的な工夫になります。
定義変更時の確認チェックリスト
定義を見直す際に、抜け漏れなく確認すべき項目を整理しておくと、レビュー会議の場が感覚的な議論に流れにくくなります。
- 変更後の条件は、属性条件と行動条件（または営業活動の事実）の両方を含んでいるか
- 変更によって、既存のパイプライン上の案件のステータスに矛盾が生じないか
- SFA・CRM上のワークフローやアラート設定に変更内容が反映されているか
- 変更内容と適用開始日が、関係部門全員に共有されているか
- 過去データと比較する際に、定義変更の影響を除外して評価できる状態になっているか
このチェックリストを毎回のレビューで機械的に確認するだけでも、「なんとなく変えてみた」定義変更を防ぎ、変更の意図と影響範囲を関係者全員が理解した状態を保てます。
KPIレポートに定義のバージョンを明記する
見落とされがちですが、定義を変更した際は、その変更がいつから適用されたかをレポート上に明記しておくべきです。定義変更の前後でリード数やMQL数を単純比較すると、施策の効果と定義変更の影響が混ざり合い、正しい評価ができなくなります。定義にバージョン番号を振り、変更履歴を残しておくことで、後から数字を検証する際の混乱を防げます。
まとめ
リードから顧客までの数字がかみ合わない根本原因は、ツールの不備でも担当者の能力不足でもなく、部門ごとに異なる「リード」の定義を、そろえないまま共有ダッシュボードに並べていることにあります。まずは各部門が今使っている定義を可視化し、属性条件と行動条件を掛け合わせた移行条件を設計し、仮運用で検証したうえでSFA・CRMに実装する。
そして導入後も定期的なレビューと現場からのフィードバックを通じて、定義を生きた基準として更新し続ける。この一連のプロセスを踏むことで、初めて「同じリードを同じ意味で数える」組織運営が実現します。
Q&A
- QMQL・SQLの定義は、業界や商材が違っても同じフレームワークで設計できますか?
- A
5段階の基本構造自体は業種を問わず応用できますが、移行条件に使う属性条件や行動条件の中身は、商材の検討期間や関与者の役職によって調整が必要です。基本設計をそのまま流用するのではなく、自社の商談化パターンに合わせて条件の閾値を調整することが前提になります。
- Q部門間で定義の合意が取れない場合、どう進めればよいですか?
- A
完全な合意を最初から目指すのではなく、まず影響の大きい1つの境界（例：リード→MQL）に絞って仮運用を行い、実データで議論する方が合意形成は進みやすくなります。感覚的な議論よりも、実際の数値の動きを共通の判断材料にすることが有効です。
- Q定義をそろえるプロジェクトには、どのくらいの期間を見込むべきですか?
- A
現状の可視化からSFA・CRMへの実装まで含めると、一般的には3〜6か月程度を見込む企業が多い傾向にあります。特に仮運用期間を短く切り上げすぎると条件の妥当性が検証できないため、拙速に本運用へ移行しないことが重要です。
専門用語解説
- MQL（Marketing Qualified Lead）：マーケティング部門の基準で見込みありと判定されたリード
- SQL（Sales Qualified Lead）：営業部門の基準で見込みありと判定されたリード
- SFA（Sales Force Automation）：営業活動を記録・管理するための営業支援システム
- CRM（Customer Relationship Management）：顧客情報や関係履歴を一元管理する仕組み
- パイプライン：商談から受注に至るまでの案件の流れ全体を指す言葉
- 商談化率：リードや案件のうち、実際に商談へ進んだ割合を示す指標
