%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
リード引き渡しの摩擦は、マーケの努力不足でも営業の怠慢でもありません。MQL/SQLの定義と引き渡しルールを両部門で共同設計し、CRMの仕組みとして運用することが解決の起点です。
リード引き渡しの摩擦は、マーケの努力不足でも営業の怠慢でもありません。MQL/SQLの定義と引き渡しルールを両部門で共同設計し、CRMの仕組みとして運用することが解決の起点です。
「マーケがせっかくリードを獲得しても、営業が対応してくれない」「営業からは"マーケのリードは質が低い"と言われる」「引き渡しの基準が曖昧で、誰がいつフォローするのか決まっていない」——マーケティング部門と営業部門の間で起きるこうした摩擦は、BtoB企業の成長を阻む根深い構造問題のひとつです。
リード引き渡しの再設計とは、リードの定義・引き渡しの基準・各部門の対応ルールをマーケと営業が共同で決め、CRMのワークフローとダッシュボードで運用できる形に組み直すことです。つまりリードナーチャリングの改善は「マーケの施策改善」ではなく、「組織間の連携プロセスの再設計」として取り組むテーマだと考えています。
本記事は「The Modelの限界と次世代営業組織｜分業体制のサイロ化を超える進化モデル」シリーズの一部です。
この記事でわかること
マーケティングと営業の連携に課題を感じている営業責任者・マーケ責任者に向けた記事です。MQL/SQLの定義づくりから、SLA、CRMでの仕組み化、失注後の掘り起こしまでを一続きの流れとして整理します。
- リード引き渡しが「組織問題」になる構造 — KPIの断絶と情報の分散が、なぜ部門間の不信につながるのかを解説します
- MQL・SQL・SLAの共同設計の進め方 — どの部門が何を決め、どこで引き渡すのかを表で整理します
- CRMのワークフローによる仕組み化 — 人の意識に頼らず、引き渡しの漏れと遅れを防ぐ設計例を紹介します
- 失注・不商談化からナーチャリングに戻すループ — 営業の声をマーケの改善材料に変える方法を解説します
本記事を通じて、CRMを営業の武器に変えるための実践的なアプローチが見えてきます。「ツールを入れたけど活用できていない」と感じている方にこそ、読んでいただきたい内容です。
リード引き渡しの摩擦が「組織問題」である理由
リード引き渡しの問題は、ツールの設定に加えて、部門ごとの目標や管理方法から生じる場合があります。両部門が別々のKPIと管理表で動いていると、施策を改善しても引き渡しの認識差が残ることがあります。まずは摩擦が生まれる構造を分解して見ていきます。
「リード数」と「商談数」でKPIが断絶している
マーケティング部門が獲得リード数、営業部門が商談数や受注額を主な指標にする組織では、対象や集計期間が揃わないまま数字を比較すると、「リードの質」について認識がずれることがあります。
マーケにとっては、フォームが送信された時点でリード獲得は完了です。一方で営業には、そのリードの商談化の見込みや対応優先度を判断する情報が必要です。この認識のズレが組織間の信頼関係を損ない、リード対応のスピードが落ち、商談化率が下がるという悪循環に陥ります。
スプレッドシートとチャットでの引き渡しが情報を分散させる
経緯が見えない営業は、初回の架電で一から状況を聞き直すことになり、リード側も「前にも伝えたのに」と感じやすくなります。コンタクト・会社・取引・過去のやり取りがひとつのCRMに入っていれば、営業はレコードを開くだけで経緯を追えます。引き渡しの再設計は、この情報の置き場所を揃えるところから始まると考えています。
個別部門の努力では解決しない
ここが1個ポイントになるのですが、この問題は「マーケがもっと良いリードを獲るべき」「営業がもっと早く対応すべき」という個別部門の努力だけでは解決しにくい場合があります。どちらかが頑張っても、基準が違えば相手からは「ズレた努力」に見えてしまうからです。
両部門がリードの定義・引き渡し基準・対応ルールを共同で設計し、その合意をCRMの仕組みとして運用すること。これが組織問題を組織の側で解くアプローチです。
なぜリード引き渡しの再設計が組織変革につながるのか
引き渡しの再設計は、一見すると業務フローの小さな修正に見えます。しかし実際には、分業体制の接続部分を作り直し、部門ごとの評価の物差しを揃える取り組みです。ここでは、収益と組織の両面からその意味を整理します。
対応の遅れが商談化率を下げる構造
引き渡しの基準が不明確な企業では、「誰がいつ対応するか」が決まらないまま、リードが放置される時間が長くなりがちです。検討意欲が高いタイミングで接触できなければ、リードは競合の情報収集に移ったり、社内検討を後回しにしたりします。
つまり引き渡しプロセスの再設計は、単なるオペレーション改善ではなく、商談数と受注額に直結する取り組みです。同じ数のMQLでも、定義が揃い対応が速くなれば、そこから生まれる商談の数は変わってきます。
分業を維持したまま「接続部分」を設計する
リード引き渡しの再設計は、The Model型の分業体制を否定するものではなく、最適化するアプローチです。マーケ・インサイドセールス（IS）・フィールドセールス（FS）の分業は維持しつつ、部門間の接続部分（ハンドオフポイント）を明確に定義し、データで管理します。
| 観点 | 再設計前 | 再設計後 |
|---|---|---|
| リードの定義 | 部門ごとに解釈が異なる | MQL/SAL/SQLの定義を共同で文書化 |
| 引き渡しの合図 | チャットや口頭での連絡 | ステージ変更をトリガーにした自動通知 |
| 対応状況の把握 | 担当者に聞かないとわからない | ダッシュボードでリアルタイムに確認 |
| 失注・不商談化の扱い | 営業の手元で止まる | 理由を分類してマーケへ還流 |
リードから請求までを一気通貫で捉える
引き渡しを再設計するときは、MQLからSQLまでの区間だけを見るのではなく、コンタクトの獲得から取引、顧客化、請求までの全体フローの中で位置づけることをおすすめします。リードが取引になり、受注して顧客となり、請求に至るまでが同じCRM上でつながっていれば、「どのマーケ施策から来たリードが受注と売上につながったのか」まで追えるようになります。
この全体像があると、マーケは「リード数」ではなく「受注につながるリード」を目標に置けるようになり、営業は「マーケのリード」を自分たちの売上の起点として捉えやすくなります。KPIの断絶を埋めるのは、スローガンではなくこの一本のデータの流れです。
ステップ1：MQL・SQLの定義を共同で策定する
再設計の出発点は、マーケと営業がMQL（Marketing Qualified Lead）とSQL（Sales Qualified Lead）の定義を共同で決めることです。定義が揃わないままSLAや自動化を作っても、土台がずれたまま仕組みだけが増えてしまいます。ここでは定義の型と、自社に合わせる際の考え方を整理します。
ステージごとの定義と責任部門を表にする
最初に、リードがどの状態にあるときにどの部門が責任を持つのかを1枚の表にまとめます。以下は判定基準の一例です。
| ステージ | 定義 | 判定基準の例 | 責任部門 |
|---|---|---|---|
| リード | フォーム送信等で接点が生まれた状態 | フォーム送信、名刺交換 | マーケティング |
| MQL | マーケが「営業対応の価値あり」と判定 | リードスコアが合意した閾値を超えた、または料金ページ閲覧＋資料ダウンロード | マーケティング |
| SAL | 営業が「対応する」と受け入れた状態 | ISが架電し、ヒアリングが完了 | インサイドセールス |
| SQL | 営業が「商談の見込みあり」と判定 | BANT（予算・決裁権・ニーズ・導入時期）のいずれかが確認できた | フィールドセールス |
表を作るときは、「判定基準の例」の列をCRMのプロパティで判定できる言葉にしておくのがポイントになってきます。「温度感が高い」のような主観的な表現は、担当者によって解釈が分かれ、後の自動化にも載せられません。
MQLの定義をマーケだけで決めない
ここで要点になるのが、MQLの定義をマーケだけで決めないことです。営業が「このレベルのリードなら対応したい」と考える基準をヒアリングし、それをスコアリングモデルに反映します。
ヒアリングでは、直近で受注した案件と、対応したものの商談化しなかったリードを営業責任者とトッププレイヤーに並べてもらい、両者を分けた行動や属性を挙げてもらうのが進めやすい方法です。営業の実感とマーケの基準が一致して初めて、引き渡しがスムーズに機能します。
自社に合わせた定義：コンタクトと会社を分けて見る
BtoBでは、1社から複数の担当者がリードとして入ってくることがよくあります。コンタクト単位で見るとリード数は多いのに、会社単位で見ると意外と対象企業が少ない、ということも起こります。そのため、コンタクトと会社のそれぞれでライフサイクルステージを管理し、会社のステージは紐づくコンタクトのうち最も進んだステージに合わせる設計をおすすめします。
また、営業・採用目的の問い合わせや競合他社からの問い合わせを「アプローチNG」、自社メンバーを「社内」として分けておくと、MQLの数字が実態から離れにくくなります。どのステージを置くか、会社単位とコンタクト単位のどちらを主に見るかは、商材や販売形態によって変わります。自社のカスタマージャーニーを書き出し、その段階に沿ってステージを定義していく順番が進めやすいと考えています。
ステップ2：部門間SLAを設計する
定義が揃ったら、次は各部門が守るルールを決めます。SLA（Service Level Agreement）とは、リード対応において各部門が何を、いつまでに、どこへ記録するのかを明文化した部門間の約束です。約束を文書にするだけで終わらせず、CRMで守られているかを見える形にするところまでが設計の範囲です。
引き渡しスピード・記録・フィードバックを表で合意する
SLAは「スピード」「対応完了の定義」「フィードバック」「数値目標」の4つの観点で整理すると、抜け漏れが少なくなります。以下は項目の例です。
| SLA項目 | マーケの責任 | ISの責任 | FSの責任 |
|---|---|---|---|
| 引き渡しスピード | MQL判定後、即時に営業チームへ通知 | 通知から合意した時間内に初回架電 | ISからのトス後、合意した期限内に接触 |
| 対応完了の定義 | MQLの判定理由をCRMに記録 | 架電結果（接続/不在/辞退）をCRMに記録 | 商談化/不商談化の判定と理由を記録 |
| フィードバック | — | 「マーケリードの質」を月次レビュー | 「ISトスの質」を月次レビュー |
| 数値目標 | 月間MQL数: XX件 | MQL→SAL転換率: XX% | SAL→SQL転換率: XX% |
対応時間の具体的な値は、自社の営業体制と、リードがどれだけ早く他社と比較を始めるかによって決まります。最初は現場が守れる値で合意し、ダッシュボードで実績を見ながら短くしていく順番をおすすめします。
SLAをダッシュボードで「見える約束」にする
SLAは文書として残すだけでは、忙しい時期に真っ先に形骸化します。CRMのダッシュボードで、MQL化からの経過時間、SLA期限を過ぎた未対応リードの数、各ステージ間の転換率をリアルタイムに表示し、月次の部門間ミーティングでその画面を見ながらレビューする運用にすると、議論が感覚ではなく数字で進みます。
ダッシュボードに載せる指標は多くしすぎないことがポイントです。最初は「期限切れの未対応リード」と「MQL→商談化率」の2つから始め、会議で実際に参照される指標だけを残していくと、見られないレポートが増えるのを防げます。
共通KPIで対立構造を協働構造に変える
部門ごとのKPIだけを並べると、SLAは「相手に守らせるルール」になりがちです。そこで、両部門の共通KPIとして「MQL→商談化率」を置くことをおすすめします。マーケはリード数を増やすだけでは数字が改善せず、営業は対応を怠ると数字が下がるため、同じ指標を一緒に追う関係が生まれます。
ステップ3：スコアリングを小さく始めて育てる
リードスコアリングは、MQLの判定基準を定量化する仕組みです。ステップ1で合意した「営業が対応したいリード」の特徴を、行動と属性の加点に置き換えます。最初から精緻なモデルを作ろうとするより、少ない項目で始めて運用データで育てるほうが、結果として精度が上がりやすいと考えています。
行動スコアを重く、属性スコアを軽く置く
スコアは、Web行動やメール反応などの「行動スコア」と、役職・企業規模・業種などの「属性スコア」に分けて設計します。配分は行動スコアに重きを置くのが1つの目安です。行動に重みを置くのは、「今まさに検討している」というシグナルを捉えるためです。
| 区分 | 項目の例 | 加点の重み（例） |
|---|---|---|
| 行動 | 料金ページの閲覧 | 大 |
| 行動 | 事例ページの閲覧 | 中 |
| 行動 | 資料ダウンロード | 中 |
| 行動 | メールの継続的な開封 | 小 |
| 属性 | 役職が部長以上 | 中 |
| 属性 | 自社のターゲット規模に該当 | 小 |
どのページを「大」とするかは、ステップ1のヒアリングで受注案件に共通していた行動をもとに決めます。自社の商材では事例ページのほうが検討の深さを示す、ということもあるため、表の重みは出発点として扱ってください。
閾値は運用データで調整する
スコアの閾値は、仮の値を置いて運用を始め、MQL化したリードの商談化率を見ながら調整します。判断の分かれ目は次のとおりです。
| 運用データの状態 | 判断 | 調整の方向 |
|---|---|---|
| MQLが多すぎて営業が期限内に対応しきれない | 閾値が低すぎる | 閾値を上げる |
| MQLの商談化率が低く、営業が「質が悪い」と感じている | 加点項目が検討度合いを反映していない | 加点の大きい行動を見直す |
| MQLが少なく、営業の手が空いている | 閾値が高すぎる | 閾値を下げる |
| 高スコアでも商談化しないリードに共通の属性がある | 属性スコアの設計がずれている | 該当属性の加点を下げる、または除外条件にする |
月次でスコア分布と商談化率の関係を見て、表のどの行に当てはまるかを判断すると、調整の議論が感覚に流れにくくなります。
項目は最小限から始める
スコアリングは最初から20項目以上を設定すると、何が効いているのか分析しにくくなります。まず5〜7項目でスタートし、商談化率との相関を見ながら段階的に拡張していただければなと思います。
項目が少ないほど、営業とマーケが「なぜこのリードがMQLになったのか」を同じ言葉で説明できます。この説明のしやすさが、スコアへの信頼、ひいてはマーケへの信頼につながっていきます。
ステップ4：CRMのワークフローで引き渡しを仕組み化する
定義・SLA・スコアリングが決まったら、それをCRMのワークフローに載せます。人の意識や努力に頼るのではなく、システムで解決するという発想が重要です。ここでは自動化の流れと、SQL以降の取引管理への接続、AIの使いどころを整理します。
引き渡しの自動化フロー
ワークフローの設計例は次のとおりです。各段で「何がCRMに記録されていれば次へ進むか」をあわせて決めておくと、運用が止まりにくくなります。
| 段階 | 自動化の内容 | 次へ進む条件 |
|---|---|---|
| 1. MQL化 | リードスコアが閾値を超えたら、ライフサイクルステージを自動的にMQLに変更 | MQLの判定理由がプロパティに残っている |
| 2. IS通知 | 担当ISにSlack通知とタスクを自動作成（期限はSLAに合わせる） | タスクが担当者に割り当てられている |
| 3. SAL判定 | ISが架電結果を記録したら、SAL/非SALをプロパティに反映 | 架電結果の選択肢が入力されている |
| 4. FSアサイン | SAL判定されたリードを担当FSに自動アサインして通知 | FSの担当者が設定されている |
| 5. 結果の還流 | FSが商談化/非商談化を記録したら、結果をマーケへフィードバック | 商談化/非商談化の理由が選択されている |
この一連のプロセスをワークフローで自動化することで、「引き渡しの漏れ」や「対応の遅延」を仕組みとして防げます。担当者が入れ替わっても、ルールは人ではなくCRMの中に残るため、新しく入ったメンバーでも同じ手順で引き渡しを回せます。
初めてワークフローを組む場合は、Breezeなどの AI にたたき台を作らせ、条件分岐や通知先を人が手直しする進め方も取っ掛かりとしてはやりやすいと考えています。
SQL以降は取引パイプラインに接続する
SQLになったリードは、取引として営業パイプラインに乗せます。引き渡しの設計がMQL→SQLで止まっていると、その先の受注・失注のデータがマーケに戻ってこないため、パイプライン側の設計まで一続きで考えることをおすすめします。
次の画面は、HubSpotの取引をボード表示で管理している例です。
パイプラインは、次の4つの要素で設計すると引き渡し後の管理が安定します。
| 要素 | 内容 | 引き渡し設計との関係 |
|---|---|---|
| 取引ステージ | 受注率が変化するポイントでステージを分ける | SQLの定義と最初のステージの定義を揃える |
| 受注確度 | 各ステージの受注確率を設定し、加重金額で見込みを算出 | どの経路のリードが見込み金額を積み上げているかを見られる |
| ステージ定義 | 各ステージの意味を文書化して社内で共有 | ISとFSで「商談」の解釈がずれるのを防ぐ |
| 必須入力プロパティ | ステージ移行時に入力を必須にする | 失注理由や商談化の根拠がマーケに届く状態を保つ |
必須入力プロパティは、新しく入った営業担当者に「このステージでは何を確認すべきか」を教える役割も果たします。個人の経験に頼らず、CRMの画面そのものが手順書になるのが仕組み化の利点です。
ライフサイクルステージの仕様を押さえて設計する
HubSpotのライフサイクルステージには、購読者・リード・マーケティングクオリファイドリード・セールスクオリファイドリード・商談・顧客・エバンジェリスト・その他が標準で用意されています。また、標準の動作ではステージは前に進む方向にのみ自動更新され、前のステージに戻すにはいったん値をクリアしてから設定し直す仕様です（出典：Use lifecycle stages）。
この仕様があるため、失注したリードをナーチャリングに戻すワークフローは「ステージをクリアする」「戻したいステージを設定する」の2段で組みます。後戻りの操作を手作業に任せると、担当者によって戻す・戻さないがばらつくので、次のステップで扱う掘り起こしのルールとセットでワークフロー化しておくのが進めやすい方法です。
AIに任せる範囲と人が判断する範囲を分ける
引き渡しの流れにAIを組み込む場合は、任せる範囲を先に決めておくことをおすすめします。
| AIに任せやすいこと | 人が判断すること |
|---|---|
| フォームの問い合わせが営業目的か通常の相談かの分類 | MQL・SQLの定義とステージ設計 |
| リードや会社のレコード要約 | 最終的なメール送信の判断 |
| 企業情報のリサーチと初回メールの下書き | 大型案件になりそうなリードへのアプローチ内容 |
| 不商談化理由の分類補助 | スコアリングの閾値と加点方針の決定 |
ただし、AIが作成したメールを確認なしで自動送信する設定はおすすめしません。
ステップ5：失注・不商談化からナーチャリングに戻すループ
引き渡し再設計の中で見落とされがちなのが、営業からマーケへのフィードバックループです。商談化しなかったリードや失注した取引は、その時点で終わりではなく、次のナーチャリングの起点になります。ここでは理由の記録方法と、掘り起こしの流れを整理します。
不商談化・失注の理由を選択肢で記録する
営業からのフィードバックが「リードの質が悪い」という定性的な不満で終わるのは、理由を記録する形式が決まっていないことが一因です。不商談化や失注の理由は、自由記述ではなくプルダウンの選択肢で記録します。
| 理由のカテゴリー | マーケ側での打ち手 |
|---|---|
| タイミングが合わない | 長期ナーチャリングのシナリオを強化する |
| 予算がない／価格 | 費用対効果を説明するコンテンツを整える |
| 競合検討中／競合他社に決定 | 比較検討段階向けのコンテンツを見直す |
| ニーズが合わない | コンテンツのターゲティングと獲得チャネルを見直す |
| 製品機能 | 要望として製品開発側へ共有する |
| 社内決裁 | 決裁者向けの資料や情報提供を用意する |
理由が選択肢で揃っていれば、円グラフなどで集計してマーケと共有できます。「営業の不満」が「改善の材料」に変わるのは、この構造化のところです。
失注から掘り起こしへ戻すライフサイクル
失注した取引に紐づくコンタクトは、一定の条件でナーチャリングの対象に戻します。流れは「商談 → 失注 → 失注掘り起こし（ナーチャリングに戻る）→ 再びMQL」というループです。
このループをワークフローで組んでおくと、失注理由が「タイミングが合わない」のリードには時期を置いてメールを届け、再び行動スコアが上がったタイミングでMQLとして営業に戻す、という流れを人手を介さずに回せます。ステップメールを組む場合は、送信の間隔（遅延）をどう置くかが要点になります。
月次のリードレビューで改善を回す
マーケ・IS・FSが参加する月次のリードレビューミーティングを設け、MQLの質、各ステージの転換率、不商談化・失注の理由を共有します。議題は毎回同じ順番にし、ダッシュボードの画面をそのまま見ながら進めると、準備の負担が小さく続けやすくなります。
このフィードバックループが回ることで、スコアリングモデルの精度が上がり、MQLの質が改善し、営業のマーケに対する信頼が高まるという好循環が生まれます。
CRM/HubSpotでの実装と、よくある失敗パターン
ここまでの設計を、HubSpotのどの機能で実現するのかを整理したうえで、再設計がうまく定着しないときのパターンを見ていきます。機能を並べるだけでなく、どこでつまずきやすいのかを先に知っておくと、導入の順番を決めやすくなります。
HubSpotの機能との対応関係
HubSpotを使う場合は、次の機能を組み合わせてリード引き渡しのプロセスを構築します。
| 設計要素 | HubSpotの機能 | 全体フローでの位置 |
|---|---|---|
| MQLの判定 | リードスコアリング（エンゲージメント＋適合スコア） | コンタクト獲得後 |
| 検討段階の管理 | ライフサイクルステージ（リード→MQL→SQL→商談→顧客） | コンタクト〜顧客 |
| 引き渡しの自動化 | ワークフロー（MQL化→通知→タスク作成→担当者アサイン） | MQL〜SQL |
| ホットリードの管理 | リードオブジェクト（コンタクトと分離して管理） | MQL〜SAL |
| 商談の管理 | 取引パイプライン | SQL〜受注・失注 |
| SLAの可視化 | ダッシュボード（SLAの進捗、転換率、対応速度） | 全体 |
Salesforceを使っている企業でも基本的な設計思想は同じです。HubSpotの場合はマーケティング・営業・カスタマーサービスが単一のプラットフォームに統合されているため、部門間のデータ連携を同じデータベースの中で完結させやすいのが特徴です。Salesforceの場合はPardotやMarketoとの連携設定が別途必要になるケースが多くあります。
失敗1：SLAを作ったが運用されない
SLAは文書化しただけでは機能しません。定着させるには、次の順番で運用に組み込みます。まずダッシュボードに期限切れの未対応リードを表示し、次に週次の営業定例でその件数を最初の議題にし、最後に月次のリードレビューで期限の値そのものを見直します。期限切れが続く担当者がいれば、個人の問題として扱う前に、担当リード数やアサインの条件がSLAと釣り合っているかを見直すのが順番です。
失敗2：スコアリングモデルを最初から複雑にしすぎる
多数の項目を一度に設定すると、どの項目が商談化に効いているのかが見えなくなります。少ない項目で始め、ステップ3の判断表に沿って1項目ずつ追加・変更していくと、変更の効果を切り分けられます。
失敗3：フィードバックが「営業の不満」で終わる
不商談化の理由を自由記述にしていると、集計できず、会議が印象論の応酬になりがちです。理由をカテゴリーの選択肢にし、商談化/非商談化の記録と同じタイミングで入力を必須にすると、定量データとして蓄積され、建設的な改善議論に変えられます。
失敗4：一度設計して放置する
リード引き渡しの設計は、市場環境やプロダクトの変化に応じて更新していくものです。四半期に1回、SLAの期限、スコアリングの閾値と加点項目、ステージ定義の3点を見直す会を計画に組み込んでください。見直しの結果はCRMの設定と定義表の両方に反映し、どちらか一方だけが古くならないようにします。
よくある質問
Q. インサイドセールスがいない場合、リード引き渡しはどう設計すればよいですか？
IS機能がない場合は、マーケが直接FSにリードを渡す形になります。この場合はMQLの閾値を高めに設定し、営業が対応すべきリードに絞り込むことをおすすめします。そのうえで、FSが期限内に対応しきれないMQLが継続的に発生するようになった段階で、IS機能の導入を検討するのが進めやすい順番です。
Q. SLAの初回対応時間はどう決めればよいですか？
リードの購買意欲は時間とともに下がっていくため、対応スピードは商談化率に直結します。ただし、現場が守れない期限を置くとSLA自体が形骸化します。まずは現在の体制で守れる期限で合意し、ダッシュボードで実際の対応時間を見ながら、短くしていく進め方をおすすめします。
Q. リードスコアリングの閾値はどう決めればよいですか？
まず仮の閾値を設定して1〜2ヶ月運用し、MQL化したリードの商談化率を分析します。次の調整を繰り返すのが現実的なアプローチです。
- 商談化率が低すぎる場合 ── 閾値を上げる
- MQL数が少なすぎる場合 ── 閾値を下げる
調整のたびに変更内容を記録しておくと、どの変更が効いたのかを後から振り返れます。
Q. マーケと営業の関係が悪く、SLAの合意が難しい場合はどうすればよいですか？
経営層をスポンサーとして巻き込み、トップダウンで「リード引き渡しの再設計プロジェクト」として推進するのが効果的です。両部門の共通KPIとして「MQL→商談化率」を設定し、対立構造ではなく協働構造に変えていきます。最初の議題は責任の押しつけ合いではなく、受注案件と非商談化リードの違いを一緒に洗い出す作業にすると、合意に進みやすくなります。
まとめ
リードナーチャリングの成果を高めるには、マーケと営業のリード引き渡しを「組織間の連携プロセス」として再設計することが近道です。全体の流れは次のとおりです。
- 定義を揃える — MQL/SAL/SQLの定義と責任部門を、営業とマーケが共同で策定する
- 約束を見える形にする — 部門間SLAを設計し、ダッシュボードで遵守状況を追う
- 判定を定量化する — 行動ベースのスコアリングを少ない項目で始め、運用データで育てる
- 仕組みで回す — ワークフローで引き渡しを自動化し、SQL以降は取引パイプラインにつなぐ
- ループを閉じる — 失注・不商談化の理由を構造化し、掘り起こしとしてナーチャリングに戻す
まずは営業責任者とマーケ責任者が同じテーブルにつき、「MQLとは何か」を合意するところから始めてみてください。次の行動としては、以下の3ステップが進めやすい順番です。
- 直近の受注案件と非商談化リードを並べ、両者を分けた行動・属性を書き出す
- その結果をもとに、ステージの定義表とSLAの項目表を1枚ずつ作る
- MQL化から担当者への通知までの1本だけをワークフロー化し、ダッシュボードで対応状況を見始める
このテーマに関連する記事はセールスマネジメントカテゴリで網羅的にまとめています。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
