マーケが渡したリードのうち、商談にならなかったものはその後どこへ行っているでしょうか。CRMを開くと、担当営業の名前が付いたまま最終活動が数か月前で止まっているリードが大量に見つかる。営業に聞くと「時期が合わなかった」「何度電話してもつながらなかった」と言うものの、その理由はどこにも記録されておらず、マーケのナーチャリング配信からも外れている。多くの会社で、差し戻しはこうした「誰のものでもない状態」で終わっています。
リードリサイクルで最初に作るべきものは、メールのシナリオではありません。営業が手放すときに理由コードを1つ選ばせ、そのコードだけで戻し先と再び営業に渡す条件が自動で決まるルールを、営業とマーケで先に合意することです。ルールが先にあれば、配信内容はあとから作り込めます。逆に配信だけを先に作っても、戻ってくるリードが入口で止まっていれば何も流れません。
MQLの定義と営業への引き渡しが回り始めた会社で、差し戻されたリードが止まったままになるのは、営業が手放すときの理由コードと、コードごとの戻し先・再び渡す条件が営業とマーケの間で決まっていないときです。配信の中身を作り込むのは、この合意ができてからで間に合います。
目次
リードリサイクルとは｜休眠掘り起こし・失注分析との違い
リードリサイクルとは、営業が追うのをやめたリードを、理由に応じてマーケの管理下に戻し、条件を満たしたら再び営業へ渡す循環の仕組みです。対象は「営業から戻ってくる一件一件」であり、リスト全体への施策ではありません。
営業やインサイドセールスがリードを手放す理由は、大きく3つに分かれます。「今は検討していない」「連絡がつかない」「商談まで進んだが失注した」です。どれも、その時点で営業が時間を使い続ける対象ではなくなったというだけで、将来の見込みが消えたわけではありません。リードリサイクルは、この「手放した瞬間」を仕組みの入口にします。
似た言葉と混同すると、設計すべきものが見えにくくなります。違いは次のとおりです。
| 取り組み | 対象 | 起点 | 主に決めること |
|---|---|---|---|
| リードリサイクル | 営業が手放した一件一件のリード | 営業の差し戻し操作 | 理由コード、戻し先、再引き渡しの条件、所有の移し方 |
| 休眠リードの掘り起こし | 長期間反応がないリスト全体 | マーケの企画 | 対象の絞り込み、再接触のメッセージ、優先順位 |
| 失注分析 | 失注した商談の集合 | 月次などの集計 | 負けた理由の分類と、訴求・ターゲットへの反映 |
リサイクルがうまく回っていれば、休眠リストに落ちるリードの数そのものが減ります。反対に、リサイクルの仕組みがないまま休眠掘り起こしを繰り返すと、毎回「なぜ止まったのか分からないリード」を相手にすることになります。すでに休眠リストが数千件たまっているなら、リサイクルのルールを決めたうえで休眠リードの掘り起こしを一度だけ行い、商談で負けたリードは失注分析で理由を分類してから戻し先を決めます。
差し戻されたリードが放置される構造
放置の原因は営業の怠慢ではなく、手放す操作と受け取る操作が別々になっていることです。所有者・理由・次の日付の3つが記録されないまま担当だけが残るため、誰も動けなくなります。
「対応済み」で止まり、所有者が変わらない
多くのCRMでは、営業がリードに見切りをつけても、担当者欄は営業のまま残ります。営業は「もう自分の案件ではない」と考え、マーケは「営業が持っている」と考える。担当者欄だけを見ると所有者がいるように見えるため、どちらの一覧にも問題として浮かび上がりません。差し戻しとは、所有をマーケへ移す操作であると定義しておく必要があります。
理由が自由記述で、戻し先を決められない
メモ欄に「またの機会に」「不在」とだけ書かれていても、マーケはそれを配信の条件に使えません。自由記述は人が読めば分かりますが、件数が増えると誰も読みません。理由が選択式で残っていないことが、リサイクルを手作業に頼らせる最大の原因です。
ステージが後戻りできず、MQLの実績が揉める
MAやCRMによっては、ライフサイクルステージが前にしか進まない仕様になっています。HubSpotでも既定のライフサイクルステージは、値をいったんクリアしないと前の段階に戻せません。この仕様を知らずに運用すると、営業が手放したリードがMQLやSQLのまま残り、ステージ別の件数が実態と合わなくなります。さらに、戻したリードを再びMQLとして数えると「同じ人でMQLを水増ししている」と営業から指摘され、マーケの実績をめぐる対立の火種になります。ステージの戻し方はHubSpotワークフロー設計の基本でワークフローの組み方として確認できます。
差し戻しは営業の失敗の記録ではなく、所有をマーケへ移す引き渡しの操作です。この定義を最初に両部門で合意しておくと、理由の入力を責められる作業だと受け取られにくくなります。
HubSpotを使っている場合は、HubSpotでライフサイクルステージとリードステータスを分けて設定する方法を先に確認してください。ステージをMQLのまま残し、見送りの状態をリードステータスで持たせる設定例を表で示しています。
差し戻し理由コードの設計
理由コードは「なぜ負けたか」ではなく「次に何をするか」で分けます。1つのコードに1つの戻し先が対応し、営業が10秒で選べる数に絞ることが条件です。
失注分析の理由とは別に作る
失注分析の分類は、原因を掘り下げるために層を分け、ある程度の粒度を持たせます。一方で差し戻しの理由コードは、リードの行き先を決めるための振り分けキーです。目的が違うため、同じ項目で兼ねようとするとどちらも中途半端になります。たとえば失注分析では「価格」と「予算が確保できない」を分けたいことがありますが、戻し先を決めるうえでは「次の予算期まで待つ」という1つの扱いで足ります。商談まで進んだ失注は、失注分析用の理由を別の項目に残したうえで、差し戻し用のコードも選ぶ運用にします。
最初に置くコードは7つ前後
実務上は、次の7つで多くのBtoB商材の差し戻しを説明できます。自社の商材に合わない行は削ってかまいません。
| 理由コード | 営業が選ぶ場面 | あわせて必須にする入力 |
|---|---|---|
| 時期尚早（時期明示） | 検討時期を相手が具体的に口にした | 再接触の目安日 |
| 時期不明 | 関心はあるが、いつ検討するか分からない | 関心を持ったテーマ |
| 予算なし | 今期の予算枠がない、稟議が通らなかった | 予算期の区切り（分かれば） |
| 連絡不通 | 決めた回数と期間の接触で応答がない | 接触した回数と手段 |
| 担当者違い | 話した相手が検討の当事者ではなかった | 本来の担当部署や役職（分かれば） |
| 商談後失注 | 提案まで進んだが他社採用・見送りになった | 失注分析用の理由（別項目） |
| 対象外 | 業種・規模・用途が自社の対象に入らない | 対象外と判断した条件 |
運用ルールは3つだけ決める
1つ目は、コードの選択を差し戻し操作の必須項目にすることです。担当者の変更やステータスの変更と同じ画面で選ばないと保存できない形にします。後から入力を依頼する運用は、ほぼ確実に抜けます。
2つ目は「その他」を置かないことです。置くと、迷ったときの逃げ道として件数の多くがそこへ流れます。どうしても置く場合は、月に一度その中身を読み、3件以上たまった理由を正式なコードに昇格させるか、既存のコードに寄せるかを決めます。
3つ目は、コードを増やすときは戻し先も同時に決めることです。戻し先が同じになるコードは、分ける意味がありません。分析したい細かな事情は、コードではなくメモや失注分析の項目に残します。
理由ごとの戻し先と、戻す期間
戻し先は「日付で呼び戻す列」「行動で呼び戻す列」「閉じる列」の3つに集約できます。コードごとに戻し先を1つに固定すれば、差し戻しと同時に振り分けを自動化できます。
A 日付起点の再接触キュー
「来年度に入ってから」「半年後にリプレースを考える」と相手が時期を口にした場合、そのリードに必要なのは継続的なメールよりも、その日付の少し前に確実に人が連絡することです。再接触の目安日を差し戻し時に入力させ、その日付の2〜4週間前（実務上の目安）になったら営業へ通知が飛ぶようにします。目安日までの間は、通常のメルマガ程度の接点で十分です。頻度を上げると、時期を伝えてくれた相手にとっては「話を聞いていない会社」に見えます。
「予算なし」も同じ列に入れます。予算期の区切りが分かれば、次の予算検討が始まる時期を目安日にします。分からない場合は、相手の決算期から逆算するか、半年後を仮の目安日にしておき、再接触のときに確かめます。
B 行動起点のナーチャリング
時期が分からないリードに日付で連絡しても、当たる確率は低くなります。この列では、関心を持ったテーマに沿ったコンテンツを届け、料金ページの閲覧や資料請求、ウェビナー申込といった新しい行動が出た時点で再判定に回します。配信するテーマは、差し戻し時に営業が記録した関心事から選び、ナーチャリングシナリオの分岐に組み込みます。
「連絡不通」は、メールアドレス自体が生きているかを先に確かめます。配信エラーが返ってくるなら、この列ではなくCの列です。「担当者違い」は、同じ会社の別の人物に接点を広げる施策と組み合わせます。当事者の部署が分かっていれば、その部署向けの資料を案内するだけでも、社内で転送される経路ができます。
「商談後失注」もこの列に入れますが、扱いは慎重にします。失注直後に新規リードと同じ入門的な配信を始めると、提案まで受けた相手には内容が浅すぎます。失注から一定期間は配信を止め、その後は導入事例や製品の更新情報など、比較検討を経た人に意味のある内容から再開します。
C 除外・データ修正
対象外、重複、退職や異動が判明したものは、循環に戻しません。対象外の会社にナーチャリングを続けると、再MQLの判定に誤って引っかかり、同じリードが何度も営業に届く原因になります。重複は名寄せして一方に統合し、退職が分かった場合は配信を止めます。同じ会社の同じ人が2件登録されていたら、リードの名寄せと重複管理のルールに沿って、活動履歴の多いほうに統合します。
再び営業に渡す条件
戻したリードを営業に再び渡す条件は、新規のMQL条件と同じにしません。差し戻した日より後に起きた行動だけで判定し、渡すときには前回の差し戻し理由を必ず添えます。
差し戻し前の行動を数えない
スコアで判定している場合、差し戻し前に積み上がった点数がそのまま残っていると、ほとんど何もしていないリードが数日後に再びMQLになります。営業から見れば「さっき返したリードがまた来た」状態で、仕組みへの信頼を最も早く失うパターンです。差し戻し時に行動系のスコアをリセットするか、差し戻し日以降の行動だけを数える別の条件を用意します。どちらの方法にするかは、MQLの判定条件が属性と行動のどちらに寄っているかで決めます。
コードごとに再浮上の条件を変える
Aの列は日付が来たことが条件です。行動の有無に関係なく、目安日が近づいたら営業に渡します。Bの列は、差し戻し後に比較検討を示す行動が1回以上あったことを条件にします。ブログ記事の閲覧のような軽い行動ではなく、料金や導入事例、問い合わせフォームのような、検討が進んだことを示す行動に限定するのが安全です。「連絡不通」で戻ったリードは、メールへの返信や資料請求など、連絡がつく状態になったことを示す行動を条件にすると、また不通で終わる再引き渡しを減らせます。
渡すときに前回の経緯を添える
再引き渡しの通知には、前回の差し戻し日、理由コード、営業のメモ、差し戻し後に起きた行動を並べます。前回と同じ営業に渡すか、別の営業に渡すかも決めておきます。前回の会話を覚えている担当者のほうが話は早い一方、相性が理由で止まっていた場合は別の担当者のほうが進むこともあります。初期設定は前回の担当者とし、営業責任者が通知を見て変更できる形にしておくと扱いやすくなります。初回の接触で何をどの順に聞くかはBtoBの問い合わせ対応スピードの一次対応の型が、再接触にもそのまま使えます。
循環の回数に上限を置く
同じリードが差し戻しと再引き渡しを何度も繰り返す場合、そのリードには営業の時間を使い続ける価値がない可能性が高いと考えます。差し戻し回数を項目として持ち、たとえば2回目の差し戻しの後は再引き渡しを止めて、通常の配信対象に移す、といった上限を決めておきます。そこから先は、リスト全体を対象にした休眠施策の側で扱います。
再MQLを新規MQLと同じ数字に混ぜて報告すると、マーケの獲得実績が水増しされているように見え、営業との信頼関係を損ないます。再MQLは別の指標として数え、新規と並べて見せてください。
理由コードの数や再浮上の条件は、商材の検討期間と営業の人数で適切な水準が変わります。自社の差し戻しデータをもとに条件を決めたい場合は、現在の引き渡しと差し戻しの流れを一緒に棚卸しする相談もお受けしています。
営業が一度も接触せずに「担当範囲外」として返したリードは、リサイクルではなく割り当ての判定のやり直しで扱います。割り当て時点の差し戻しと再割り当てを分けておくと、理由コードの集計に接触前の返却が混ざりません。
営業とマーケのSLAで取り決める項目
リサイクル用のSLAは、引き渡しのSLAに数行を足すだけで十分です。営業が保持できる期限、差し戻しの入力、マーケが受け取る期限、再MQLの数え方を双方の義務として書きます。
MQLの供給数や初回接触までの時間といった引き渡し側のSLAがまだ決まっていなければ、先にマーケ・セールス連携の仕組みやインサイドセールスとマーケの分担で合意しておきます。そのうえで、戻ってくる流れのために次の項目を追加します。
| 主体 | 取り決める項目 | 書き方の例 |
|---|---|---|
| 営業 | 保持できる最大期間 | 最終活動から一定日数、次の予定がないリードは差し戻す |
| 営業 | 連絡不通と判断する基準 | 決めた期間内に、電話とメールで決めた回数以上接触した |
| 営業 | 差し戻し時の入力 | 理由コードは必須、時期尚早は目安日も必須 |
| マーケ | 戻し先への投入 | 差し戻しから数営業日以内に、コードに対応する戻し先へ入れる |
| マーケ | 再引き渡しの条件と添付情報 | 差し戻し後の行動だけで判定し、前回の経緯を通知に含める |
| 両者 | 再MQLの数え方 | 新規MQLと分けて数え、月次で再MQLからの商談数を確認する |
差し戻しを最も確実に発生させるのは、1行目の「保持できる最大期間」です。これがないと、営業は「いつか連絡するかもしれない」リードを手元に置き続け、差し戻しそのものが発生しません。期間は商材の検討期間から決め、最初は営業が守れる長さで始めて、運用が回ってから短くします。守れない数字を最初に置くと、初月で未達が続いてSLA自体が読まれなくなります。
マーケ側の義務を必ず対にしてください。営業にだけ入力と期限を課すと、一方的な負担の追加として受け取られます。「差し戻してくれたら、数営業日以内に必ず配信に入れ、再び渡すときは経緯を付けて渡す」とマーケが先に約束すると、入力の協力を得やすくなります。
放置されたリードを見つける方法
放置リードは、所有者・最終活動日・次の予定の3項目を組み合わせた一覧で機械的に見つけます。人の記憶や営業への聞き取りに頼ると、毎回同じ漏れ方をします。
週次で見る4つの一覧
次の4つの条件で、CRMに保存済みの一覧を作っておきます。どれも特別な機能は要らず、担当者、ステータス、最終活動日、次回予定日といった基本的な項目で作れます。
| 一覧の名前 | 条件 | 見つかったときの対応 |
|---|---|---|
| 営業保持の停滞 | 担当が営業、商談なし、最終活動から保持期間を超えた | 営業に差し戻しか次の予定の入力を依頼する |
| 未接触のMQL | MQLになってから、営業の活動記録が一度もない | 引き渡しの通知経路と担当割り当てを確認する |
| 行き先のない差し戻し | 差し戻し済みだが、どの戻し先にも入っていない | 理由コードの欠落か振り分けルールの漏れを直す |
| 期日切れの再接触 | 再接触の目安日を過ぎたが、営業の活動記録がない | 通知が届いたかを確認し、担当者を再割り当てする |
一覧を「誰が」「いつ」見るか
一覧は作っただけでは見られません。週次のマーケと営業の定例で、4つの一覧の件数だけを冒頭の数分で確認する運用にします。一件ずつの対応を会議の中で議論する必要はなく、件数が先週より増えたかどうかと、増えた一覧の担当者を確認すれば十分です。
最初に一覧を作ると、過去の放置分が大量に出てくることがあります。これを全部さかのぼって理由コードを付けてもらうのは、営業に過大な負担をかけます。過去分は最終活動日で一括してマーケへ移し、行動起点の列にまとめて入れ、今日以降の差し戻しからルールを適用するほうが現実的です。過去分への再接触を企画として行う場合は、休眠リードの施策として別に扱います。
月次で見る数字
月に一度は、理由コード別の差し戻し件数と、コード別の再MQL率、再MQLからの商談数を並べます。特定のコードだけが急に増えていれば、引き渡し側の条件に問題がある合図です。たとえば「担当者違い」が多いなら、MQLの判定で役職や部署を見ていない可能性があります。この数字はリードの質の議論にもそのまま使えます。営業と「リードの質」を議論するときは、リードの質の評価指標とこの差し戻し件数を同じ表に並べます。
放置は個人の問題ではなく、一覧に出てこない状態の問題です。所有者・最終活動日・次の予定の3項目がそろっていれば、放置は必ず一覧に現れます。
やらない判断と向かない場合
リードの数が少ない会社、営業とマーケを同じ人が担っている会社では、差し戻しの仕組みを作るより、営業が持ち続けて日付で管理するほうが確実です。
実務上の目安として、月に営業へ渡すリードが数件から十数件程度であれば、理由コードと戻し先を作り込む必要はありません。この規模なら、営業が一件ずつ再接触日をカレンダーに入れて持ち続けるほうが、仕組みを保守する手間より小さく済みます。コードを作っても件数が少なすぎて、月次で見ても傾向が読めません。
営業とマーケを1人か2人で兼務している会社も同じです。差し戻しは「所有を別の人に移す」操作なので、移す先が同じ人であれば意味がありません。この場合に必要なのは、ステータスと次回予定日を必ず入力するという1つのルールだけです。
商談サイクルが短く、検討が数週間で決まる商材では、Aの列の出番がほとんどありません。時期を逃したリードは翌月にはほかで導入を決めていることが多いため、差し戻し後はBの列に一本化し、再浮上の条件を問い合わせなど強い行動に絞るほうが合っています。
最後に、対象外のリードを「もったいないから」と循環に戻すのはやめてください。対象外を戻すと再MQLの精度が落ち、営業がリサイクルからの引き渡しを後回しにするようになります。閉じるべきものを閉じることも、仕組みの一部です。
まとめ
- リードリサイクルは、営業が手放した一件一件のリードをマーケに戻し、条件を満たしたら再び営業に渡す循環の仕組みで、休眠リストへの施策や失注分析とは対象も起点も違います。
- 差し戻しは所有をマーケへ移す操作と定義し、理由コードの選択を必須にします。コードは「次に何をするか」で分け、7つ前後から始めます。
- 戻し先は日付起点の再接触キュー、行動起点のナーチャリング、除外とデータ修正の3つに集約し、コードごとに1つに固定します。
- 再び営業に渡す条件は差し戻し後の行動だけで判定し、前回の経緯を添えます。循環の回数には上限を置き、再MQLは新規と分けて数えます。
- SLAには営業が保持できる最大期間とマーケが受け取る期限を対にして書き、放置は4つの一覧で週次に機械的に見つけます。
営業から戻ってくる流れは、一度ルールを決めてしまえば、あとは配信の中身とコードの見直しを続けるだけで回ります。理由コードと戻し先の設計を自社のCRMに合わせて進めたい場合は、ご相談ください。
無料相談
営業から戻ってくるリードの行き先を、一緒に決めます
「営業が手放したリードがどこにあるか分からない」「差し戻しの理由が残っていない」「再MQLをめぐって営業と揉める」。こうした状態は、理由コードと戻し先、再引き渡しの条件を決めるだけで大きく変わります。Ampelは外部CMOとして、現在のCRMの項目と引き渡しの流れを確認し、差し戻しのルールとSLAの追加項目を営業の方と一緒に設計します。
よくある質問
- リードリサイクルとリードナーチャリングは何が違いますか
- ナーチャリングは、まだ営業に渡す段階にないリードを育てる活動全般を指します。リードリサイクルは、そのうち一度営業に渡したあとで戻ってきたリードの扱いに絞った仕組みです。戻ってきた理由が分かっている分、新規リードより配信の出し分けを細かくでき、再び渡すときの条件も変えられます。
- 営業に差し戻しの理由を入力してもらえません。どうすればいいですか
- 入力を依頼するのではなく、差し戻しの操作そのものに理由の選択を組み込みます。担当者やステータスを変える画面で理由を選ばないと保存できない形にし、選択肢は10秒で選べる数に絞ります。あわせて、差し戻されたリードからの再MQLや商談の件数を営業に返すと、入力が自分たちの商談につながっていると実感してもらえます。
- 差し戻したリードをまたMQLとして数えてもよいですか
- 数えること自体は問題ありませんが、新規のMQLとは分けて集計してください。混ぜて報告すると、同じ人物で実績を積み増しているように見え、営業との信頼関係を損ないます。再MQLと、再MQLから生まれた商談数を別の行で示すほうが、リサイクルの成果も説明しやすくなります。
- 失注したリードにはいつ再接触すればいいですか
- 一律の決まりはなく、失注の理由で決めます。時期や予算が理由なら、相手が示した時期や次の予算期の少し前が目安です。他社を採用した場合は、その製品の契約更新や導入後の見直しが起きそうな時期まで、比較検討を経た人向けの情報を控えめに届けながら待つのが基本です。失注理由そのものの分類は失注分析の設計で決めます。
