営業へのリード引き渡しで決める項目一覧｜取りこぼしを防ぐ

マーケティング側は「先月は50件のリードを営業に渡した」と報告する。営業側は「使えるリードが来ない」と言う。どちらも嘘をついていません。渡した件数と、営業が対応に値すると判断した件数が違うだけです。この食い違いは、引き渡しの条件と方法を決めていないことから生まれます。何を満たしたら渡すのか、渡した後は誰がいつまでに対応するのか、対応できない場合はどうするのか。この3点が決まっていないと、リードは部門の境界で滞留します。この記事では、引き渡しのルールとして決めるべき項目を、実務で使える形に整理します。

渡したつもりと受け取っていないの間

部門をまたぐリードの受け渡しでは、双方の認識がずれた状態が長く続くことがあります。マーケティング側は件数を成果として報告し、営業側は質の低さを問題として語る。同じ対象について話しているのに、噛み合いません。

ずれの原因は、渡す基準が言葉になっていないことです。マーケティング側は「関心を示した相手」を渡し、営業側は「商談になりうる相手」を期待している。この定義の差が、そのまま評価の差になります。基準を揃えれば、件数の議論は成立します。

もう1つの原因は、渡した後の扱いが決まっていないことです。誰がいつまでに対応するかが決まっていなければ、渡された側は自分の判断で優先順位を付けます。他の業務が忙しければ後回しになり、数日後には鮮度が落ちています。

この2つを解決するのが、引き渡しのルールです。渡す条件と、渡した後の対応をセットで決めます。片方だけを決めても、もう片方で滞留が起きます。ルールは複雑にする必要はなく、1枚の紙に収まる分量で足ります。

作る際は、両部門で合意することが前提です。マーケティング側だけで決めた基準は、営業側の実感と合わず守られないという結果になります。1時間の打ち合わせで大枠は決められます。

ルールがないと何が起きるか

ルールの不在によって起きる問題を具体的に挙げておくと、整備する動機が明確になります。放置すると損失が積み上がる領域です。

1つ目は、対応漏れです。渡されたリードが誰の担当かが不明確なまま数日が過ぎ、そのまま忘れられます。問い合わせから最初の連絡までの時間が商談化率に大きく影響するため、この漏れは直接的な機会損失になります。

2つ目は、重複した接触です。マーケティング側が育成のメールを送り続け、同時に営業が電話をかける。相手からすると、同じ会社から異なる文脈で連絡が来る状態になり、印象を損ねます。

3つ目は、評価の混乱です。マーケティングの成果を件数で測ると、質の低いリードを増やす動機が生まれます。営業側の対応率や商談化率を含めた指標にしなければ、部門の目標が対立します。

4つ目は、改善の停滞です。どの条件のリードが商談になりやすいかの検証ができず、施策の精度が上がらないという状態になります。基準がなければ、比較する対象も作れません。

4つのステージで整理する

リードの状態を段階に分けて管理すると、どこで滞留しているかが見えます。段階の数は多すぎない方が運用できます。

BtoBの実務では、4つのステージ（MQL、SAL、SQL、SQO）を使うと管理しやすくなります。MQLはマーケティングが営業に渡す価値があると判断したリード、SALは営業が受け取りを承認した状態、SQLは営業が商談に値すると判断した状態、SQOは商談として案件化した状態です。

この4段階の価値は、責任の所在が明確になることです。MQLからSALへの移行が滞っていれば受け取りの運用に問題があり、SALからSQLが滞っていれば渡す基準に問題があります。数字を見れば、どちらの部門が手を入れるべきかが分かります。

段階ごとの件数を毎月記録すると、通過率が見えます。MQLが50件でSQLが5件なら、通過率は10%です。この数字が前月と比べてどう動いたかが、改善の指標になります。

4段階が多いと感じる場合は、3段階から始めても構いません。渡した、受け取った、商談になった。この3つの記録があれば議論は始められるという水準です。段階の細分化は、運用が回り始めてからで足ります。

MQLの定義を決める

最も重要なのがMQLの定義です。ここが曖昧だと、渡す基準が担当者の感覚に委ねられます。

MQLとは、マーケティング部門が営業に渡す価値があると判断したリードを指します。一定の属性条件と行動条件を満たしたものに限定するという性質を持ちます。すべてのリードがMQLになるわけではありません。

この限定が重要です。資料をダウンロードした全員をMQLとして渡すと、情報収集の段階の相手が大量に含まれます。営業が対応しても商談にならず、渡されたもの全体への信頼が下がります。

定義は文書に残し、両部門で共有します。「対象業種に該当し、従業員100名以上で、部長以上の役職者が、資料を2回以上ダウンロードした場合」といった具体的な形にします。曖昧な表現を残さないことが要点です。

定義は固定せず、見直す前提を持ちます。四半期ごとに、MQLからSQLへの通過率を見て条件を調整する運用にしてください。通過率が低ければ条件を厳しくし、MQLの件数が足りなければ緩めます。

属性条件と行動条件

MQLの条件は2種類の要素を組み合わせて作ります。どちらか一方だけでは、精度が上がりません。

MQLの判断基準は、属性条件（対象業種・企業規模・役職）と行動条件（資料DL・ウェビナー参加・問い合わせフォームへの入力などの購買シグナル）の組み合わせが使われることが多くなっています。属性は相手が誰かを示し、行動は関心の度合いを示します。

属性条件だけで判断すると、大企業の担当者が1度資料を見ただけで渡されます。関心が低い相手に営業が接触することになり、対応の効率が落ちます。逆に行動条件だけでは、対象外の業種や個人の情報収集が混ざります。

組み合わせ方は、点数で管理する方法と条件で管理する方法があります。最初は条件で管理するほうが分かりやすく、運用も容易です。点数化は、条件が複雑になってから検討してください。

行動条件では、行動の重みを分けます。価格ページの閲覧や見積の依頼は、資料のダウンロードより強い関心を示す行動です。この差を条件に反映させると、精度が上がります。

条件は営業と合意して決める

条件を決める作業は、マーケティング部門だけでは完結しません。営業側の実感を反映させる必要があります。

合意の作り方は、過去の実績から始めるのが確実です。直近で商談になったリードの属性と行動を並べ、共通点を探します。20件程度を確認すれば、傾向が見えてきます。この作業を両部門で一緒に行うと、条件の議論が具体的になります。

あわせて、商談にならなかったリードも確認します。対応したが商談にならなかった理由を分類すると、条件から除外すべき要素が見つかります。個人での利用目的、対象外の規模、競合他社からの情報収集などが典型です。

合意した条件は、両部門の責任者が確認した形で残します。口頭の合意は、担当者が変わった時点で失われます。文書として残し、参照できる場所に置いてください。

見直しの場も定例化します。四半期に1度、通過率と実績を見ながら条件を調整する会議を設ける形にすれば、条件が実態から離れません。

SLAという考え方

引き渡しのルールを整備する際、SLAという枠組みが役に立ちます。部門間の約束を明文化する考え方です。

SLAはService Level Agreementの略で、日本語ではサービスレベル合意書と訳され、サービス提供者と顧客との間でサービス内容とその品質レベルを合意して明文化した文書を指します。この考え方を部門間に適用します。

マーケティングと営業の間で合意する内容は2方向です。マーケティング側は月に何件のMQLを、どの条件で渡すか。営業側は渡されたリードに何時間以内に、どういう方法で対応するか。双方の約束として書きます。

片方向だけの約束にしないことが重要です。マーケティング側の件数目標だけを決めると、質を犠牲にして件数を作る動機が生まれます。営業側の応答の約束もセットにすることで、双方が改善に向かいます。

形式は簡潔で構いません。A4で1枚、両部門の約束が並んで書かれていれば機能するという水準です。詳細な文書を作ることより、参照される状態を保つことが重要です。

引き渡しの方法を決める

条件が決まったら、実際にどう渡すかを決めます。方法が曖昧だと、渡したかどうかの認識がずれます。

引き渡しのルールとしては、商談化の条件、引き渡しの方法（CRM上のステータス変更、通知、口頭でのブリーフィング）、引き渡し時に共有すべき情報を明確化しておくことが組織的な成果につながります。方法は1つに絞ってください。

推奨されるのは、システム上の記録を正とする方法です。CRMのステータスを変更し、その変更が通知として営業に届く形にします。口頭やチャットだけの引き渡しは、記録が残らず、後から確認できません。

通知の設計も含めます。誰に通知が届くか、通知に何が書かれているかを決めます。担当が決まっていない場合は、チーム全体に届く形にし、誰かが受け取った時点でステータスを変える運用にします。

複数の方法を併用しないでください。重要なリードだけ口頭で伝えるという例外を作ると、記録の一貫性が失われることになります。すべて同じ経路で渡す形が確実です。

引き渡し時に渡す情報

リードそのものだけを渡しても、営業側は何から話せばよいか分かりません。あわせて渡す情報を決めておきます。

渡す情報	内容	なぜ必要か
属性情報	企業名・部署・役職・従業員規模	相手の立場を把握して話し方を決める
行動の履歴	閲覧したページ、DLした資料、参加したウェビナー	関心の対象が分かる
入力された内容	問い合わせ本文、アンケートの回答	課題を事前に把握できる
MQL判定の理由	どの条件を満たして渡したか	営業が優先度を判断できる
接触の履歴	これまでに送ったメールと反応	重複した説明を避けられる

4行目が特に重要です。なぜ渡したのかの理由が添えられていれば、営業は対応の優先度を判断できます。理由がないまま渡されると、他のリードと同じ扱いになります。

5行目も見落とされやすい項目です。マーケティング側が既に送った内容を営業が知らないと、同じ説明を繰り返すことになります。相手からすると、社内で情報が共有されていない印象を持ちます。

これらの情報は、手作業で転記するのではなくシステム上で参照できる形にします。転記が必要な運用は、忙しい時期に必ず省略されるためです。CRMの画面で確認できる状態が理想です。

受け取り側の応答期限

渡した後の対応について、期限を決めます。ここが決まっていないと、滞留の責任が不明確になります。

決めるのは2つです。1つ目は受け取りの確認の期限で、渡されたことを認識してステータスを変えるまでの時間です。2つ目は最初の接触の期限で、実際に電話やメールで連絡するまでの時間です。この2つを分けて決めます。

期限の目安は、リードの種類によって変えます。問い合わせや見積依頼は当日中、資料ダウンロードからのMQLは翌営業日中といった配分が現実的です。すべてに同じ期限を設けると、守れない期限になります。

期限を守れなかった場合の扱いも決めておきます。責任を追及する運用にすると、記録が正確でなくなります。守れなかった件を集計して、原因が仕組みにあるかを検討する形にしてください。

期限の設定は、営業側の実務と照らして決めます。営業が守れない期限を設定すると、ルール全体が形式的なものになるためです。実行できる水準から始めてください。

差し戻しのルール

渡したリードが条件に合わなかった場合、差し戻す仕組みが必要です。これがないと、条件の精度が上がりません。

差し戻しの条件を決めます。対象外の業種だった、個人での問い合わせだった、競合他社からの情報収集だった、時期がまったく合わなかった。こうした理由を選択式で記録できる形にします。

記録することが目的です。差し戻しの理由が集計されれば、MQLの条件のどこを直すべきかが分かります。理由を書かずに差し戻す運用では、改善の材料が残りません。

差し戻されたリードの扱いも決めます。完全に対象外なら除外し、時期が合わないだけなら育成の対象に戻します。後者は数か月後に再びMQLになる可能性があります。

差し戻し率も指標として見ます。差し戻しが3割を超えるなら、MQLの条件が緩すぎるという合図です。この数字を月次で確認すれば、条件の調整のタイミングが分かります。

決める項目の一覧

ここまでの内容を、決めるべき項目として整理します。この一覧が埋まれば、ルールとして機能します。

• MQLの属性条件（業種・企業規模・役職）を具体的に定めてある
• MQLの行動条件（どの行動を何回で満たすか）を定めてある
• 引き渡しの方法を1つに決め、記録が残る形にしてある
• 引き渡し時に共有する情報の項目を決めてある
• 受け取り確認と最初の接触の期限を、リードの種類ごとに定めてある
• 差し戻しの理由を選択式で記録できる形にしてある
• 四半期ごとに条件を見直す場を定例化してある

7項目のうち、最初の2つに時間をかけてください。条件の定義が曖昧なままでは、他の項目を決めても運用が安定しません。過去の実績を確認する作業を含めて、半日程度を確保する価値があります。

残りの項目は、決めれば終わる性質のものです。方法、情報、期限、差し戻し。いずれも打ち合わせで決められます。決めた内容を1枚の文書にまとめ、両部門で共有してください。

7項目目の定例化を忘れないでください。見直しの場がないルールは、実態から離れたまま残り続けることになります。四半期に30分でも足ります。見直しの結果として条件を変えた場合は、変更した日付と理由を記録に残してください。後から通過率の変化を振り返るときの材料になります。

運用の手順

ルールを作って運用に乗せるまでの手順を示します。合意の作り方が要点になります。

1番目を飛ばして条件を決めると、根拠のない基準になります。実績から作った条件は、営業側も納得しやすくなります。この作業に時間をかけるほど、後の運用が安定します。

5番目の見直しは、最初の1か月では大きく調整が入ります。初回の条件設定は仮のものと考え、1か月後の調整を前提にすると、決める作業が進みます。

数字で見直す

運用が始まったら、数字で状態を確認します。見る指標は多くありません。

見るのは4つです。MQLの件数、MQLからSQLへの通過率、差し戻し率、そして渡してから最初の接触までの平均時間です。この4つで、条件と運用の両方の状態が分かります。

通過率が低い場合は条件が緩く、MQLの件数が足りない場合は条件が厳しいという判断になります。両方が同時に問題になる場合は、条件の項目自体が実態と合っていない可能性があります。

応答時間が長い場合は、通知の設計か担当の割り振りに問題があります。条件を直しても改善しないため、原因の切り分けが必要です。営業側に理由を聞くのが早い解決方法です。

4つの数字を月次で並べて記録してください。推移が見えると、施策の効果と原因の関係が判断できるようになるという効果があります。数字を並べた表を1枚作り、月初に更新する運用にしてください。関係者が同じ表を見る状態になれば、認識のずれも起きません。

やりがちな失敗

リードの引き渡しで見られる失敗を挙げます。いずれも部門間の合意の不足から起きます。

• MQLの件数だけを目標にする：質を犠牲にして件数を作る動機が生まれ、営業からの信頼が下がります
• 条件をマーケティング側だけで決める：営業の実感と合わず、渡されたリードが放置されます
• 差し戻しの理由を記録しない：条件を改善する材料が残らず、同じ問題が続きます
• 重要なリードだけ口頭で渡す：記録が残らず、後から状況を確認できません

1つ目は、目標設定の構造から生まれる問題です。MQLの件数と、そこからの通過率を並べて目標にすれば、質と量の両方が意識されます。件数だけの目標は避けてください。

• ルールの文書は1枚に収める。詳細な規定は参照されなくなる
• 条件の変更履歴を残しておくと、通過率の変化と条件の関係を後から確認できる

この整備でAIを使う場所

引き渡しのルール作りでは、実績の分析と文書化の作業が中心になります。生成AIが効くのはこの部分です。

分析の場面では、商談になったリードとならなかったリードの一覧を渡して、共通点を整理させる使い方があります。属性と行動の組み合わせのうち、どの要素が商談と関連しているかを整理させると、条件の候補が出ます。

文書化の場面では、決めた内容をルールの文書としてまとめる作業に使えます。打ち合わせの内容を渡して、両部門の約束として1枚にまとめさせる形です。表現の統一も同時に行えます。

あわせて、差し戻しの理由の選択肢の設計にも使えます。過去の差し戻し事例を渡して、分類の案を出させる。選択肢が適切なら、記録の負荷が下がります。

判断は人が行う前提です。どの条件でリードを渡すかは、事業の方針に関わる判断であり任せられない領域です。材料の整理と文書化に限定して使ってください。

まとめ

マーケティングが渡したリードが営業で放置される原因は、渡す条件と渡した後の対応を決めていないことにあります。BtoBではMQL、SAL、SQL、SQOの4ステージで整理すると、どこで滞留しているかが見えます。MQLの条件は属性条件と行動条件を組み合わせ、過去の実績から両部門で合意して決めてください。あわせて、引き渡しの方法を1つに絞り、共有する情報の項目、応答の期限、差し戻しの理由の記録までをセットで決めます。MQLの件数だけを目標にすると質が犠牲になるため、通過率と並べて見る形にしてください。まずは商談になったリード20件の共通点を確認するところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。