インサイドセールスのハンドオフ基準｜マーケからのリード提供とFSへのトスアップ

マーケが渡したリードにインサイドセールス（IS）がなかなか動かない。逆に、ISが「これは商談化した」と渡した案件を、フィールドセールス（FS）が「質が低い」と突き返してくる。分業型の営業組織を運用していると、こうした部門間のすれ違いが日常的に起きます。原因は担当者のスキルではなく、「どの状態になったら次の部門へ渡してよいか」という基準が担当者の感覚任せになっていることにあります。この記事では、マーケ→IS、IS→FSの2つの接続点それぞれで、引き渡し基準を客観的な条件として設計し、明文化し、運用に定着させる手順を説明します。分業型営業組織の連携の全体像はインサイドセールス組織とマーケ・FSの連携を参照してください。

ハンドオフ基準とは｜引き渡しルールを客観条件にする

ハンドオフ基準とは、部門間でリードや商談を引き渡すときに「渡してよい状態」を客観的な条件として定めたルールのことです。マーケからISへ、ISからFSへと顧客との接点が受け渡されるとき、「なんとなく良さそう」「温度が高そう」といった担当者ごとの感覚で判断すると、渡す側と受け取る側の期待がずれ、必ず摩擦が起きます。基準を条件として明文化すれば、誰が判断しても同じ結論になり、この摩擦を大きく減らせます。この記事が扱う接続点は、マーケ→IS（MQLの引き渡し）とIS→FS（SQLのトスアップ）の2つです。それぞれで「何を確認できたら渡してよいか」を具体的に設計していきます。

ハンドオフで成果が漏れる仕組み

分業型（The Model型：マーケ・IS・FSなどが役割を分担し、リードを段階的に引き継ぐ営業モデル）では、1人が最初から最後まで担当する形に比べて「渡す」「戻す」という工程が新たに発生します。この工程がきちんと設計されていないと、渡す側は「渡した後は相手の仕事」と考え、受け取る側は「渡されたものの質が低い」と不満を持ちます。分業によって各部門が専門領域に集中できるはずのメリットが、接続点の摩擦によって相殺されてしまうわけです。ハンドオフ基準は、この接続点を「感覚の受け渡し」から「条件を満たしたものの受け渡し」へ変える仕組みです。

基準を明文化する効用

基準を客観条件にすると、まず摩擦が減ります。渡す側と受け取る側で「渡してよい状態」の認識が一致するため、突き返しや放置が起きにくくなります。次に選別の工数が減ります。ISが「本当に対応すべきリードか」を毎回ゼロから判断する手間がなくなるためです。そして受注率が改善します。FSが提案に集中できる案件だけを受け取れるようになるからです。

この効用は、営業生産性の観点で整理すると位置づけがはっきりします。営業生産性は「（商談数 × 受注率 × 単価）÷ 工数」で表せます（Mazricaの営業生産性フレームワーク）。質の高い案件だけがFSに渡ることで受注率という分子が上がり、ISが選別に費やす工数という分母が下がります。ハンドオフ基準は、分子と分母の両方に効く施策です。

マーケ→ISのハンドオフ基準｜MQLの定義とリード提供の条件

マーケからISへ渡す基準は、MQL（Marketing Qualified Lead：マーケが商談化の見込みありと判断したリード）を、属性条件と行動条件の2軸で定義するのが実務の定石です。この定義がないと、マーケは獲得した全リードをそのままISへ流し、ISは「動くべきリード」を毎回自分で選別することになります。結果として、ISの時間の多くが選別に消え、対応スピードが落ちて有望なリードを取りこぼします。以下では、属性と行動の掛け合わせでMQLを定義する方法と、その定義をマーケ単独で決めない進め方を説明します。

MQLを属性条件と行動条件で定義する

MQLは、リードの「素性」を示す属性条件と、「関心の高さ」を示す行動条件の掛け合わせで判定します。両方が一定水準を超えたときにISへ渡すのが基本です。

• 属性条件：業種、従業員規模、事業領域、リードの役職（決裁層か担当層か）など、自社のターゲット像に合致するかを示す情報
• 行動条件：料金ページの閲覧、導入事例や比較資料のダウンロード、セミナー・ウェビナーへの参加、複数回のサイト訪問など、検討が進んでいることを示す行動

属性だけが合っていても行動が伴わなければ「今は動くタイミングではない」ですし、行動が活発でも属性がターゲット外なら受注につながりにくいものです。この2軸を組み合わせることで、「ターゲット企業で、かつ検討行動が見えるリード」だけをISへ渡せます。

スコアリングで今すぐ度を見極める

属性と行動を定性的に判断するだけでは、担当者ごとにばらつきます。そこで使われるのがリードスコアリングです。属性ごとに点数（例：ターゲット業種+10点、決裁層+15点）、行動ごとに点数（例：料金ページ閲覧+20点、資料DL+10点）を割り当て、合計が閾値を超えたリードを自動的にIS通知の対象にする考え方です。

このスコアリングとリード通知を自動化する役割を担うのがMA（マーケティングオートメーション：商談化前のリード獲得・育成を自動化するツール）です。MAで行動データを蓄積し、閾値を超えた瞬間にISへ渡せば、有望なリードへの初回接触を早められます。スコアの点数配分そのものが「MQLとは何か」の定義になるため、配分の設計は次に述べるすり合わせと一体で行います。

マーケとISでMQL定義をすり合わせる進め方

MQLの定義をマーケ単独で決めると、ISが受け取ったときに「これは動けない」というリードが混ざり、接続点で摩擦が起きます。定義は、受け取る側であるISと必ずすり合わせて決めます。

実務では、過去に「ISが実際に動いて商談化したリード」の共通点を逆算するのが有効です。商談化したリードの属性と、商談化前にどんな行動を取っていたかを洗い出し、その特徴を満たすものをMQLの条件として定義します。感覚で「良さそうなリード」を決めるのではなく、成果につながった実績から条件を組み立てるため、マーケとISの認識が一致しやすくなります。定義を決めた後も、後述する振り返りで継続的に調整します。

IS→FSのハンドオフ基準｜SQL（質の高いトスアップ）の条件

ISからFSへ渡す基準は、SQL（Sales Qualified Lead：FSが提案・商談を進める価値があるとISが判断したリードまたは商談）の条件を明確にすることです。この接続点は、分業型の連携で最も摩擦が起きやすい場所です。FSが「渡された商談の質が低い」と突き返す原因のほとんどは、SQLの条件がISとFSの間ですり合っていないことにあります。トスアップ（IS→FSへ商談を引き渡すこと）の基準を、確認済みの事実として定義すれば、この突き返しは大きく減らせます。以下では、摩擦のメカニズムと、BANTを中心にした必須確認項目を説明します。

FSが質が低いと突き返す本当の原因

FSの突き返しは、ISの能力不足で起きているとは限りません。多くは、ISが「どこまで確認できたら渡してよいか」を知らないまま、あるいはISの評価指標が引き渡しの質を歪めているために起きます。

典型的なのは、ISをアポイント獲得数だけで評価しているケースです。ISが「アポ数」というKPIだけで動くと、とにかく面談を設定してFSへ渡すことが目的になり、商談の中身が伴わないまま数だけが積み上がります。渡す側の指標が「数」に偏ると、質が犠牲になる構造がここにあります。SQLの条件を明文化し、ISの評価にも質の観点を組み込むことで、この歪みを正せます。

SQLの必須確認項目

SQLの条件は、BANTと呼ばれる4項目に「課題の言語化と次アクションの合意」を加えた形で設計するのが実務的です。BANTは商談の見込みを測る古典的なフレームで、次の4つの頭文字です。

• Budget（予算）：導入に充てられる予算の有無、おおよその規模を把握できているか
• Authority（決裁）：誰が意思決定するかを把握し、決裁に関わる人物と接点を持てているか
• Need（課題）：解決したい課題が具体的に存在し、自社の提供価値と合致しているか
• Timeframe（時期）：導入・検討の時期が明確か

これに加えて、「顧客の課題が言語化されており、次のアクション（提案・見積・訪問など）が顧客と合意されているか」を確認します。トスアップの閾値としては、4項目すべてが完璧に揃っていなくても、少なくともNeed（課題）が明確でTimeframe（時期）が近く、次アクションが合意されている状態を最低条件にするのが現実的です。予算や決裁の精緻化はFSが商談の中で詰める、という分担も選択肢になります。どこまでを最低条件にするかは、FSと合意して決めます。

温度感を尺度化して属人判断をなくす

現場でよく使われる「温度が高い」「熱いリード」という表現は、担当者ごとに解釈が異なります。ある人の「温度が高い」は「反応が良かった」程度で、別の人の「温度が高い」は「決裁者が導入時期を明言した」を意味するかもしれません。この解釈差が、トスアップの質のばらつきを生みます。

温度感を属人判断から外すには、「温度が高い」を確認済みの事実に分解します。たとえば「予算を把握できているか」「決裁者と接触できているか」「導入時期が明確か」「具体的な課題を把握できているか」という4つの事実を、それぞれ確認済みか未確認かで記録します。温度感という曖昧な言葉を、確認済み事実の数と組み合わせに置き換えることで、誰が判断しても同じ結論になります。これは前項のBANT＋課題の確認項目を、判断の尺度として使い直す整理です。

育っていないリードの差し戻しと継続育成のルール

ハンドオフ基準を作ると、必ず「基準を満たさないリード・商談」が出てきます。これを放置して捨てるのではなく、マーケへ差し戻す（リサイクルする）のか、ISが継続育成するのかを分ける判断ルールをセットで設計します。上位の解説記事の多くは「渡す」基準ばかりを扱い、この「戻す・育て直す」設計を抜かしています。しかし、差し戻しの経路がないと基準を満たさないリードが宙に浮き、せっかく獲得した見込み客が失われます。

差し戻し（リサイクル）の判断基準

差し戻すべきか、育成に回すべきかは、「なぜ今は基準を満たさないのか」で決まります。判断は大きく2つに分かれます。

「課題はあるが導入時期が先」というリードは、ターゲットとしては有望で、タイミングだけが合っていません。この場合はマーケのナーチャリング（見込み客を継続的に育成すること）へ差し戻し、時期が来たときに再びISへ渡せるようにします。一方、「そもそもターゲット外」「課題が自社の提供価値と合致しない」というリードは、育成しても受注につながりにくいため、対象外として除外します。この2つを混同して有望なリードまで除外すると機会損失になり、対象外のリードまで育成し続けると工数の無駄になります。戻し先を「時期の問題か、適合の問題か」で切り分けるのが要点です。

差し戻しを摩擦なく回す記録の残し方

差し戻しは、理由をデータとして残さないと同じ摩擦が繰り返されます。理由が記録されていないと、一度差し戻されたリードが後日また同じ状態でISへ流れ、ISが再び選別に時間を取られます。差し戻しのたびに、フェーズ（どの段階で戻したか）と差し戻し理由をコード化して記録し、次にそのリードを扱うときに履歴を参照できるようにします。理由がデータで残っていれば、マーケ側も「どういうリードが差し戻されやすいか」を分析でき、MQLの定義そのものの改善につながります。

ハンドオフ基準を運用に定着させる進め方

ハンドオフ基準は、決めることよりも運用に定着させることのほうが難しい課題です。せっかく明文化しても、日々の業務の中で守られなければ意味がありません。定着のためには、部門間で合意（SLA）を交わし、それをSFA/CRMのフェーズ条件として仕組みに埋め込み、定期的に振り返って更新する、という流れで回します。基準を文章のドキュメントだけに置くと形骸化しやすいため、日々の入力や進捗管理の仕組みに組み込むことが定着の鍵になります。

部門間でSLAを交わす

SLA（Service Level Agreement：部門間で「何を・いつまでに・どの品質で渡すか」を取り決めた合意）を交わすことで、ハンドオフを「お願い」から「約束」に変えます。片方だけが基準を守っても連携は改善しないため、相互に約束を交わすのがポイントです。

マーケ側は、ISへ供給するリードの数と質（MQL条件を満たすこと）を約束します。IS側は、受け取ったリードへの対応スピード、たとえば「MQL通知から初回接触まで何時間以内に行う」といった対応時間を約束します。IS→FSの接続点でも同様に、ISはSQL条件を満たした商談を渡すこと、FSは受け取った商談へ何営業日以内に着手することを取り決めます。数字を含めて相互に約束することで、どちらか一方に負担が偏る事態を防げます。

基準をSFA/CRMのフェーズ条件に落とし込む

属人化を解消するには、データを一元化するだけでなく、プロセスを標準化する視点が欠かせません。SFA/CRMは単なる情報の入れ物ではなく、営業のプロセスそのものを標準化し、誰がやっても一定の質で回る状態をつくるための仕組みでもあります。ハンドオフ基準を文章のルールで終わらせず、この仕組みに埋め込むことで、基準が守られている状態を自然に担保できます。

具体的には、SQLの確認項目（予算・決裁・時期・課題）を案件のフェーズごとの必須項目として設定し、それが埋まらないと次のフェーズへ進められないようにします。たとえばMazrica SalesのようなSFA/CRMでは、フェーズごとに必須項目やコメントを設定でき、条件を満たさない案件は次フェーズへ進められないようにできます。また、案件ボードでは直近のアクション状況に応じて色分け（1週間以内にアクションがあれば青、1か月以内なら黄、1か月以上なければ赤）で表示され、放置された案件が一目で分かります（Mazrica Salesの機能）。こうした仕組みを使えば、トスアップ基準が担当者の記憶や善意ではなく、システム上の制約として担保されます。

定期的な振り返りで基準を更新する

一度決めたハンドオフ基準が、いつまでも正しいとは限りません。市場や商材が変われば、MQL・SQLの条件も見直しが必要です。受注データと失注データを定期的に振り返り、「SQL条件を満たしていたのに失注した商談」「基準を満たさなかったのに受注した商談」を洗い出して、閾値が妥当かを検証します。

この振り返りは、部門をまたいだフィードバックの仕組みとして回すことで効果が高まります。FSがつかんだ受注・失注の理由をISやマーケへ戻し、それをもとに基準を更新するサイクルの作り方は、フィードバックループで詳しく扱っています。基準の更新は単発の作業ではなく、この振り返りループの中に組み込むと継続します。

ハンドオフ基準づくりでよくある失敗と回避策

基準を作っても機能しないパターンには、いくつかの典型があります。先回りして知っておくと、設計と運用の落とし穴を避けられます。

基準を厳しくしすぎてリードが渡らない

質を担保しようとMQLやSQLの条件を厳しくしすぎると、条件を満たすリードがほとんど出てこず、FSの商談数が枯れます。質を追った結果、そもそも渡すものがなくなるのは本末転倒です。回避策は、最低条件と理想条件を分けることです。最低条件を満たせば渡し、足りない情報はFSが商談の中で補う、という運用にすれば、質と量のバランスを取れます。

基準が形骸化して「とりあえず渡す」に戻る

基準を文章で決めても、日々の業務では面倒に感じられ、いつの間にか「とりあえず渡す」運用に戻ることがあります。ドキュメントを読み返す習慣は続きません。回避策は、基準をSFA/CRMのフェーズ必須項目として仕組みに埋め込むことです。条件が埋まらないと次へ進めない状態にすれば、守ること自体が業務の一部になり、形骸化しにくくなります。

KPIが単独最適でハンドオフを歪める

ISをアポ数だけ、マーケをリード獲得数だけで評価すると、各部門が自分の数字を最大化しようとして引き渡しの質が犠牲になります。ISは中身の薄い商談でも数を稼ぎ、マーケは質を問わずリードを流します。回避策は、供給の量だけでなく、渡した先での成果（商談化率や受注率）まで含めて評価指標を設計することです。渡した後の結果に責任を持つ指標にすれば、質を意識した引き渡しに変わります。

差し戻し理由が残らず同じ摩擦が再発する

差し戻したリードの理由が記録されないと、同じリードが後日また同じ状態で流れてきて、選別の手間が繰り返されます。人の記憶に頼ると、なぜ戻したかは忘れられます。回避策は、差し戻し理由をコード化してデータで残すことです。履歴が残れば、次に扱うときに一目で状況が分かり、マーケのMQL定義の改善材料にもなります。

まとめ

ハンドオフ基準は、どこから手をつけるかを状況に応じて決めると効果が出やすくなります。FSからの突き返しが多い組織は、まずSQLの必須確認項目（BANT＋課題の言語化と次アクションの合意）を明文化し、ISとFSで最低条件をすり合わせるところから始めるとよいでしょう。マーケ由来のリードにISが動かない組織は、MQLの定義をマーケ・ISの2部門ですり合わせ、過去に商談化したリードの共通点から条件を逆算するのが第一歩になります。

最初の一歩は小さく具体的にするのが続けるコツです。たとえば、直近3か月の失注商談を10件だけ見返し、SQL条件のどれが欠けていたかを洗い出してみてください。それだけで、自社のトスアップ基準に足りない確認項目が見えてきます。そこから基準を明文化し、SFA/CRMの仕組みに落とし込み、振り返りで更新していく流れをつくれば、部門間の摩擦は着実に減っていきます。分業型営業組織の連携の全体像はインサイドセールス組織とマーケ・FSの連携で確認できます。

よくある質問

Q MQLとSQLの違いは何ですか。

A

MQL（Marketing Qualified Lead）は、マーケが「商談化の見込みあり」と判断したリードで、属性条件と行動条件を満たした段階を指します。SQL（Sales Qualified Lead）は、ISが実際に接触して予算・決裁・課題・時期などを確認し、FSが提案を進める価値があると判断した商談です。MQLはマーケ→ISの引き渡し基準、SQLはIS→FSの引き渡し基準という位置づけの違いがあります。

Q ハンドオフ基準はマーケ・IS・FSの誰が決めるべきですか。

A

どれか1部門が単独で決めるべきではありません。MQLの定義は渡す側のマーケと受け取る側のISで、SQLの定義はISとFSで、それぞれすり合わせて決めます。渡す側だけで決めると受け取る側が「これでは動けない」となり、受け取る側だけで決めると渡す側が満たせない条件になりがちです。関係する両部門の合意で決めることが、摩擦を減らす前提になります。

Q SDRとBDRでハンドオフ基準は変えるべきですか。

A

変えるのが自然です。SDR（Sales Development Representative：インバウンドのリードに対応する反響型のIS）は、マーケが獲得したリードを受けるため、MQLの行動条件（資料DLや問い合わせなど）が起点になります。BDR（Business Development Representative：アウトバウンドで新規開拓するIS）は、自ら接触した企業が対象のため、属性条件（ターゲット企業への合致）とアプローチ後の反応が起点になります。リードの入り口が違うので、渡してよい状態の条件も分けて設計します。

Q トスアップした商談をFSが差し戻すときのルールはどう決めますか。

A

差し戻しの条件と理由コードを、ISとFSで事前に合意しておきます。「どの確認項目が欠けていたら差し戻すか」を明文化し、差し戻す際はフェーズと理由をデータで記録します。理由が残らないと同じ商談が再び同じ状態で流れ、摩擦が繰り返されます。また、差し戻しが多発する場合はSQL条件そのものの見直しサインなので、振り返りの材料として活用します。

Q ハンドオフ基準はどのくらいの頻度で見直せばよいですか。

A

決まった正解はありませんが、受注・失注データが一定量たまるタイミング、たとえば四半期ごとに振り返るのが現実的です。市場環境や商材、ターゲットが変われば基準も陳腐化します。「SQL条件を満たしていたのに失注した」「満たさなかったのに受注した」商談を検証し、閾値がずれていれば更新します。フィードバックの仕組みの中に組み込むと、見直しが単発で終わらず継続します。

Q 小規模組織でもハンドオフ基準は必要ですか。

A

役割分担がある限り、規模が小さくても必要です。1人が複数の役割を兼ねる組織でも、「どの状態になったら次の工程へ進めるか」の基準がなければ、判断がその日の気分や記憶に左右されます。最初から精緻なスコアリングを組む必要はなく、SQLの最低確認項目を数個決めるだけでも、判断のばらつきと取りこぼしを減らせます。組織が大きくなったときに基準を拡張していく土台にもなります。