インサイドセールスとフィールドセールスの違いは、商談に進めるかを判断する役割と、提案・交渉を通じて受注まで進める役割にあります。引き継ぐ目安は、相手の課題が具体的に分かり、次の商談に応じていて、自社が対象とする企業の条件に当てはまることです。分業する際は、渡す条件に加えて、受け入れられなかったリードを誰が引き取り、いつ再び接触するかまで決めておきます。
HubSpotを使ってリードを蓄積していても、商談を渡す側と受け取る側の判断が異なれば、営業への通知を増やすだけでは解決しません。「商談として受け入れたのか」「追加で聞くことがあるのか」「時期を待つのか」を記録し、それぞれに担当者と次の行動を割り当てる必要があります。
インサイドセールスとフィールドセールスは何が違うのか？
| 項目 | インサイドセールス | フィールドセールス |
|---|---|---|
| 主に扱う段階 | リードへの接触から、商談に進めるかの判断まで | 商談から受注まで |
| 主な仕事 | 課題や検討状況を聞く、商談への意向を確かめる、時期が早いリードとの接点を保つ | 提案、見積もり、交渉、クロージング |
| 判断すること | この相手と、今、何を目的に商談するか | 誰に何を提案し、どのように受注を目指すか |
| 見る指標 | 接触数、商談にした件数、渡した商談が受け入れられた割合 | 受注数、受注率、受注までの日数 |
| HubSpotで主に扱う記録 | コンタクトのライフサイクルステージ、リードステータス、接触内容 | 取引と取引のステージ、提案・交渉の内容 |
違いは、訪問するかどうかではありません。フィールドセールスがWeb会議で提案していても、受注に向けて商談を進めているなら、その役割はフィールドセールスです。
また、インサイドセールスの仕事を「日程を取ること」だけにすると、商談の目的が曖昧なままフィールドセールスへ渡されます。日程だけでなく、相手が何を相談したいのか、次の商談で何を扱うのかまで共有して、引き継ぎとします。
どの状態のリードをフィールドセールスへ渡せばよいか？
基本となるのは、次の条件です。
-
相手の課題が具体的に分かっている
-
相手が次の商談に応じている
-
自社が対象とする企業の条件に当てはまる
ただし、「課題あり」「商談希望」と記録するだけでは、受け取る側が提案を準備できません。相手の発言と、担当者の解釈を分けて残します。
例えば、「営業の効率を上げたい」という発言だけなら、何に時間がかかっているのかは分かりません。「見込み顧客への連絡を担当者ごとに管理していて、連絡漏れがある」と聞けていれば、次の商談で扱う内容を絞れます。
BANTは聞く項目の整理に使う
BANTは、Budget（予算）・Authority（決裁権）・Need（必要性）・Timeline（導入時期）を整理する枠組みです。すべてを引き継ぎの必須条件にする必要はありません。
予算が未定でも、具体的な課題があり、解決方法を比較するために提案を聞きたい相手はいます。一方、予算と導入時期が分かっていても、自社で対応できない課題なら、そのまま商談として渡すべきではありません。
予算や決裁者について聞けていない場合は、空欄にせず、「相手も未定」「担当者がまだ聞いていない」「次の商談で聞く予定」を区別します。情報がない理由によって、フィールドセールスの準備が変わるためです。
| リードの状態 | 引き継ぎの扱い | 次に行うこと |
|---|---|---|
| 資料請求やセミナー参加だけ | その行動だけでは渡さない | インサイドセールスが関心のある内容と課題を聞く |
| 課題は分かったが、商談には応じていない | まだ渡さない | 必要な情報を送り、再び接触する日を決める |
| 課題が具体的で、商談への同意があり、対象企業の条件に合う | 引き継ぎの候補とする | 商談の目的と、分かっている情報を共有する |
| 商談を希望しているが、対象企業の条件に合わない | 通常の引き継ぎから外す | 対象外とする理由を記録する |
マーケティングからインサイドセールスへ渡すMQLの基準と、フィールドセールスへ渡す基準は別に扱います。MQLになったことを、そのまま商談化の条件にしないようにします。
MQLの判定と部門間の取り決めについては、MQLの判定基準とSLAの決め方で詳しく解説しています。
自社に合う引き継ぎ基準はどう決めればよいか？
過去の受注・失注の取引を比べるときは、引き継ぎの時点で分かっていた情報に限って比べるのが原則です。
受注した取引には、商談を進める途中で聞いた予算や決裁者の情報も残っています。それを引き継ぎ時点の情報として扱うと、インサイドセールスに、初回の接触では聞きにくい内容まで求める基準になってしまいます。
Step.1：受注・失注の取引を同じ条件で集める
比較する期間や商材、対象企業の条件をそろえ、受注と失注の取引を並べます。異なる商材や顧客層を一緒に扱うと、引き継ぎ基準の違いなのか、商材や顧客層の違いなのかを判断しにくくなります。
また、フィールドセールスが受け入れなかった取引と、受け入れた後に提案・交渉を経て失注した取引は分けます。「商談にするには早かった」と「商談として成立したが受注には至らなかった」は、見直す内容が異なります。
Step.2：引き継ぎ時点の情報を取り出す
接触履歴や引き継ぎ時の記録を読み、次のような表に整理します。
| 比べる項目 | 記録する内容 |
|---|---|
| 課題 | 相手の発言と、困っている業務 |
| 次の商談への同意 | 何を相談するために商談へ進んだか |
| 対象企業との適合 | 自社の対象条件に合っていたか |
| 導入時期 | 時期が明らかだったか、未定だったか、聞いていなかったか |
| 予算 | 予算の有無や、予算を検討する段階 |
| 決裁の流れ | 誰が検討し、誰が承認するか |
| 情報が分かった時点 | 引き継ぎ前か、引き継ぎ後か |
当時の記録がなければ、「不明」とします。現在のプロパティの値を見て、過去にも分かっていたはずだと補わないことが大事です。
Step.3：必須条件と商談で聞く項目を分ける
受注した取引で共通していた項目を、すぐにすべて必須にするのは避けます。失注した取引にも同じ項目がそろっていれば、その項目だけでは引き継ぎの判断材料になりません。
また、予算が分からないまま受注した取引があるなら、「予算が分かっていること」を一律の条件にする理由は薄くなります。
整理するのは、次の区分です。
-
渡す前に必要な情報：商談として受け入れるかを判断するための情報
-
分かっていれば渡す情報：提案の準備に役立つ情報
-
次の商談で聞く情報：フィールドセールスが相手と話しながら具体化する情報
過去の記録が足りない項目は、仮の基準として扱い、今後の引き継ぎで記録をそろえます。
Step.4：受け入れの結果と受注の結果を分けて見直す
引き継ぎ後は、フィールドセールスが受け入れた割合と、その後の受注率を分けて見ます。
受け入れられない商談が多いなら、引き継ぎ条件や情報の伝え方を見直します。受け入れられているのに失注が多いなら、引き継ぎ条件だけでなく、提案内容や商談中に分かった事情も調べます。失注をすべてインサイドセールスの判断の問題にしないことです。
弊社がBtoB企業でマーケティング・営業に関わる480名を対象に実施した「MA活用実態調査（第0回）」では、MAを導入している企業の担当者134名のうち、MAが商談・売上に貢献していると答えた担当者（42名）で「マーケティングと営業がスムーズに連携している」と答えた割合は78.6％、そうでない担当者（92名）では6.5％でした。一方、「営業への通知・トスアップ」の機能を使っている割合は61.9％と60.9％で、ほとんど差がありませんでした。
この結果は関連を示すものであり、因果関係を示すものではありません。引き継ぎ基準や差し戻しのルールがこの差を生んだとまでは言えませんが、通知機能の利用と、担当者が感じる連携の円滑さは分けて考える必要があります。
出典：株式会社Sells up「MA活用実態調査（第0回）」。調査主体：株式会社Sells up／調査ツール：Surveroid（2026年9月、回答者480名）。
HubSpotでは引き継ぎをどこに記録すればよいか？
Marketing Hub Professionalだけで運用する場合は、ライフサイクルステージ、コンタクトのリードステータス、取引、カスタムプロパティを使い分けます。
すべての状態をライフサイクルステージだけで表そうとすると、「営業対象ではあるが時期が早い」「取引はあるが受け入れ判断が済んでいない」といった違いが見えにくくなります。
ライフサイクルステージと対応状況を分ける
HubSpotの標準のライフサイクルステージは、購読者（Subscriber）・リード（Lead）・MQL・SQL・商談（Opportunity）・顧客（Customer）・エバンジェリスト（Evangelist）・その他（Other）です。
引き継ぎでは、主にMQL・SQL・商談を使います。ただし、「SQLにしたら引き継ぎ完了」ではなく、フィールドセールスの受け入れ結果を別に残します。
| 記録先 | 記録する内容 |
|---|---|
| ライフサイクルステージ | マーケティング・営業上の段階 |
| コンタクトのリードステータス | SQLの中での対応状況 |
| 取引と取引ステージ | 個別の商談がどこまで進んでいるか |
| カスタムプロパティ | 受け入れの結果、受け入れなかった理由、再び接触する日など |
コンタクトのリードステータスの標準値は、New・Open・In Progress・Open Deal・Unqualified・Attempted to Contact・Connected・Bad Timingです。
これはSQLの中の対応状況を表す項目です。ライフサイクルステージの代わりとして使うのではなく、SQLを維持したまま時期を待つならBad Timingを使う、といったルールにします。
取引を作るタイミングをそろえる
取引を作成するタイミングは、「インサイドセールスが渡すとき」か「フィールドセールスが受け入れたとき」かを社内でそろえます。
前者なら、受け入れ前の取引と受け入れ後の取引を区別する記録が必要です。後者なら、受け入れ前の判断結果をコンタクト側などに残します。どちらの場合も、取引があることだけで、フィールドセールスが受け入れたとは判断しないようにします。
取引の設定でライフサイクルステージの同期をオンにすると、取引の作成時に関連するコンタクトと会社が商談（Opportunity）へ、取引が受注になったときに顧客（Customer）へ変わります。受け入れ前に取引を作る運用では、この更新も含めて扱いを決めてください。
リードのオブジェクトは契約条件を分けて考える
リードのオブジェクト（Leads）を使うには、Sales Hub ProfessionalまたはEnterpriseが必要で、使う人にはSalesのシートが要ります。Marketing Hub Professionalだけでは使えません。
Marketing Hub Professionalだけの運用で、リードのオブジェクトを前提に引き継ぎ手順を組む必要はありません。既存のライフサイクルステージ、リードステータス、取引、カスタムプロパティで、受け入れと差し戻しを記録します。
リードが営業へ渡らない原因の整理は、HubSpotでリードが営業に渡らないときの見分け方も参考になります。
引き継いだ後は誰がリードと商談を持つのか？
コンタクトの担当者と取引の担当者は別のプロパティで、異なる人を設定できます。ただし、設定できることと、顧客への連絡を誰が担うかは別の話です。
担当者を分けるなら、商談中に顧客へ連絡する人と、差し戻し後に接触を再開する人を明記します。
| 担当の持ち方 | 向いている運用 | 決めておくこと |
|---|---|---|
| コンタクトはインサイドセールス、取引はフィールドセールス | インサイドセールスが継続的な接点を持ち、商談は別の担当者が進める | 商談中の連絡は誰が行うか、差し戻し後に誰が再接触するか |
| コンタクトも取引もフィールドセールス | 商談開始後の連絡をフィールドセールスへまとめる | 差し戻す際に、コンタクトの担当を誰へ戻すか |
前者では、コンタクトの担当者がインサイドセールスだからといって、商談中の相手へ別の営業連絡をしてよいわけではありません。後者では、取引を失注にしただけで、インサイドセールスへの引き継ぎが済んだことにはなりません。
SLAとして取り決める内容も、受け入れ期限だけでは足りません。少なくとも、次をそろえます。
-
フィールドセールスがいつまでに受け入れを判断するか
-
判断結果をどこへ記録するか
-
受け入れなかった場合に何を理由として残すか
-
差し戻し後の担当者を誰にするか
-
次の接触を誰が、いつ行うか
引き継ぐ情報には、課題、検討時期、予算、決裁に関わる人、接触履歴、次の行動を含めます。分からない項目は、そのまま不明として渡し、次に誰が聞くかを添えます。
フィールドセールスが受け入れなかった場合はどう戻せばよいか？
差し戻しでは、「理由を残す」「持ち主を戻す」「作成済みの取引を閉じる」「必要に応じてライフサイクルステージを戻す」を分けて扱います。ステージだけ戻しても、次の担当者と接触日がなければ、リードへの対応は再開されません。
Step.1：受け入れなかった理由を分ける
「質が低い」「まだ早い」だけでは、インサイドセールスが次に何をすべきか判断できません。
| 理由 | 次に行うこと | 持ち直す担当 |
|---|---|---|
| 検討時期が先 | 再び接触する日と、そのときに聞く内容を残す | インサイドセールス |
| 課題が曖昧 | 追加で聞く項目を具体化する | インサイドセールス |
| 対象企業の条件に合わない | 対象外とする理由を残す | 社内ルールに沿って割り当てる |
| 次の商談の目的が共有されていない | 相手の意向と商談の目的を聞き直す | インサイドセールス |
| 決裁に関わる人への接点が足りない | 次に接触する相手と方法を相談する | 両部門で担当を指定する |
決裁者本人と話せていないことだけを理由に、機械的に戻すのは避けます。現在の窓口と商談を進めながら、関係者へ接点を広げる方がよい場合もあるためです。
Step.2：再び接触する日と担当者を残す
「時期が来たら連絡する」では、担当者が接触時期を判断できません。カスタムプロパティなどに、再び接触する日を残します。
日付に加えて、次の内容も記録します。
-
相手が話していた検討時期
-
今は商談を進めない理由
-
再接触時に聞くこと、送る情報
-
再接触する担当者
相手の時期が不明なら、まず担当者が改めて時期を尋ねる日を設定します。「検討時期が分からない」と「次に連絡する日を置かない」は別です。
Step.3：作成済みの取引を閉じる
商談として進めないと判断した作成済みの取引は、Closed lost（失注）で閉じ、理由を残す運用にします。取引を開いたまま残すと、進行中の商談との区別がつきにくくなります。
このとき、「受け入れ前に差し戻した取引」と「受け入れ後に失注した取引」を、カスタムプロパティなどで区別します。前者を含めて一括で受注率を見ると、引き継ぎの判断と商談中の提案結果を混同するためです。
取引を閉じることは、そのコンタクトとの接点を終えることではありません。時期が早い相手なら、取引は閉じたうえで、インサイドセールスが接触を続けます。
Step.4：必要な場合だけライフサイクルステージを戻す
HubSpotのライフサイクルステージは、標準の自動更新では前にしか進みません。前のステージへ戻すには、値を消してから設定し直すか、ワークフローで前のステージを設定します。
ただし、差し戻されたリードをすべてMQLへ戻す必要はありません。
| 差し戻し後の判断 | ステージの扱いの例 |
|---|---|
| 営業対象としては妥当だが、検討時期が先 | SQLを維持し、リードステータスをBad Timingにする |
| SQLの条件を満たしていなかった | 自社の定義に沿ってMQLやリードへ戻す |
| 取引作成で商談へ進んだが、受け入れられなかった | 取引を閉じたうえで、SQLなど適切な段階へ戻す |
表は運用例です。自社のSQLの定義に沿って使い分けてください。
取引をClosed lostにする処理と、ライフサイクルステージを戻す処理は分けて扱います。失注にしただけで以前のステージへ戻ることを前提にしないようにします。
また、同期によって会社側も商談へ進んでいた場合は、コンタクトだけを見て作業を終えないことです。ただし、同じ会社に別の進行中の取引がある、すでに顧客であるといった場合に、今回の差し戻しだけを理由に会社のステージまで戻すのは避けます。関連する取引や既存の関係を見て、変更する対象を絞ります。
インサイドセールスとフィールドセールスを分業しないほうがよいのはどんな場合か？
リードが数百件以上あっても、その保有件数だけで分業の適否は判断できません。今接触すべき相手がどれだけいるか、接触から提案までにどれほど個別の理解が必要かを見ます。
次の条件では、同じ担当者が初回接触から受注まで持つ方法も検討に値します。
-
営業の人数が少なく、担当を分けると引き継ぎの負担が増える
-
接触すべきリードが少ない
-
高単価で、商談が長く複雑である
-
顧客ごとの個別の提案が中心である
分業しない場合も、商談へ進める条件や、次に接触する日の記録は必要です。同じ担当者が持つことと、担当者の記憶だけで管理することは分けて考えます。
完全に分けるか、同じ担当者がすべて持つかの二択でもありません。インサイドセールスが初回の商談に同席し、相手から聞いた内容を補足してからフィールドセールスへ引き継ぐ方法もあります。
フィールドセールスへ渡すリードを、MAのデータから選ぶには
LisCoreは、MAに蓄積されたデータを毎日解析し、その日にトスアップする相手を一覧にする自社開発のツールです。2026年11月2日からβ版を提供し、HubSpot Marketing Hubをお使いの企業さまを対象に10社限定で募集しています（募集は2027年3月末まで）。
デモを申し込む →まとめ
インサイドセールスは商談に進めるかを判断し、フィールドセールスは提案・交渉を通じて受注まで進めます。違いは対面か非対面かではなく、担う段階と判断です。
引き継ぎ基準は、過去の受注・失注の取引から、引き継ぎ時点で分かっていた情報を比べて作ります。後から分かった情報を必須条件に混ぜず、渡す前に必要な情報と、商談で聞く情報を分けてください。
HubSpotでは、受け入れの結果、担当者、取引、ライフサイクルステージを別々に扱います。差し戻す場合は、取引やステージを整理するだけでなく、誰が持ち直すかと、再び接触する日まで残すところを一連の手順にします。
よくある質問
インサイドセールスとフィールドセールスは、どちらを先に設けるべきですか？
接触しきれないリードが多く、商談に進める判断を分担したいなら、インサイドセールスの役割を分ける方法があります。リードや営業の人数が少ない場合は、同じ担当者が両方を担う形も選択肢です。役職名を先に置くより、接触と提案のどちらに人手が必要かを見て判断します。
BANTのすべてが分からないと、フィールドセールスへ渡せませんか？
すべてを必須にする必要はありません。課題が具体的で、次の商談への同意があり、対象企業の条件に合うなら、予算や決裁の流れを商談で聞く運用もあります。聞けていない情報は、未定なのか、まだ質問していないのかを分けて渡します。
引き継ぎ後もコンタクトの担当者をインサイドセールスにしてよいですか？
構いません。コンタクトの担当者と取引の担当者は別々に設定できます。ただし、商談中の連絡は誰が担うか、差し戻し後は誰が接触を再開するかを決め、顧客への連絡が重ならないようにします。
フィールドセールスが受け入れなかったら、SQLからMQLへ戻すべきですか？
一律に戻す必要はありません。営業対象として妥当で、時期だけが早いなら、SQLを維持してBad Timingで管理する方法があります。SQLの条件自体を満たしていなかった場合は、MQLなどへ戻します。前のステージへの変更には、値を消して再設定するか、ワークフローで設定する処理が必要です。
Marketing Hub Professionalだけで引き継ぎと差し戻しを管理できますか？
ライフサイクルステージ、コンタクトのリードステータス、取引、カスタムプロパティで記録する運用を組めます。リードのオブジェクトはMarketing Hub Professionalだけでは使えず、Sales Hub ProfessionalまたはEnterpriseと、使う人のSalesのシートが必要です。
