%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}
この記事の結論
インサイドセールスの立ち上げは、組織・プロセス・KPIを一体で設計できるかが成否を分けます。
インサイドセールスの立ち上げは、組織・プロセス・KPIを一体で設計できるかが成否を分けます。
「The Modelを参考にインサイドセールス部門を立ち上げたいが、SDRとBDRの違いがわからない」「インサイドセールスを置いたものの、アポイント数だけを追いかけて質の低い商談が増えている」「マーケティングから渡されたリードをどう処理すべきか、基準が曖昧なまま運用が回っている」——こうした課題は、組織の「設計」が不十分なまま立ち上げを進めた結果として生じる、構造的な問題です。
インサイドセールスとは、マーケティングが創出したリードを電話・メール・オンライン商談などの非対面チャネルで精査し、フィールドセールスが受注できる商談へと変換する営業機能です。単に「電話をかける部門」ではなく、営業プロセスの歩留まりを改善する「変換装置」として設計することがポイントになってきます。
本記事では、インサイドセールス組織の立ち上げに必要な設計要素を体系的に解説します。SDR/BDR体制の構築方法、ライフサイクルステージに連動したリード管理設計、KPIの設計と運用、CRM/SFAを活用したプロセスの実装パターン、フィールドセールスとの連携設計まで、組織設計とシステム設計の両面からカバーします。
営業責任者・経営者の方に向けた、インサイドセールス立ち上げの実践ガイドとしてお読みください。関連するトピックを横断的にまとめたインサイドセールス実践ガイドもあわせてご覧ください。
この記事でわかること
これからインサイドセールス組織を立ち上げる方、あるいは立ち上げたものの成果が出ていない方に向けて、設計の全体像と実務上の落とし穴を整理しています。
- インサイドセールスの役割とSDR/BDRの使い分け — テレアポ部隊との違いと、自社に合った型の選び方がわかります。
- ライフサイクルステージの設計方法 — リード→MQL→SQL→商談→顧客の各ステージと移行条件の決め方がわかります。
- KPIの3層構造と目標の逆算設計 — 売上目標から必要なMQL数・SQL数を逆算する手順がわかります。
- CRM/SFA上でのプロセス実装 — ステージ管理・パイプライン・シーケンス・引き渡しを仕組み化する方法がわかります。
- 部門間連携と立ち上げの進め方 — フィールドセールスとのSLA設計、4フェーズの立ち上げ手順、よくある失敗の回避策がわかります。
インサイドセールス組織の設計を検討している営業責任者・経営者の方に向けて書いています。最後まで読むと、自社の状況に合わせた立ち上げ設計を自分で描けるようになります。
インサイドセールスとは｜営業プロセスにおける役割と位置づけ
まず、インサイドセールスが営業プロセスの中でどの役割を担うのかを整理します。役割の定義が曖昧なままだと、「テレアポの延長」として運用されてしまい、本来の価値を発揮できません。
インサイドセールスの定義
インサイドセールスとは、見込み顧客（リード）に対して電話・メール・オンライン商談などの非対面チャネルを通じてアプローチし、商談機会を創出する営業機能です。フィールドセールス（外勤営業）が対面での商談・受注獲得を担うのに対し、インサイドセールスはその前段階の「リードの精査」と「商談化」を専門的に担います。
重要なのは、インサイドセールスが単なる「テレアポ部隊」ではないという点です。テレアポは不特定多数に画一的なアプローチを行う活動として捉えられることが多いのに対し、インサイドセールスはリードの状態や属性に応じたコミュニケーションを設計し、顧客の購買プロセスを前進させることを目的とする機能として整理すると分かりやすいです。
営業プロセス全体における位置づけ
BtoB営業における分業モデル（The Model）では、営業プロセスは4つの機能に分かれます。インサイドセールスは、マーケティングとフィールドセールスの間に位置し、両部門をつなぐ「ブリッジ」の役割を果たします。
| 機能 | 主な役割 | インサイドセールスとの関係 |
|---|---|---|
| マーケティング | リードの獲得・育成（リードジェネレーション・ナーチャリング） | ISにリードを引き渡す（MQL化） |
| インサイドセールス | リードの精査・商談機会の創出 | 中核的な役割 |
| フィールドセールス | 商談の推進・受注獲得 | ISから商談を受け取る（SQL化） |
| カスタマーサクセス | 契約継続・アップセル・解約防止 | 既存顧客の追加案件をISに戻すケースもある |
インサイドセールスが機能しない組織では、マーケティングが創出したリードが「放置」されるか、フィールドセールスが未精査のリードに時間を奪われるか、いずれかの非効率が生じます。つまりインサイドセールスは、リード獲得から受注・顧客化までの一気通貫の流れの中で、歩留まりを左右する変換装置です。その設計品質が組織全体の営業生産性を左右します。
テレアポ部隊との本質的な違い
インサイドセールスと従来のテレアポは、表面的には「電話をかける」という行為が共通していますが、その設計思想は根本的に異なります。
| 比較項目 | テレアポ | インサイドセールス |
|---|---|---|
| アプローチ対象 | 不特定多数のリスト | マーケティングが獲得・育成したリード |
| コミュニケーション | 画一的なスクリプト | リードの状態に応じたパーソナライズ |
| 成果指標 | アポイント数（量重視） | 商談化率・受注貢献額（量と質の両方） |
| チャネル | 電話のみ | 電話・メール・SNS・オンライン商談など複合 |
| データ活用 | 架電リストの消化 | CRMデータに基づくアプローチ優先度の判断 |
| 顧客体験 | 押し売り感が強い | 課題解決型のコンサルティングアプローチ |
この違いを理解せずにインサイドセールスを「テレアポの延長」として運用すると、リードの疲弊やブランド毀損につながります。インサイドセールスの立ち上げにおいて、まずこの役割の定義と位置づけを組織全体で共有することが出発点です。
SDRとBDRの違い｜インサイドセールスの2つの型
インサイドセールスは、アプローチの起点によってSDRとBDRの2つの型に分かれます。どちらを先に立ち上げるかは企業様によって最適な形が異なりますので、違いを正しく理解したうえで自社の状況に合わせて選ぶことが重要です。
以下の画面は、HubSpotのシーケンス機能でフォローアップメールを自動化する画面のイメージです。SDR・BDRどちらの型でも、こうした仕組みを使ってリードへの接触を標準化していきます。
インサイドセールスは、そのアプローチの起点によって大きく2つの型に分かれます。SDR（Sales Development Representative）とBDR（Business Development Representative）です。両者は混同されがちですが、対象リード・アプローチ方法・必要なスキルが異なるため、組織設計において明確に区分することが重要です。
SDR（Sales Development Representative）：インバウンド対応型
SDRは、マーケティング活動によって獲得されたインバウンドリードに対応するインサイドセールスです。Webサイトからの問い合わせ、ホワイトペーパーのダウンロード、ウェビナーへの参加、展示会での名刺交換などを通じて獲得したリードに対して、電話やメールでフォローアップし、商談化を目指します。
SDRの主な業務は以下のとおりです。
- リードの初期対応：問い合わせや資料請求に対して迅速にレスポンスします。
- リードの精査（クオリフィケーション）：BANT条件などに基づいてリードを評価します。
- 商談機会の創出：課題をヒアリングし、商談を設定します。
- リードの育成（ナーチャリング）：すぐに商談化しないリードへ継続的にフォローします。詳しくはリードナーチャリングの設計思想を参照ください。
SDRに求められるスキルは、顧客の課題を的確にヒアリングし、自社サービスとの接点を見出す「課題発見力」と、マーケティングが設定したリードスコアやライフサイクルステージに基づいて優先順位を判断する「データリテラシー」です。
BDR（Business Development Representative）：アウトバウンド開拓型
BDRは、ターゲット企業に対して自ら能動的にアプローチするアウトバウンド型のインサイドセールスです。マーケティングからのリードを待つのではなく、自社が定義したICP（Ideal Customer Profile：理想顧客像）に合致する企業を特定し、戦略的にアプローチを仕掛けます。
BDRの主な業務は以下のとおりです。
- ターゲット企業のリサーチ：業界動向、企業の課題仮説、キーパーソンを特定します。
- アウトバウンドアプローチ：コールドコール、パーソナライズドメール、SNSメッセージで接触します。
- 関係構築：ターゲット企業のキーパーソンとの信頼関係を構築します。
- 商談機会の創出：課題仮説に基づく提案を行い、商談を設定します。
BDRはSDRよりも高度なスキルが求められます。相手が自社のことを知らない状態からアプローチするため、業界知識、仮説構築力、パーソナライズされたメッセージング能力が不可欠です。
SDRとBDRの比較と使い分け
| 比較項目 | SDR | BDR |
|---|---|---|
| リードの起点 | インバウンド（マーケティング起点） | アウトバウンド（自ら開拓） |
| アプローチ方法 | 問い合わせへのフォローアップ | コールドコール・パーソナライズドメール |
| 主なKPI | 商談化率、レスポンスタイム | 新規アカウント開拓数、ミーティング設定数 |
| 必要スキル | ヒアリング力、データリテラシー | リサーチ力、仮説構築力、メッセージング力 |
| 適するフェーズ | マーケティング施策が成熟しリードが潤沢な段階 | ターゲットが明確でエンタープライズ攻略が必要な段階 |
| 難易度 | 比較的立ち上げやすい | 高い専門性が必要で立ち上げ難度が高い |
多くの企業では、まずSDRから立ち上げ、マーケティングとの連携を確立したうえでBDRを追加するという段階的なアプローチが有効です。すべてを一気に進めるのは難しいため、自社で効果が出そうな型から優先順位をつけてトライしていただければと思います。SDRとBDRを同時に立ち上げると、リード管理の複雑性が増し、KPI設計や評価制度の整備が追いつかないリスクがあります。
ただし、ターゲット企業が明確に絞り込まれているエンタープライズ向けビジネスや、インバウンドリードが少ない立ち上げ初期フェーズでは、BDRから着手するケースもあります。自社のビジネスモデルとリード獲得状況に応じた判断が必要です。
ライフサイクルステージの設計｜MQLからSQLへの変換プロセス
インサイドセールス組織を機能させるためには、リードがどの状態にあるかを明確に定義し、管理する仕組みが不可欠です。この仕組みがライフサイクルステージであり、インサイドセールスの業務設計の土台になります。自社のカスタマージャーニーをベースに、自社にフィットした形でステージを定義することが要点になります。
ライフサイクルステージの基本設計
ライフサイクルステージとは、見込み顧客が最初の接点から顧客になるまでの「旅程」を段階的に定義したものです。BtoB営業において標準的なライフサイクルステージは、以下の5段階で構成されます。
| ステージ | 定義 | 主な責任部門 | 次ステージへの移行条件（例） |
|---|---|---|---|
| リード | 接点を持った段階。フォーム入力、名刺交換など | マーケティング | スコアリング基準を満たす/特定行動をとる |
| MQL（Marketing Qualified Lead） | マーケティングが「営業対応すべき」と判断したリード | マーケティング→インサイドセールス | ISがBANT条件を確認し、商談可能と判断 |
| SQL（Sales Qualified Lead） | 営業が「商談として進めるべき」と判断したリード | インサイドセールス→フィールドセールス | 初回商談が実施され、パイプラインに登録 |
| 商談（Opportunity） | 具体的な提案・交渉が進行中の状態 | フィールドセールス | 契約締結・受注 |
| 顧客（Customer） | 契約が成立し、取引関係にある状態 | カスタマーサクセス | - |
ここで最も重要なのは、各ステージの「移行条件」を定量的かつ明確に定義することです。「なんとなくホットそうだから」ではなく、具体的な基準に基づいてステージを進めることが、インサイドセールスの品質を担保する鍵です。定義が属人化していると、担当者によって判定がばらつき、KPIの数値自体が信用できなくなります。
MQL（Marketing Qualified Lead）の定義と設計
MQLとは、マーケティング活動を通じて獲得したリードのうち、「営業対応の価値がある」とマーケティングが判断したホットリードのことです。MQLの定義が曖昧な組織では、質の低いリードがインサイドセールスに大量に流れ込み、ISチームの生産性を著しく低下させます。MQL定義とスコアリングモデルの具体的な設計手法については、リードスコアリングの設計方法で詳しく解説しています。
MQLの定義に用いる代表的な基準は以下のとおりです。
- デモグラフィック基準（フィット）：企業規模、業界、役職、所在地などがICP（理想顧客像）に合致するかを確認します。
- ビヘイビアル基準（エンゲージメント）：Webサイトの訪問頻度、資料ダウンロード、メール開封率、ウェビナー参加などの行動を評価します。
- リードスコア：上記の基準を点数化し、閾値を超えたリードをMQLとして定義します。
CRM上ではリードスコアリング機能を活用し、一定スコアに達したリードを自動的にMQLに昇格させ、インサイドセールスへの通知とタスク割り当てを行う設計が有効です。人の記憶や申し送りに頼らず、仕組みで判定する形にしておくと、担当者が変わっても同じ基準で運用できます。
SQL（Sales Qualified Lead）の定義と設計
SQLとは、インサイドセールスがMQLに対してコンタクトを取り、「商談として進めるに値する」と営業側が判断したリードのことです。MQLがマーケティング視点での評価なのに対し、SQLは営業視点での評価です。
SQLへの昇格基準として広く活用されているのがBANT条件です。
- Budget（予算）：導入に必要な予算の確保状況を確認します。
- Authority（決裁権）：意思決定者と決裁フローを把握します。
- Need（ニーズ）：解決すべき課題の明確さと緊急度を確認します。
- Timeline（導入時期）：具体的な導入スケジュールの有無を確認します。
ただし、BANT条件のすべてが揃うリードは限られます。実務では、「Need（ニーズ）」と「Timeline（時期）」の2つが確認できれば商談化の判断基準とするなど、自社の商材特性に合わせた基準の調整が必要です。
MQL→SQL変換の設計ポイント
MQLからSQLへの変換は、インサイドセールスの最も重要な業務です。この変換プロセスの設計において押さえるべきポイントは以下の4つです。
- レスポンスタイムの基準を設けます：MQLが発生してから初回コンタクトまでの目標時間を定義します。問い合わせ直後の早いタイミングでコンタクトするほど、商談化につながりやすいとされています。
- フォローアップの回数と間隔を標準化します：初回不通の場合の再コンタクト回数、間隔、チャネル（電話→メール→SNSなど）を定義します。
- 非SQL化リードの取り扱いを定義します：ISが「商談化に至らない」と判断したリードをマーケティングに戻す（リサイクル）仕組みを設計します。
- SLA（Service Level Agreement）をマーケティングと合意します：MQLの品質基準とISの対応基準を数値で合意し、部門間の期待値を揃えます。
このMQL→SQL変換の品質を測定する指標が「MQL→SQL変換率」です。変換率が低すぎる場合はMQLの定義が甘い可能性があり、高すぎる場合はMQLの基準が厳しすぎてリード数が不足している可能性があります。適正値は業界や商材によって異なりますので、自社の実績データで検証しながら調整していきましょう。
インサイドセールス組織のKPI設計｜目標管理の実務
インサイドセールスの成果を正しく評価し、組織として継続的に改善していくためには、適切なKPI設計が不可欠です。KPIの設計を誤ると、「量だけを追いかけて質が低下する」「活動量が多いのに成果が出ない」という非効率な状態に陥ります。ここではKPIの構造から逆算設計、CRM上での管理方法までを解説します。
KPIの3層構造
インサイドセールスのKPIは、以下の3層で設計することが有効です。
| KPI層 | 目的 | 代表的な指標 | 計測頻度 |
|---|---|---|---|
| 成果指標（Outcome KPI） | 最終的な貢献度を測定 | SQL創出数、商談化率、受注貢献額 | 月次 |
| プロセス指標（Process KPI） | 変換効率を測定 | MQL→SQL変換率、平均レスポンスタイム、フォローアップ完了率 | 週次 |
| 活動指標（Activity KPI） | 日々の行動量を測定 | 架電数、メール送信数、有効会話数、ミーティング設定数 | 日次 |
多くの企業が陥りがちな失敗は、活動指標だけをKPIに設定してしまうことです。「架電数100件/日」だけを追いかけると、質の低い架電が増え、リードの疲弊やフィールドセールスへの低品質商談の押し付けが発生します。「成果指標→プロセス指標→活動指標」の順で設計し、上位指標と下位指標の因果関係を意識することが重要です。
SDR/BDR別のKPI設計
SDRとBDRではアプローチの起点が異なるため、KPI設計も分けて行う必要があります。
| KPI項目 | SDR（インバウンド対応） | BDR（アウトバウンド開拓） |
|---|---|---|
| 成果指標 | SQL創出数：月15〜25件（目安） | 新規アカウント商談創出数：月5〜10件（目安） |
| プロセス指標 | MQL→SQL変換率：20〜30% | アプローチ→ミーティング設定率：5〜10% |
| 活動指標 | 架電数：40〜60件/日、メール：20〜30通/日 | パーソナライズドメール：15〜25通/日、架電：30〜50件/日 |
| レスポンス | MQL発生→初回コンタクト：5分以内（目標） | ターゲットリスト作成→初回アプローチ：24時間以内 |
なお、上記の数値はあくまで目安です。自社の商材特性・単価・商談サイクル・リード量に応じて調整が必要です。重要なのは、自社にとっての「適正値」を仮説として設定し、データに基づいて改善していくことです。
KPIの目標設定と逆算設計
インサイドセールスのKPIは、売上目標からの逆算で設計するのが基本です。この逆算プロセスを具体例で示します。
【逆算の例】月間売上目標：3,000万円の場合
- 平均受注単価を300万円とすると、必要受注数は10件/月です。
- 商談→受注率を25%とすると、必要商談数は40件/月です。
- SQL→商談化率を80%とすると、必要SQL数は50件/月です。
- MQL→SQL変換率を25%とすると、必要MQL数は200件/月です。
- ISメンバーが4名なら、1人あたりのSQL目標は12.5件/月になります。
この逆算により、マーケティングに求めるMQL数の目標値と、インサイドセールスに求めるSQL数の目標値が明確になります。売上目標→必要受注数→必要商談数→必要SQL数→必要MQL数という逆算の流れを、マーケティング・インサイドセールス・フィールドセールスの3部門で共有し、合意することが組織連携の土台です。数値はあくまで仮説なので、まずは受注目標や受注件数のような捉えやすい指標から設定し、運用データで補正していく進め方がおすすめです。
CRM上でのKPI管理とレポーティング
設計したKPIは、CRM/SFA上でリアルタイムに計測・可視化できる状態をつくることが運用の鍵です。スプレッドシートで手動集計していると、入力・集計の手間が増えるだけでなく、集計時点によって数値がずれて「どの数字が正しいのか」という議論に時間を取られてしまいます。CRMの目標管理機能やダッシュボード機能を活用し、以下の仕組みを構築します。
- 個人別目標ダッシュボード：各ISメンバーのSQL創出数・活動量・変換率を一覧で確認できます。
- チーム別進捗ダッシュボード：チーム全体の目標達成率をリアルタイムで可視化できます。
- パイプライン連携レポート：IS起点の商談がフィールドセールスのパイプラインでどのように進行しているかを追跡できます。
- マーケティング連携レポート：リードソース別のMQL→SQL変換率を分析し、マーケティング施策の効果を評価できます。
HubSpotのSales Hubでは、目標管理機能で個人・チーム単位の目標設定と進捗トラッキングが可能です。カスタムレポートを活用すれば、リードソース別の変換率やステージ別の滞留時間など、インサイドセールスの改善に直結する分析をリアルタイムで実行できます。しっかりデータが入力される仕組みさえ整えば、CRMは単なる記録ツールではなく、マネジメント判断の基盤として機能します。
CRM/SFAを活用したインサイドセールスプロセスの実装
インサイドセールスの組織設計を、実際のCRM/SFA上でどう実装するかが運用成功の分水嶺です。優れた設計も、システム上で再現できなければ絵に描いた餅になってしまいます。ここでは、CRM上でのインサイドセールスプロセス実装の具体的なパターンを解説します。
以下の画面は、HubSpotのパイプライン管理で取引をかんばん形式で確認する画面のイメージです。ISからFSへの引き渡しも、このパイプライン上で可視化していきます。
パターン1：ライフサイクルステージの実装
CRM上でライフサイクルステージを実装する際のポイントは以下のとおりです。
- ステージの定義をプロパティとして設定します：コンタクトのライフサイクルステージをカスタムプロパティまたは標準プロパティで管理します。
- ステージ移行を自動化します：リードスコアが閾値を超えた場合に自動でMQLに昇格させるワークフローを構築します。
- 手動ステージ変更のルールを定義します：ISがSQL判定する際の手動変更ルールとその記録方法を明確化します。
- 逆行（ダウングレード）のルールも設定します：MQL→リードへの差し戻し（リサイクル）も仕組みとして設計します。失注や商談化しなかったリードを一度ステージから外し、ナーチャリングに戻す導線を用意しておくと、時期が来たリードを掘り起こせます。
HubSpotでは、ライフサイクルステージがコンタクトオブジェクトの標準プロパティとして用意されています。ワークフロー機能を活用し、リードスコアやフォーム送信などの条件に基づいて自動昇格を設定することで、人的判断のばらつきを排除した一貫性のあるステージ管理が実現します。
パターン2：パイプラインと取引ステージの設計
インサイドセールスが商談化したリードをフィールドセールスに引き渡す際、パイプライン上の取引ステージが連携の基盤になります。パイプライン設計では、取引ステージの分け方・受注確度（角度）・各ステージの定義・必須入力プロパティの4要素を自社に最適な形で設計することが要点です。
インサイドセールス関連の取引ステージは、以下のように設計するのが基本です。
| 取引ステージ | 担当 | 概要 | 受注確度（目安） |
|---|---|---|---|
| アポイント獲得 | IS | 商談日程が確定した段階 | 10% |
| 初回商談完了 | FS | 初回商談を実施し、課題が確認された段階 | 20% |
| 提案 | FS | 具体的な提案書を提示した段階 | 40% |
| 見積提出 | FS | 見積書を提出し、交渉段階にある | 60% |
| クロージング | FS | 最終合意・契約手続き中 | 80% |
| 受注 | FS | 契約締結 | 受注確定 |
| 失注 | FS/IS | 商談不成立 | 0% |
HubSpotのSales Hubでは、パイプライン管理機能で上記の取引ステージを設定し、各ステージに必須入力プロパティを紐づけることで、ステージ移行時に必要な情報を漏れなく記録する仕組みを構築できます。営業プロセス上必要な情報と、レポートや経営管理上必要な情報の両方をこの設計に含めておくと、入力することがそのまま新人教育のガイドにもなります。
パターン3：シーケンス（自動フォローアップ）の設計
インサイドセールスの業務効率を飛躍的に高める仕組みが、メールシーケンス（自動フォローアップ）です。手動でのフォロー漏れを防ぎ、リードへの継続的な接点を確保します。
インサイドセールスで活用すべきシーケンスのパターンは以下のとおりです。
- MQL初回フォローシーケンス：MQL発生直後の初回コンタクトと不通時の再アプローチを、電話→メール→電話の組み合わせで5〜7ステップほど組みます。
- 資料請求後フォローシーケンス：資料ダウンロード後に、追加情報の提供から課題ヒアリングの打診までを段階的に行います。
- ウェビナー参加後フォローシーケンス：参加お礼から関連資料の案内、商談打診までを個別にフォローします。
- リサイクルリード再活性化シーケンス：過去に商談化しなかったリードへ、新情報の提供や状況確認を行います。
- BDR向けアウトバウンドシーケンス：パーソナライズドメール→コールドコール→SNS接触→再メールという段階的なアプローチを設計します。
シーケンスの設計においては、各ステップの間隔と、シーケンス全体の期間を適切に設定することが重要です。間隔が短すぎるとリードに「しつこい」印象を与え、長すぎると熱量が下がります。一般的には、初回コンタクトの翌日→3日後→1週間後→2週間後という間隔が基本パターンです。
パターン4：タスク管理とリード引き渡しの仕組み化
インサイドセールスの日常業務は、大量のリードに対する架電・メール・フォローアップの繰り返しです。この業務を効率的に回すためには、CRM上のタスク管理とキュー（優先順位付きのタスクリスト）の設計が重要です。
- 自動タスク生成：MQLが発生した際に自動でISメンバーにタスクを割り当てるワークフローを構築します。
- 優先度ベースのキュー設計：リードスコア、リードソース、企業規模などに基づいてタスクの優先度を自動設定します。
- ラウンドロビン配分：新規MQLを複数のISメンバーに均等に割り当てる仕組みを作ります。
- 未対応アラート：一定時間内に対応されていないタスクをマネージャーにエスカレーションする仕組みを用意します。
- 引き渡し情報の必須化：BANT情報・コミュニケーション履歴・キーパーソン情報などを、取引作成時の必須入力プロパティとして設定します。
HubSpotでは、ワークフローによるタスク自動生成と、コンタクトの担当者割り当て機能を組み合わせることで、これらの仕組みをノーコードで構築できます。
インサイドセールスからフィールドセールスへのリード引き渡しは、営業プロセスにおける最も重要な「接続点」です。引き渡し時に記録・共有すべき情報は、BANT情報、商談の経緯、顧客の期待値、キーパーソン情報、競合情報の5点です。「口頭での申し送り」に依存する運用は、情報の欠落と属人化を招きます。個人の力量に頼るのではなく、CRM上の必須項目として仕組みで担保することが、引き継げる・新人でも回る組織づくりの要になります。
フィールドセールスとの連携設計｜組織間の接続ルール
インサイドセールスの成果は、フィールドセールスとの連携品質によって大きく左右されます。IS単体で見れば優秀な数値が出ていても、フィールドセールスが「ISから渡される商談の質が低い」と感じていれば、組織として機能していません。ここでは部門間の接続ルールを設計します。
SLA（Service Level Agreement）の設計
インサイドセールスとフィールドセールスの間で、リード引き渡しに関するSLA（合意基準）を明文化することが連携の基盤です。
SLAに含めるべき項目は以下のとおりです。
| SLA項目 | IS側の基準 | FS側の基準 |
|---|---|---|
| 引き渡し条件 | BANT条件のうちNeed+Timelineが確認済み | 引き渡しから48時間以内に初回商談を実施 |
| 情報の品質 | 必須プロパティ（課題・ニーズ・キーパーソン）がすべて入力済み | 商談結果を24時間以内にCRMに記録 |
| フィードバック | ISはFSからのフィードバックを基にアプローチを改善 | FSは商談結果をISにフィードバック（受注/失注理由含む） |
| リジェクト対応 | FSがリジェクトしたリードを再精査し、リサイクルまたは破棄を判断 | リジェクト時は理由を記録し、ISに通知 |
SLAは「一度決めて終わり」ではなく、月次の振り返りを通じて定期的に見直します。特に重要なのは、「FSのリジェクト率」を定期的にモニタリングすることです。リジェクト率が高い場合、SQLの定義基準を見直す必要があります。
定例ミーティングの設計
IS-FS間の連携を継続的に改善するためには、以下の定例ミーティングを設計します。
- 日次スタンドアップ（5〜10分）：当日の引き渡し案件の共有と優先順位を確認します。
- 週次レビュー（30分）：週間のSQL創出数・リジェクト率・パイプライン進捗を振り返ります。
- 月次SLAレビュー（60分）：SLAの達成状況、変換率の推移、改善施策を協議します。
特に週次レビューでは、リジェクトされた案件の具体的な理由を分析し、ISのアプローチ改善につなげることが重要です。また、FSから「こういうリードが欲しい」「この業界のリードは商談化しやすい」といったフィードバックを共有する場としても活用します。
マーケティングとの連携設計
インサイドセールスはフィールドセールスだけでなく、マーケティングとの連携も同様に重要です。ISはマーケティングの「お客様の声の代弁者」であり、リードと直接会話する唯一のマーケティング接点です。
- MQL品質のフィードバック：ISからマーケティングに対して、MQLの品質評価（スコアリングの精度、リードソースごとの変換率）をフィードバックします。
- コンテンツニーズの共有：ISが商談の中で把握した顧客の課題やニーズを、マーケティングのコンテンツ制作に還元します。
- リサイクルリードの運用：ISが「タイミングではない」と判断したリードをマーケティングに戻し、ナーチャリングを継続する仕組みを作ります。
CRM上では、ライフサイクルステージの「差し戻し」ワークフローと、差し戻し理由を記録するプロパティを設計することで、マーケティングとISの間のリード循環を仕組み化できます。
インサイドセールス組織の立ち上げステップ
ここまで解説した設計要素を踏まえ、インサイドセールス組織を実際に立ち上げる際のステップを4フェーズで整理します。一気に全部を作り込もうとせず、段階的に広げていくスモールスタートの進め方がおすすめです。
フェーズ1：設計準備（2〜4週間）
立ち上げの成否は、この準備フェーズの設計品質で決まります。以下の項目を明確化します。
- IS組織のミッションと位置づけ：何のためにISを立ち上げるのか、どの課題を解決するのかを明文化します。
- SDR/BDRの選択：自社のビジネスモデル・リード獲得状況に応じて、SDRから始めるかBDRから始めるかを判断します。
- ライフサイクルステージの定義：リード→MQL→SQL→商談→顧客の各ステージの移行条件を明確化します。
- KPIの仮説設定：売上目標からの逆算で、各指標の仮目標値を設定します。
- 体制の決定：初期メンバー数、マネージャーの配置、レポートラインを設計します。
このフェーズで特に重要なのは、マーケティング・フィールドセールスの責任者を巻き込み、SLAを先に合意することです。IS単独で設計を進めると、他部門との「期待値のズレ」が立ち上げ後の摩擦の原因になります。
フェーズ2：CRM/SFA実装（2〜4週間）
設計した内容をCRM/SFA上で実装します。主な実装項目は以下のとおりです。
- ライフサイクルステージの設定：CRM上でステージ定義とワークフローによる自動昇格を構築します。
- パイプラインと取引ステージの設定：IS→FSの引き渡しに対応した取引ステージを構築します。
- タスクの自動化：MQL発生時の自動タスク生成、担当者割り当てのワークフローを構築します。
- シーケンスの作成：初回フォロー、資料請求フォロー、リサイクルなどのシーケンスを作成します。
- ダッシュボードとレポートの構築：KPIの計測に必要なダッシュボードを構築します。
- 必須入力プロパティの設定：引き渡し時の情報品質を担保するための必須項目を設定します。
CRM実装において注意すべきは、初期段階から「完璧な仕組み」を目指さないことです。まずは最低限のステージ設計・タスク自動化・ダッシュボードを構築し、運用しながら改善を重ねるアプローチが現実的です。項目を増やしすぎると現場が入力しなくなり、使われないプロパティが乱立するというSFA導入でありがちな失敗に陥ります。入力項目は最小限に絞り、本当に必要なものから始めてください。
フェーズ3：採用・育成と試運転（4〜8週間）
ISメンバーの採用・配置と、実際のオペレーションの試運転を行います。
- 人材の配置：社内からの異動、または新規採用でISメンバーを確保します。営業経験者が望ましいですが、マーケティング出身者やカスタマーサポート出身者も適性があります。
- オンボーディング：商材知識、CRM操作、ヒアリングスクリプト、ロールプレイなどのトレーニングを体系的に実施します。
- 試運転期間：実際のリードに対してアプローチを開始し、KPIの計測とプロセスの検証を行います。
- 初期のフィードバックループ：日次で振り返りを行い、スクリプトの改善、フォローアップの間隔調整、CRM設定の修正を迅速に実施します。
試運転期間は、KPIの「適正値」を見つけるための検証期間と位置づけます。仮説として設定した数値を実データで検証し、自社にとっての適正な目標値を導き出します。
フェーズ4：本格運用と継続改善（3ヶ月〜）
試運転の成果をもとに本格運用を開始し、継続的な改善サイクルを回します。
- KPIの確定と全体共有：試運転で検証したKPIを正式な目標として確定し、マーケティング・FSと共有します。
- 定例レビューの制度化：週次レビュー、月次SLAレビューを制度として定着させます。
- ナレッジの蓄積：成功事例・失敗事例をCRM上に記録し、チーム全体の学習に活用します。
- スケーリングの判断：ISの増員タイミング、BDR追加のタイミングを、データに基づいて判断します。
本格運用フェーズにおいて意識すべきは、「仕組みの改善」と「人の育成」を同時に進めることです。CRMの設定改善やプロセスの見直しだけでなく、ISメンバーのスキル向上（ヒアリング力、課題発見力、交渉力）にも投資を続けることが、組織としての持続的な成長につながります。
AIエージェントを活用したインサイドセールスの進化
インサイドセールスの業務は、定型的なリサーチ・メール作成・フォローアップなど、AIエージェントによる支援・自動化と相性の良い領域を多く含んでいます。AIを「人の代替」ではなく「人の能力を拡張するアシスタント」として位置づけることで、ISの生産性を高めることが可能です。
案件創出エージェントの活用パターン
AIエージェントがインサイドセールスの業務を支援する代表的なパターンは以下のとおりです。
- ターゲット企業のリサーチ：BDRが新規アプローチする企業の業界動向、最近のニュース、経営課題の仮説をAIが事前にリサーチし、アプローチの精度を高めます。
- パーソナライズドメールの作成：リサーチ結果に基づいて、ターゲット企業ごとにカスタマイズされたアプローチメールのドラフトをAIが生成します。
- メール文面のレビュー：ISが作成したメールの文面をAIがレビューし、改善提案を行います。
- フォローアップタイミングの最適化：過去のデータから、リードごとに最適なフォローアップのタイミングとチャネルをAIが提案します。
この「リサーチ→メール作成→レビュー→送信」というワークフローにおいて、AIエージェントが前半の工程を支援し、ISメンバーは「最終判断と顧客との直接コミュニケーション」に集中するという役割分担が、生産性向上の鍵です。
AIエージェント活用時の設計ポイント
AIエージェントをインサイドセールスに導入する際には、以下の設計ポイントを押さえる必要があります。
- 人間が最終判断する設計にします：AIが生成したメールや提案は、ISメンバーがレビューしてから送信する運用にしてください。完全自動化は顧客体験の低下リスクがあります。
- AIの役割を明確に定義します：「何をAIに任せ、何を人間が行うか」の境界を明確にし、チーム全体で共有します。
- CRMとの連携を前提に設計します：AIエージェントの出力をCRM上のプロパティやタイムラインに記録し、活動の可視化と分析を可能にします。
- 段階的に導入します：まずはリサーチ支援やメールドラフトなど、リスクの低い領域から導入し、効果を検証しながら範囲を拡大します。
AIはあくまで「アシスタント」であり、超一流の営業パーソンの代替ではないという認識が前提です。
AIエージェントの詳細な役割設計と実装パターンについては、「AIエージェントの役割設計と業務活用」（W-6）で体系的に解説しています。また、インサイドセールスの生産性指標の考え方については、「営業生産性の可視化と改善」（R-2）も併せてご参照ください。
以下の画面は、Breezeの案件創出エージェントが下書きしたアプローチメールの承認画面です。担当者が内容を確認してから送信できます。
Breezeの案件創出エージェントが下書きしたアプローチメールの承認画面。担当者が内容を確認してから送信できます。
インサイドセールス立ち上げでよくある失敗とその回避策
インサイドセールスの立ち上げは、多くの企業が試行錯誤を経験する領域です。ここではよくある失敗パターンとその回避策を整理します。設計段階でこれらを潰しておくと、立ち上げ後の修正コストを大きく減らせます。
失敗1：アポイント数だけをKPIに設定する
「月間アポイント数◯件」だけをKPIに設定すると、ISメンバーは数を稼ぐために質の低いアポイントを量産するようになります。結果として、フィールドセールスの時間を浪費し、IS→FSの信頼関係が悪化します。
回避策：成果指標（SQL創出数・受注貢献額）をメインKPIに設定し、活動指標（架電数など）はサブKPIとして位置づけます。「量」と「質」のバランスが取れたKPI構造にすることが重要です。
失敗2：MQL/SQLの定義が曖昧なまま運用を始める
ステージの定義が曖昧な状態で運用を始めると、「何をもってMQLとするか」「いつSQLに昇格させるか」がISメンバーの主観に依存し、品質にばらつきが生じます。
回避策：ライフサイクルステージの移行条件を具体的な基準で定義し、CRM上のワークフローで自動化します。特にMQL→SQL変換のBANT基準は、ヒアリングシートとして標準化してください。
失敗3：フィールドセールスとの連携ルールがない
SLAを定めずに運用を始めると、ISは「アポイントを渡しているのにFSが動かない」と不満を持ち、FSは「ISから渡されるリードの質が低い」と不満を持ちます。部門間の対立が生じ、組織全体のパフォーマンスが低下します。
回避策：立ち上げ前にIS-FS間のSLAを合意してください。引き渡し条件、対応期限、フィードバックの仕組みを明文化し、月次レビューで見直します。
失敗4：スプレッドシート管理とコストセンター化で仕組みが育たない
「まずはスプレッドシートで始めよう」というアプローチは、短期的には手軽ですが、リードの一元管理、活動の追跡、KPIの自動集計ができないため、組織がスケールしません。担当者マスターと顧客リストで別々に情報を持つと差分も起きやすく、どちらが正しい情報か分からなくなります。
また、インサイドセールスを「アポイントを取る部門」としてのみ位置づけると、戦略的な投資ではなくコスト削減の対象になりがちです。結果として、優秀な人材が配置されず、育成にも投資されず、「テレアポ部隊」化してしまいます。
回避策：立ち上げ初期からCRM/SFAを導入し、データの蓄積を開始します。初期投資は必要ですが、蓄積されたデータが後の改善サイクルを支える基盤になります。あわせて、ISの受注貢献額をCRMのアトリビューション分析でトラッキングし、「売上に直結する投資」として経営層に位置づけてもらうことが重要です。
よくある質問
Q. インサイドセールスは何名体制から始めるのが適切ですか？
まずは2〜3名からスタートするのが一般的です。1名だと休暇や退職のリスクに対応できず、多すぎると管理コストが先行します。初期メンバーの中にマネージャー（プレイングマネージャーでも可）を1名配置し、KPIの管理とフィールドセールスとの連携を統括させる体制が望ましいです。メンバー1名が無理なく対応できるMQLの量は、商材やフォロー回数の設計によって変わるため、試運転の実績データをもとに負荷の上限を決めていきましょう。
Q. SDRとBDRのどちらを先に立ち上げるべきですか？
多くの企業では、SDR（インバウンド対応型）から立ち上げることを推奨します。マーケティングからのリードが既に存在する場合に即座に活動を開始でき、BDRと比較してオペレーションの難易度が低いためです。SDRの運用を通じてライフサイクルステージやKPI管理の仕組みを整備しておけば、BDR追加時にその基盤を活用できます。
ただし、ターゲット企業が明確に絞り込まれている場合や、インバウンドリードが極めて少ない場合には、BDRから着手するケースもあります。
Q. MQLの基準は厳しめと緩めのどちらに設定すべきですか？
立ち上げ初期は、やや緩めに設定してインサイドセールスに十分なリード量を供給し、運用データを蓄積することを優先します。MQL→SQL変換率の実績データが蓄積されてきたら、そのデータをもとに基準を段階的に引き上げていくアプローチが有効です。蓄積された変換率の実績を目安に、自社にとっての最適なバランスを見つけていくことが重要です。
Q. インサイドセールスの評価制度はどう設計すべきですか？
評価制度は、KPIの3層構造に対応させる形で設計します。SQL創出数や受注貢献額などの「成果指標」を主軸としつつ、MQL→SQL変換率やレスポンスタイムなどの「プロセス指標」も組み込むことが重要です。架電数などの「活動指標」だけでインセンティブを設計すると、量だけを追う行動が促進されるリスクがあります。
IS起点の商談が受注に至った場合に、ISメンバーにも受注インセンティブの一部が還元される設計にすると、「質の高い商談を創出する」動機づけが強まります。
Q. CRMはHubSpot以外でもインサイドセールスの仕組みは構築できますか？
本記事で解説した設計思想やプロセスは特定のCRMに依存するものではなく、Salesforce、Zoho CRM、Pipedriveなど他のCRM/SFAでも実装可能です。ただし、ライフサイクルステージの管理、ワークフローによるタスク自動化、シーケンス、パイプライン管理、ダッシュボード構築の機能が揃っていることが前提です。
HubSpotはこれらの機能が統合プラットフォームとして一体的に提供されている点で、インサイドセールスの立ち上げとの親和性が高いと言えます。
まとめ
インサイドセールス組織の立ち上げは、単に「人を配置して電話をかけさせる」ことではありません。組織設計・プロセス設計・システム設計・KPI設計を一体的に行うことで、はじめて機能する営業機能です。本記事のポイントを振り返ります。
- インサイドセールスの役割を正しく定義します：テレアポではなく、マーケティングとフィールドセールスをつなぐ「変換装置」として設計します。
- SDRとBDRの違いを理解し、自社に適した型を選択します：多くの企業では、まずSDRから立ち上げ、段階的にBDRを追加するアプローチが有効です。
- ライフサイクルステージを明確に定義します：リード→MQL→SQL→商談→顧客の移行条件を定量的に設定し、CRM上で実装します。
- KPIは3層構造で設計します：成果指標・プロセス指標・活動指標の因果関係を意識し、売上目標からの逆算で目標値を設定します。
- CRM/SFAでプロセスを仕組み化します：ステージ管理、パイプライン、シーケンス、タスク、引き渡しをシステムで担保し、属人化を防ぎます。
- フィールドセールスとのSLAを合意します：引き渡し条件、対応期限、フィードバックの仕組みを明文化します。
- AIエージェントは「アシスタント」として活用します：人とAIの役割分担を明確にし、最終判断は人間が行う設計にします。
最初の一歩は、まず「リード→MQL→SQLの定義を1枚の図に描く」ことから始めるのがおすすめです。今日からできる次の行動は、次の3ステップです。
- 現状のリードの流れを棚卸しし、マーケティングから営業へリードがどう渡り、どこで滞留・放置されているかを洗い出します。
- ライフサイクルステージとMQL/SQLの移行条件を、マーケティング・フィールドセールスと合意できる粒度で書き出します。
- CRMでステージのプロパティと担当者割り当ての自動化という最小構成から実装し、運用しながら改善を重ねます。
インサイドセールスは、設計品質が成果を左右する営業機能です。自社のビジネスモデルとリード獲得状況に合わせた設計を行い、段階的に立ち上げていきましょう。CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
