リード管理プロセス設計｜MQLからSQLへ確実に転換する方法

TL;DR

• リード管理プロセスはステージ定義・スコアリング・引き渡しルールの3点を一体設計する仕組みである
• MQLは属性スコアと行動スコアの2軸で判定し、SQL転換率20〜50%を目安に閾値を月次調整する
• 共通言語としてのステージ定義がマーケと営業の相互不信を解消し、パイプライン入口の質を高める

この記事が役立つ状況

• 対象者: 営業企画・RevOps担当 / マーケティングマネージャー / インサイドセールスリーダー
• 直面している課題: リードは獲得できているのに商談に繋がらず、マーケと営業の間で「質が低い」「フォローされない」という相互不信が発生している
• 前提条件: CRM/MAツールが導入済みで、マーケと営業がステージ定義・SLAについて合意形成できる体制があること

このノウハウをAIで実行するプロンプト

以下をコピーしてLLMに貼り付け、[ ] 内を自社の情報に書き換えてください。

あなたはBtoBのRevOps担当者です。自社のリード管理プロセスを以下の観点で設計してください。

【自社情報】
- 業種: [   ]
- ターゲット企業規模: [   ]
- 月間リード獲得数: [   ]
- 現在のMQL→SQL転換率: [   ]%

【設計依頼】
1. Raw Lead / MQL / SAL / SQL / Opportunity の5ステージそれぞれの進行条件（Exit Criteria）を、定量条件で定義してください
2. MQL判定の属性スコア（業種・役職・企業規模）と行動スコア（料金ページ閲覧・事例DL等）の配点設計を提案してください
3. MQL発生からISの初回接触までのSLA時間と、SQL転換率の月次レビュー基準を示してください

リード管理プロセスとは何か

リード管理プロセスとは、見込み客（リード）を獲得してから商談化・受注に至るまでの一連の流れを設計・運用する仕組みだ。MQL（Marketing Qualified Lead）からSQL（Sales Qualified Lead）への転換を確実に行うには、リードのステージ定義、スコアリング基準、部門間の引き渡しルールの3つを一体として設計する必要がある。

多くの企業で「リードは獲得できているのに商談に繋がらない」という課題が発生している。この原因は、リード管理のプロセスが設計されていないことにある。マーケティングが大量のリードをCRMに登録しても、営業がどのリードを優先的にフォローすべきか判断できなければ、リードは放置される。逆に、営業がすべてのリードに片っ端から電話をかけても、検討初期のリードには時期尚早であり、営業工数の無駄になる。

リード管理プロセスの本質は、「適切なリードを、適切なタイミングで、適切な担当者に届ける」仕組みを作ることだ。この仕組みがあることで、パイプライン全体の入口の質が向上し、営業の生産性とフォーキャストの精度が同時に改善する。

リードステージの定義——共通言語を作る

リード管理プロセスの設計において最初に行うべきは、リードのステージ定義だ。マーケティングと営業が「リード」という言葉で異なるものを指している限り、どんな施策も効果を発揮しない。

以下の5ステージが、BtoB企業における標準的なリードステージ体系だ。

ここで重要なのは、各ステージの「進行条件（Exit Criteria）」を具体的に定義することだ。「なんとなくホットそう」「感覚的にまだ早い」という属人的な判断を排除し、誰が見ても同じ分類ができる基準を設ける。

たとえばMQLの進行条件は、「リードスコア50点以上」「過去14日以内に料金ページまたは事例ページを閲覧」「企業規模が従業員30名以上」のように、複数の定量条件を組み合わせて設計する。この基準はマーケティングと営業のSLAとして明文化し、両部門が合意した上で運用を開始してください。

ステージ定義が曖昧なまま運用を始めると、マーケティングは「渡したリードをフォローしてもらえない」、営業は「質の低いリードばかり来る」という相互不信に陥る。共通言語としてのステージ定義は、リード管理プロセス全体の土台だ。

MQLの設計——データで「営業に渡すべきリード」を判定する

MQLの設計は、リード管理プロセスの中で最もインパクトの大きい工程だ。MQLの基準が適切であれば、営業は受注確度の高いリードに集中でき、マーケティングはリード獲得施策のROIを正確に測定できる。

MQLの判定には、属性スコアと行動スコアの2軸を使いる。

属性スコアは、リードが自社のターゲット像にどれだけ合致しているかを評価する。企業規模、業種、役職、所在地などのデモグラフィック情報を基に点数を付与する。たとえば、ターゲット業種であれば+20点、意思決定者の役職であれば+15点、という具合だ。

行動スコアは、リードの関心度や購買意欲を示すオンライン行動を評価する。料金ページの閲覧（+15点）、事例ページの閲覧（+10点）、ホワイトペーパーのダウンロード（+10点）、セミナーへの参加（+20点）など、購買に近い行動ほど高いスコアを付与する。

属性スコアと行動スコアの合計が事前に設定した閾値を超えた時点で、そのリードをMQLとして判定する。MAツールを使えば、この判定を自動化し、MQL発生時にインサイドセールスへ即座に通知する仕組みを構築できる。

MQL設計の注意点として、閾値の初期設定は「仮説」に過ぎないという認識が重要だ。運用開始後、実際にMQLとして営業に渡したリードのうち何%がSQLに転換したかを月次で測定し、閾値を調整する。転換率が20%を下回る場合は閾値を引き上げ、50%を超える場合は閾値を下げてリード供給量を増やす方向で調整してください。

MQLからSQLへの転換プロセス——引き渡しの「仕組み」を作る

MQLの判定基準を設計しただけでは、SQLへの転換率は上がらない。MQLが発生してからSQLに転換するまでの引き渡しプロセスを、具体的なルールとして設計する必要がある。

ステップ1: MQL通知と初回接触

MQLが発生した時点で、CRM/MAツールからインサイドセールス（IS）に自動通知を送る。ISはSLAで定めた時間内（ホットリードは1時間以内、ウォームリードは24時間以内が目安）に初回接触を行いる。InsideSales.comの調査によれば、リード発生から5分以内の対応は30分後と比較してコンタクト成功率が21倍になる。スピードは転換率に直結する要素だ。

ステップ2: ヒアリングとSAL判定

ISはリードとの対話を通じて、BANTやMEDDICなどのフレームワークに基づいたヒアリングを行いる。具体的には「予算の有無」「意思決定者へのアクセス」「導入時期の目安」「具体的な課題」を確認し、SAL（Sales Accepted Lead）として受け入れるか、ナーチャリングに差し戻すかを判定する。差し戻す場合は、CRMに差し戻し理由を必ず記録する。このデータがMQLの基準を改善するためのフィードバックになる。

ステップ3: SQL判定と商談化

SALとして受け入れたリードに対して、さらに深いヒアリングや提案を行い、SQL（商談化すべきリード）として判定する。SQLの判定基準は、フィールドセールス（FS）と合意した「商談化条件」に基づくる。たとえば「予算が確保されている」「3ヶ月以内の導入意向がある」「意思決定者との面談が設定できる」の3条件を満たした場合にSQLとする、といった具合だ。

ステップ4: リサイクルリードの循環

見落とされがちだが、極めて重要なのがリサイクルの仕組みだ。SAL判定で差し戻されたリード、SQL判定に至らなかったリードを、リードナーチャリングのフローに自動で再投入する循環構造を設計する。「今は必要ない」と言ったリードが半年後に再検討を始める可能性は十分にあり、過去に投資したリード獲得コストを回収する機会を逃してはならない。

転換率を高める3つの実践テクニック

リード管理プロセスの基本設計ができたら、転換率を改善する具体的なテクニックを実装する。

1. リードの温度感に応じたアプローチの出し分け

すべてのMQLに同じアプローチをしてはいけない。行動スコアの内訳に応じて、ISのアプローチ方法を変える。料金ページを複数回閲覧しているリードには「具体的な導入相談」の切り口で架電し、ホワイトペーパーをDLしただけのリードには「課題のヒアリング」の切り口でメールを送る。この出し分けにより、リードの体験が向上し、コンタクト成功率とSAL受入率が改善する。

2. 営業へのコンテキスト共有

MQLを営業に引き渡す際、リードの「スコアの数字」だけでなく「なぜMQLになったか」のコンテキストを伝える。具体的には、閲覧したコンテンツの一覧、流入チャネル、過去のセミナー参加履歴、メールの開封・クリック履歴をCRM上で確認できる状態にする。営業がリードの関心事を把握した上で対話に臨むことで、ヒアリングの質が上がり、SQL転換率が向上する。

3. ステージ滞留アラートの設計

各ステージに標準的な滞留期間を設定し、超過した場合にアラートを出す仕組みを作る。たとえば「MQLからSAL判定まで48時間」「SALからSQL判定まで14日」という基準を設け、超過時にマネージャーに自動通知する。滞留はパイプラインの健全性を損なう最大の要因であり、早期に検知して対処することが転換率の維持に不可欠だ。

RevOps視点でのリード管理プロセス最適化

従来のリード管理は、マーケティングが獲得し、営業がフォローするという二部門間のオペレーションだった。しかし、RevOps（Revenue Operations）の視点では、リード管理を収益パイプライン全体の入口設計として捉え、部門横断で最適化する。

統一データ基盤の構築。マーケティングのMAツール、営業のSFA、カスタマーサクセスのCSツールに分散しているリードデータを、CRMを中心とした統一基盤に集約する。リードが最初にどのチャネルから流入し、どのコンテンツに触れ、誰が対応し、最終的にどの金額で受注（または失注）したかの全データが繋がっていることで、リード管理プロセス全体のボトルネックを特定できる。

ファネル全体の歩留まり分析。RevOpsはRaw Lead→MQL→SAL→SQL→Opportunityの各転換率を一貫して計測し、ファネル分析によってどのステージに最大の改善余地があるかを特定する。マーケティングがMQL数だけを追い、営業がSQL数だけを追う部分最適を排除し、ファネル全体のスループットを最大化する視点で改善施策を立案する。

フィードバックループの制度化。営業からマーケティングへの「リードの質」に関するフィードバックを、月次の定例ミーティングで制度化する。SAL受入率、差し戻し理由の傾向、SQL転換率の推移をデータで共有し、MQLの基準やナーチャリングシナリオの改善に反映する。このフィードバックループが回り続けることで、リード管理プロセスの精度は運用するほど向上していくる。

まとめ

リード管理プロセスの設計は、「リードステージの定義」「スコアリング基準」「部門間の引き渡しルール」の3つを同時に設計することが前提だ。どれか一つが欠けると、MQLからSQLへの転換率は改善しない。

まずはマーケティングと営業が合意したリードステージの定義を作成し、MQLの判定基準を仮設定してください。運用を開始し、月次でSAL受入率とSQL転換率を計測しながら閾値を調整していくことで、自社に最適化されたリード管理プロセスが構築できる。

リード管理は一度設計して終わりではなく、データに基づいて継続的に改善するプロセスだ。RevOpsの視点でファネル全体を俯瞰し、部門横断のフィードバックループを回し続けること。それが、MQLからSQLへの転換率を確実に高める唯一の方法だ。リードライフサイクル全体の設計についてはリードライフサイクル管理、リードナーチャリングの自動化はGTMエンジニア視点の営業自動化も参考になる。