%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}
この記事の結論
HubSpotでフィールドセールスとインサイドセールスの動きをつなぎます。連携の核心は、トスアップ前後の判断と情報を同じ取引レコードに残すことです。
HubSpotでフィールドセールスとインサイドセールスの動きをつなぎます。連携の核心は、トスアップ前後の判断と情報を同じ取引レコードに残すことです。
「インサイドセールスがアポを取っても、フィールドセールスに引き継いだ途端に案件が止まる」
「商談では同じ質問を繰り返し、顧客に負担をかけている」
「失注後に誰が再接触するのか決まっていない」——こうした状態は、担当者同士の連絡量ではなく、連携の設計から見直す必要があります。
フィールドセールスとインサイドセールスの連携設計とは、案件を渡す条件、引き継ぐ情報、受領後の行動、失注後の戻し先を共通ルールにし、HubSpot上で実行できる形にすることです。分業の境界だけでなく、マーケティングから商談、受注、顧客対応へ続く流れの中に置くことがポイントになってきます。
本記事は「PLG × PLSハイブリッド戦略｜プロダクトレッドと営業レッドを両立する設計」シリーズの一部です。
この記事でわかること
ここでは、FSとISの役割、トスアップ基準、HubSpotでの実装、運用改善の要点を整理します。「インサイドセールスがアポを取っても、フィールドセールスに引き継いだ途端に案件が止まる」とお感じの方に、特に参考になる内容です。
- 分業モデルの基本 — マーケティング、IS、FS、カスタマーサクセスをつなぎ、各部門の役割と受け渡し条件を整理します。
- 連携が止まる原因 — アポ件数だけを追う状態、情報不足、失注後の担当不在がなぜ起きるのかを分解します。
- HubSpotでの実装方法 — 取引ステージ、確度、ステージ定義、必須プロパティを使って連携を仕組みにします。
- トスアップ基準とSLA — BANTを使った判定、引き継ぎ項目、受領後の行動ルールを設計します。
- 分業と協業の使い分け — 標準案件は分業し、複雑な案件は共同対応する判断軸を整理します。
フィールドセールスとインサイドセールスの連携設計とは
FSとISの連携は、アポを取る人と商談する人を分けるだけでは成立しません。顧客情報と判断理由が次の担当へ渡り、受注または失注後の行動までつながっている状態を設計します。
CRMは記録を保管する場所ではなく、営業プロセスを標準化し、部門間の判断をそろえる基盤として使います。
分業の目的は専門化ではなく顧客対応の連続性
- IS ── 初回接触、課題の把握、商談機会の見極めを担います。
- FS ── 提案と意思決定の支援を担います。
役割を分けても、顧客から見れば同じ会社との対話です。そのため、FSが初回商談で会話を最初からやり直す状態では、社内の効率だけでなく顧客体験も損ないます。
連携設計では、誰が何をするかに加えて、前工程で得た情報を次工程がどう使うかまで決めます。ISのヒアリング内容がFSの提案準備に使われ、FSの商談結果がISの見極め基準に戻る循環が必要です。
全体フローの中で受け渡しを位置づける
FSとISだけを切り出すと、マーケティングから届いたリードの扱いや、失注後の再接触が抜けやすくなります。
コンタクトと会社で見込み顧客を把握し、商談化したら取引を作成し、受注後は顧客対応や請求へつなぐ流れとして考えます。
| フェーズ（主な担当） | HubSpotに残す情報 | 次工程への条件 |
|---|---|---|
| 見込み顧客の把握（マーケティング） | 接点、関心、会社情報 | ISが対応対象と判断できること |
| 課題の確認（IS） | 課題、時期、予算、決裁関係 | トスアップ基準を満たすこと |
| 提案と商談管理（FS） | 提案内容、金額、次の行動、結果 | 受注または失注の理由が記録されること |
| 顧客対応（カスタマーサクセス） | 契約内容、要望、対応履歴 | 継続対応に必要な情報が渡ること |
| 請求への接続（営業または管理部門） | 契約後の請求情報 | 契約内容と請求条件が対応すること |
ただし、HubSpotに情報を集めるだけでは連携は改善しません。各フェーズの完了条件と次の担当者の行動が定義されていなければ、データが増えても判断は属人化したままです。
FSとISの連携が止まる原因
連携不全は、担当者の姿勢よりも評価指標と入力ルールの不一致から生まれます。スプレッドシート、チャット、個人メモに情報が分散していると、最新版の判断根拠を探すだけでも負担が増えます。
まずは止まっている地点を、トスアップ前、受領直後、失注後に分けて見ます。
アポ件数だけを追うと判定基準が弱くなる
ISの評価がアポ件数だけに寄ると、課題や時期が曖昧なままFSへ渡しやすくなります。FSは提案へ進めない商談に時間を使い、ISは件数を達成していても受注への貢献を把握できません。
改善するには、アポを取った事実と、FSが提案へ進める状態を分けます。ISの完了条件を「日程を確保した」だけにせず、合意したトスアップ項目が入力され、FSが次の行動を選べる状態まで含めます。
引き継ぎ情報が自由記述だけでは再利用しにくい
「興味がある」「温度感が高い」といった所感だけでは、担当者ごとに意味が変わります。次の項目を選択式や日付などのプロパティで持ち、補足だけを自由記述にすると判断をそろえやすくなります。
- 課題
- 利用中のツール
- 予算
- 導入時期
- 決裁関係
スプレッドシートとチャットを併用している場合は、どちらが正しい情報か分からなくなることがあります。取引レコードを正本にし、チャット通知から取引へ戻れる運用にすると、引き継ぎ後も同じ情報を参照できます。
失注後の戻し先がないと案件が宙に浮く
FSが失注を記録しても、ISへ戻す条件や再接触のきっかけがなければ、その案件は動きません。
失注は営業活動の終点ではなく、理由に応じて再検討を待つか、対象外として閉じるかを分ける地点です。
失注理由は、価格、競合、時期、ニーズ不一致、社内決裁などから選択して記録します。時期が理由なら再接触候補へ戻し、ニーズ不一致なら無理に追わないというように、理由から次の行動を決めます。
トスアップ基準と引き継ぎ情報をそろえる
連携設計の中で重要になるのが、ISからFSへ案件を渡す条件です。基準は担当者の感覚だけに置かず、入力項目と判断ルールに分けます。そのうえで、基準を満たさない案件を育成へ戻す経路も用意します。
BANTを判定項目として使う
BANTは、予算、決裁権、ニーズ、導入時期を整理する考え方です。すべてを一律に満たすことを求めるのではなく、商材と営業プロセスに合わせて、どの状態ならFSが提案へ進めるかを合意します。
| 判定項目（HubSpotでの持ち方） | ISが確認する内容 | FSが見る判断 |
|---|---|---|
| 予算（予算ステータス） | 予算の有無や確保の見込み | 提案範囲を組み立てられるか |
| 決裁権（役職、決裁関係） | 決裁者との関係や社内手順 | 誰の合意が必要か |
| ニーズ（課題カテゴリ、詳細メモ） | 課題と解決したい状態 | 提案テーマが明確か |
| 導入時期（導入検討時期） | 検討時期と背景 | 次の行動日を置けるか |
- 基準が厳しすぎる場合 ── FSが早期に関与した方がよい案件までISで止まります。
- 基準が緩すぎる場合 ── FSが初回確認をやり直します。
商談結果を見ながら、どの項目が受注や失注の判断に使われたかを振り返り、不要な項目は減らします。
BANTに競合と人的リソースを加えて整理する場合は、BANTCHフレームワークの質問例も参照できます。
必須プロパティは次工程が使う項目に絞る
引き継ぎ時に残す候補は、次のとおりです。
- 会社情報
- 課題
- 利用中のツール
- 予算
- 時期
- 決裁関係
- ISの所感
ただし、入力項目を増やしすぎると、形式的な入力や空欄が増えます。FSが商談前に読み、提案または追加確認に使う項目だけを必須にします。
（出典：オブジェクトパイプラインを設定・管理する）
この仕組みは入力漏れを責めるためではなく、誰が担当しても同じ情報を集められるようにするためのものです。質問項目が画面に現れれば、引き継ぎ可能な状態が明確になり、新人でも進め方を学びやすくなります。
SLAは相互の行動を定義する
SLAは、ISだけに品質を求めるルールではありません。ISはどの状態で渡すか、FSは受け取った後に何を返すかを対で定義します。
| 場面 | ISの行動／FSの行動 | 完了の判定 |
|---|---|---|
| トスアップ | IS：基準項目を入力し、判断理由を残す／FS：内容を読み、対応可否を決める | 次の行動と担当者が入っている |
| 初回商談後 | IS：必要に応じて補足する／FS：結果と次のステージを記録する | 取引レコードで進捗を追える |
| 見送り | IS：育成対象を受け取る／FS：失注理由と再接触条件を残す | 戻し先または終了理由が決まる |
| 振り返り | IS：トスアップ後の結果を見る／FS：基準が不足した案件を返す | 基準の修正案を合意できる |
SLAが形骸化したら、ルールを増やすより、未入力のまま止まった案件を見ます。入力されなかった項目が意思決定に使われていなければ削り、使われていたのに欠けたなら必須化するという順序で整えます。
HubSpotのパイプラインに連携設計を実装する
HubSpotでの実装は、取引ステージを並べるところから始まります。
ただし、ステージ名だけでは担当者ごとの解釈が残るため、次の項目を合わせて設計します。
- 確度
- 定義
- 必須プロパティ
ここではFSとISの境界をパイプライン上で読める状態にします。
- 既定のパイプライン ── HubSpot公式の既定の取引パイプラインには7つのステージがあり、たとえば「Decision maker bought-in」の確度は80%に設定されています。これは既定値の例です。
- 自社の定義 ── ISからFSへ渡す条件は自社の商談プロセスに合わせて定義し、既定の確度を成果予測としてそのまま採用しないでください。（出典：Set up and manage object pipelines）
パイプラインはステージ、確度、定義、必須項目で設計する
| 設計要素 | 決める内容 | FSとIS連携での役割 |
|---|---|---|
| 取引ステージ | 顧客の状態が変わる地点 | ISからFSへ渡る場所を示す |
| 確度 | ステージごとの見込み | 商談の重みを同じ基準で見る |
| ステージ定義 | その状態に入る条件 | 担当者ごとの解釈を減らす |
| 必須プロパティ | 移行時に必要な情報 | 引き継ぎの抜け漏れを防ぐ |
ISフェーズはリード受付、初回接触、ニーズ確認、アポ設定のように置き、FSフェーズは初回商談、提案、見積提示、受注内示、契約、請求へつなげます。名称は、自社の顧客が実際に進む節目に合わせます。
FS・ISの境界をHubSpotの取引パイプラインに作る手順
- 設定（歯車アイコン）＞ データ管理 ＞ オブジェクト ＞ 取引 ＞「パイプライン」タブを開き、パイプライン名をクリックします。
- 「＋ステージを追加」で、IS側のステージ（例：リード受付／初回接触／ニーズ確認／アポ設定）と、FS側のステージ（例：初回商談／提案／見積提示／受注内示）を、実際の受け渡しの順に作ります。
- 各ステージの「取引の確度」を選びます。既定値は自社の実績ではないため、まず仮置きにして、受注データがたまってから見直します。受注（Won）と失注（Lost）は必ず含めます。
- トスアップのステージ（例：アポ設定）の「条件付きロジックのルール」で「ルールを追加」を押し、依存プロパティを追加して「必須」をオンにします。
- テスト用の取引を1件作り、ISの担当者として、必須項目が出る位置とFSが読める位置が一致しているかを確認します。
| プロパティ（例） | フィールドタイプ | トスアップ時の扱い |
|---|---|---|
| 予算ステータス | ドロップダウン選択 | 必須（確保済み／検討中／未定） |
| 決裁関係 | ドロップダウン選択 | 必須（決裁者と面談済み／紹介待ち／未接触） |
| 課題カテゴリ | 複数チェックボックス | 必須（FSが提案テーマを選べる項目） |
| 導入検討時期 | 日付 | 必須（次の行動日の根拠にする） |
| ISの引き継ぎメモ | 複数行テキスト | 任意（所感ではなく、顧客の発言を書く） |
上の表は設計例です。先にプロパティを作り、ステージの条件付きロジックから依存プロパティとして選びます。スコアや計算プロパティなどの読み取り専用のプロパティは選べません。出典：Set up and manage object pipelines（HubSpotナレッジベース）。後から変えにくい設定はHubSpotで後から変えにくい設定で先に確認できます。
同じパイプラインか分けるかを判断する
（出典：オブジェクトパイプラインを設定・管理する）
| 判断条件 | 同じパイプラインが合う状態 | 分ける方が合う状態 |
|---|---|---|
| ステージ | ISからFSまで共通の流れで表せる | ISとFSで工程そのものが異なる |
| KPI | 同じ取引を連続して追いたい | 部門ごとの入口と完了を分けて追いたい |
| 引き継ぎ | 担当者変更で表現できる | 別の取引作成や明確な変換が必要 |
| 運用負荷 | 一覧性を優先する | 各部門の操作を単純にしたい |
企業様の規模や商材によって最適な形は異なります。最初は同じパイプラインで境界を可視化し、ステージの意味やレポートが混ざると分かった段階で分ける方が、不要な複雑化を避けやすくなります。
ボードビューで滞留と受け渡しを読む
以下の画面は、HubSpotの取引をボードビューで表示し、初回訪問、意思決定者の確認、見込み、見積提示、受注内示の各ステージと、見込みステージに取引カードが表示された状態を示しています。
ボードビューでは、どのステージに取引があり、どこが空いているかを同じ画面で見られます。
FSとISの連携では、トスアップ前の取引、FSが受領した取引、提案へ進んだ取引をステージで分け、担当者と次の行動を取引カードから確認できる状態を目指します。
ただし、カードが移動していても、定義と必須情報がそろっているとは限りません。
営業会議では件数だけでなく、移行条件を満たしているか、次の行動が入っているかまで取引レコードを開いて見ます。
自動化と手動運用の境界を決める
HubSpotの自動化は、担当者変更や通知など、条件が明確な処理に向いています。一方で、顧客へどう提案するか、複雑な案件を誰と進めるかは人が判断します。
機械的にできる処理と営業判断を分けると、ワークフローを増やしすぎずに運用できます。
担当者の割り当てを仕組みにする
取引ステージがアポ設定に変わったら、次の処理を行います。
- FS担当者を割り当てる
- 担当者へ通知する
- IS担当者の情報を追跡用に残す
これにより、現在の担当とトスアップした担当を混同せず、後からIS担当者別の商談結果を見られます。
割り当て方法は、次の項目で決めます。
- 商材
- 地域
- 既存の関係
- 担当者の稼働状況
条件が明確ならワークフローへ移し、判断が揺れる案件は責任者が担当を決める経路を残します。
担当割り当てと通知のワークフロー設計例
メニューの オートメーション ＞ ワークフロー から「ワークフローを作成」を押し、次のような設計で始めます。ワークフローはMarketing Hub・Sales Hub・Service Hub・Data Hub・Revenue HubなどのProfessionalまたはEnterpriseで利用できます。
| 項目 | 設計例 | 補足 |
|---|---|---|
| 登録条件 | 取引ステージが「アポ設定」になった | 再登録は、ステージを戻した案件で重複通知が出ないよう「設定」タブで決める |
| 担当割り当て | 「レコードを所有者へローテーション」でFSチーム内に均等に割り当てる | Sales HubまたはService HubのProfessional以上。条件が揺れる案件は責任者が決める |
| タスク作成 | 「タスクを作成」で、FS担当者に「トスアップ内容を確認し次の行動を入力」を期限付きで作る | 期限は受領のSLAに合わせる |
| 社内通知 | 「社内メール通知の送信」で、取引リンク・引き継ぎ理由・次の行動期限を送る | チーム宛てはプライマリメンバーのみが受信する設定がある |
出典：Create workflows・Choose your workflow actions（HubSpotナレッジベース）。登録条件・再登録・命名はHubSpotワークフロー設計書の書き方にまとめています。
通知は行動とセットにする
通知だけを増やすと、受け取った側が何をすべきか分からず、見過ごされやすくなります。通知には次の項目を含めます。
- 取引へのリンク
- 引き継ぎ理由
- 次の行動期限
FSが受領後に担当者と次の行動を更新したら完了とします。
ISへのフィードバックも同じ取引に戻します。商談へ進まなかった場合は、どの基準が不足したかを選び、ISが次のヒアリングで使える形にします。
パイプラインルールの例外まで見る
自動化が向かないのは、案件ごとに判断材料が大きく異なる場面です。条件を複雑に重ねるより、例外ステータスを用意して責任者が判断し、その結果を次のルール改善に使う方が運用しやすいケースがあります。
パイプラインルールでステージのスキップを制限する
IS・FSの連携では、必須項目を飛ばして先のステージへ進める運用が起きがちです。パイプラインルールを使うと、ステージのスキップや後戻り、レコードを作成できるステージを制限できます。
- 設定（歯車アイコン）＞ データ管理 ＞ オブジェクト ＞ 取引 ＞「パイプライン」タブで対象のパイプラインをクリックします。
- 画面下部の「パイプラインルール」タブを開きます。
- 「作成できるステージの限定」「ステージのスキップの制限」「後戻りの制限」などのスイッチをオンにし、保存します。
設定にはスーパー管理者権限が必要で、基本的なルールはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRMのProfessionalまたはEnterpriseが対象です。ルールを有効にすると、一括編集でのステージ変更はできなくなります。「受注」「失注」への移動はスキップが許可され、ワークフローやAPIで作成・編集したレコードはルールの対象外になる点にも注意してください。出典：Set up pipeline rules（HubSpotナレッジベース）。
失注後の掘り起こしまで一気通貫で設計する
FSとISの連携は、受注した時だけでなく、見送りになった時に品質が表れます。失注理由と再接触条件を残し、FSからISまたはマーケティングへ戻せる状態を作ります。
これにより、失注案件の放置と、理由を無視した再連絡を減らせます。
失注理由から次の行動を分ける
失注理由は、価格、競合、時期、ニーズ不一致、社内決裁などから選び、必要な補足を残します。自由記述だけでは集計しにくいため、カテゴリを選択式にし、顧客固有の事情をメモで補います。
| 失注理由 | 次の扱い | 再開のきっかけ |
|---|---|---|
| 時期 | 掘り起こし対象へ戻す | 顧客が示した検討時期 |
| 予算 | 状況確認の対象にする | 予算検討が再開する時期 |
| 競合 | 比較理由を残して終了または育成 | 再検討の連絡や契約見直し |
| ニーズ不一致 | 原則として終了する | 提供範囲が変わり適合する場合 |
| 社内決裁 | 決裁条件を整理して育成する | 必要な関係者との接点ができた時 |
ライフサイクルステージへ戻す
FSが失注を記録したら、取引の失注理由に応じて、関連するコンタクトや会社を掘り起こし対象へ戻します。
逆行を制限している運用では、元の値を直接戻すのではなく、次のように扱います。
- 掘り起こし用の状態を定義する
- 再商談化した時に改めて前進させる
再接触の時期は一律にせず、顧客が示した時期や失注理由から決めます。
- 日付が決まっている場合 ── タスクや通知に落とします。
- 条件が決まっていない場合 ── 定期レビューの一覧に置きます。
失注データを連携基準の改善に戻す
失注理由が蓄積されると、ISの見極め、FSの提案、マーケティングの訴求のどこを直すか話しやすくなります。
例えば、次のように見直します。
- ニーズ不一致が多い場合 ── トスアップ前の質問を見直します。
- 社内決裁で止まる場合 ── 決裁関係の把握を早めます。
ここで大切なのは、ISを評価するためだけに失注理由を使わないことです。FSの提案内容や商材側の課題も含め、全体フローの改善材料として扱います。
分業と協業のバランスを判断する
分業は営業活動の目的ではなく、顧客への対応を滑らかにする手段です。
リード量、案件の複雑さ、既存関係の有無によって、ISとFSを分ける範囲は変わります。全案件を同じルールにせず、標準対応と共同対応を分けます。
標準化しやすい案件は分業する
確認項目と提案の流れがそろっている案件は、ISが見極め、FSが提案する分業に向いています。HubSpotのプロパティとステージ定義を使えば、担当者が変わっても同じ順序で対応できます。
分業の効果を見る時は、ISのアポ件数だけでなく、FSが受領した後の進行、失注理由、受注へのつながりを合わせて見ます。インサイドセールスのKPI設計と連動させると、量と質を同じ流れで整理できます。
複雑な案件は共同対応に切り替える
協業シーンには、大型案件、既存顧客のクロスセル、展示会で温度感が高い案件があります。こうした案件では、ISが情報を集めた後に完全に離れるのではなく、FSと共同でヒアリングし、接点と背景を引き継ぎます。
| 協業シーン | ISの役割／FSの役割 | 共通で残す情報 |
|---|---|---|
| 大型案件 | IS：初回接点と背景整理／FS：提案方針と商談推進 | 課題、関係者、次の行動 |
| 既存顧客のクロスセル | IS：追加ニーズの把握／FS：既存関係を踏まえた提案 | 現契約、要望、検討理由 |
| 展示会フォロー | IS：初期連絡と温度感の確認／FS：優先案件への早期対応 | 接点、関心、対応状況 |
共同対応へ切り替える条件も、取引プロパティで明示します。担当者同士の口頭判断だけにせず、案件の複雑さや既存関係など、切り替え理由を記録します。
分業が向かない状態もある
案件数が限られ、顧客ごとに深い理解が必要な場合は、同じ担当者が初回接触から提案まで進める方が自然なケースがあります。
分業を前提に組織を作ると、次のことが起こる場合があります。
- 受け渡しのための作業が増える
- 顧客との関係が細切れになる
ただし、一気通貫で担当する場合でも、活動履歴と次の行動はHubSpotに残します。担当者が不在でも他のメンバーが状況を理解でき、引き継げる状態にしておくことが、仕組みで解決する設計です。
小さく始めて連携ルールを改善する手順
連携設計は、最初から全項目と自動化を作り込むより、止まっている受け渡しを選んで始める方が進めやすいです。
現行プロセスを可視化し、最小限の項目とステージを設定し、実際の案件で差分を見ます。運用結果から項目と自動化を広げます。
現在の受け渡しを可視化する
最初に、マーケティングからIS、ISからFS、FSから失注後の担当へ、どの情報を何で渡しているかを書き出します。スプレッドシート、チャット、個人メモに同じ情報がある場合は、更新者と正本を決めます。
| 見る場所 | 確認する内容 | 判断 |
|---|---|---|
| トスアップ前 | FSが提案判断に使う情報があるか | 足りない項目だけ候補にする |
| 受領直後 | 担当者と次の行動が決まるか | 決まらない理由をSLAに反映する |
| 商談後 | 結果がISへ戻っているか | フィードバック項目を決める |
| 失注後 | 戻し先と再接触条件があるか | 育成または終了を分ける |
最小限の設定で動かす
取引ステージの境界、トスアップ時の必須プロパティ、FS担当者、次の行動、失注理由から設定します。自動化は、担当者割り当てや通知など、条件と結果が明確な処理から始めます。
完了の目安は、ISがトスアップするとFSが同じ取引レコードを読み、次の行動を選べることです。ここで不足した情報だけを追加し、使われなかった項目は必須から外します。
実案件の振り返りで拡張する
運用後は、止まった取引をステージ別に見ます。
- トスアップ前で止まる場合 ── 質問項目を見直します。
- 受領後で止まる場合 ── SLAを見直します。
- 提案後で止まる場合 ── 商談結果と失注理由を見直します。
基準を変えたら、変更理由と適用開始のタイミングをチームで共有します。設定を増やす前に、同じ定義で入力できていることを確かめ、その後にレポートや自動化を広げる流れがおすすめです。
このテーマに関連する記事はセールスマネジメントカテゴリで網羅的にまとめています。
FSとISの連携設計を運用に乗せる進め方｜StartLinkの支援工程
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。FSとISの連携は、設定する前に受け渡しの現状を整理する順で進めます（HubSpot導入・構築支援の工程に沿っています）。
- 現状の整理・要件定義 — マーケティングからIS、ISからFS、失注後の担当まで、何の情報をどこで渡しているかを書き出し、止まっている地点を特定します。
- 設計・構築 — 上の表の形で、取引ステージ・必須プロパティ・割り当てワークフローを設計し、スモールスタートで1つの受け渡し（トスアップ）から構築します。
- データ移行・テスト・検証 — 既存のスプレッドシートの案件を取り込み、テスト用の取引でステージ遷移と通知を確認します。移行時の突合はHubSpotデータ移行の検証手順が参考になります。
- 定着・運用改善 — 週次の営業会議でトスアップ後の進行と失注理由を確認し、SLAと必須項目を見直します。会議の型はHubSpot定着の運用設計にあります。
AIは、商談メモの要約や引き継ぎ内容の下書きなど、人が最終判断する前の準備に組み込みます。営業からバックオフィスまでの分け方はHubSpotのAI業務設計で整理しています。企業様によって最適な形は異なりますので、体制に合わせて一緒に設計します。
よくある質問
FSとISの連携設計で判断が分かれやすい点を整理します。設定の選択肢だけでなく、どの状態ならどちらを選ぶかまで回答します。
Q1. ISとFSのパイプラインは分けるべきですか
ステージが連続し、同じ取引を受注まで追うなら、同じパイプラインから始めると全体を見やすくなります。工程や完了条件が明確に異なり、同じステージ名ではKPIが混ざるなら分けます。担当チームが異なるだけなら、先に担当者と権限で分けられないかを検討します。
Q2. ISのKPIはアポ件数だけでよいですか
アポ件数だけでは、FSへ渡した後の質が見えません。トスアップ後に提案へ進んだか、失注理由は何か、受注にどうつながったかを合わせて見ます。ISが制御できないFSの提案結果だけで評価せず、引き継ぎ基準の充足と商談結果を対で振り返ります。
Q3. 失注案件はいつ再アプローチすべきですか
一律の間隔ではなく、失注理由と顧客が示した時期で決めます。時期が理由なら顧客の検討再開時期、予算なら予算検討の節目、ニーズ不一致なら提供範囲が変わった時をきっかけにします。再開条件がない案件は終了扱いにし、形式的な連絡を続けない運用にします。
Q4. 必須プロパティを増やせば引き継ぎ品質は上がりますか
項目数を増やすだけでは、入力負荷が増えて形式的な値が入りやすくなります。FSが商談前に利用した項目を残し、使わなかった項目は削ります。未入力で止まった案件と、情報不足で商談が止まった案件を見比べると、必須にする項目を判断しやすくなります。
Q5. 自動化できない例外案件はどう扱いますか
例外を通常フローへ無理に当てはめず、責任者が判断する状態を用意します。判断理由と決定後の担当者を取引レコードに残し、同じ例外が繰り返されたら標準ルールへ取り込みます。単発の例外は人が扱い、反復する処理は仕組みに移す切り分けが有効です。
Q6. 必須入力を飛ばしてステージを進められる運用は止められますか
パイプラインルールで、ステージのスキップや後戻り、レコードを作成できるステージを制限できます。設定は、設定＞データ管理＞オブジェクト＞取引＞パイプラインタブから対象パイプラインを開き、画面下部のパイプラインルールで行います。設定にはスーパー管理者権限が必要で、基本的なルールはProfessionalまたはEnterpriseが対象です。ワークフローやAPIで作成・編集したレコードはルールの対象外になる点に注意してください。
まとめ
FSとISの連携は、アポの受け渡しではなく、判断と情報を次工程へつなぐ設計です。HubSpotでは、取引ステージ、確度、ステージ定義、必須プロパティを軸にし、担当者割り当て、SLA、失注後の掘り起こしまで一体で組み立てます。
押さえる要点
- トスアップ基準はBANTなどの共通項目に落とし、FSが次の行動を選べる状態を完了条件にします。
- 引き継ぎ項目は次工程が使うものに絞り、入力漏れを個人への注意ではなく仕組みで防ぎます。
- パイプラインはステージだけでなく、確度、定義、必須プロパティを合わせて設計します。
- 失注理由から育成、再接触、終了を分け、FSの結果をISとマーケティングへ戻します。
- 標準案件は分業し、複雑な案件は共同対応へ切り替える条件をHubSpotに残します。
まず取り組むこと
- 現在の受け渡しで、情報が止まる地点を洗い出します。
- FSが提案判断に使う項目だけを選び、トスアップ条件と取引ステージを設定します。
- 実際の取引で運用し、止まった地点に応じてSLA、必須項目、自動化を見直します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
FSとISの役割設計をさらに深めるための記事です。体制、KPI、役割の違い、部門間SLAを順に確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
