SaaS企業の営業組織において、インサイドセールス（IS）は「あったら便利」な機能ではなく、ARRを積み上げるための基幹インフラです。しかし、一般的なBtoB企業向けのIS運用をそのまま持ち込んでも、SaaS特有の構造にフィットしないケースが少なくありません。
トライアルやフリーミアムから生まれるProduct Qualified Lead（PQL）の扱い、月額課金を前提としたパイプライン管理、カスタマーサクセスとの接続――。SaaSならではの論点を押さえずにISを立ち上げると、「架電はしているが受注につながらない」状態に陥ります。
本記事では、SaaS企業がISを構築・運用する際に押さえるべき実務を体系的に整理します。汎用的なIS立ち上げの基本についてはインサイドセールスの立ち上げと運用ガイドで解説していますので、併せて参照してください。
SaaSのISが汎用BtoBと異なる点
要点: PQLの扱い、月額課金前提のパイプライン管理、CS連携がSaaS特有のIS論点。
SaaS企業のインサイドセールスには、従来型BtoBのIS運用とは構造的に異なるポイントがあります。この違いを理解しないまま組織を設計すると、KPI設計やフォロー方針がずれてしまいます。
リードの種類が多層化している
一般的なBtoBでは、マーケティングが獲得したMQL（Marketing Qualified Lead）をISがフォローする一方向のフローが基本です。SaaSではこれに加えて、プロダクト利用から生まれるPQL（Product Qualified Lead）が存在します。
| リード種別 | 定義 | 商談化率の目安 | 対応の優先度 |
|---|---|---|---|
| MQL | マーケ施策経由で一定スコアに達したリード | 10〜15% | 中 |
| PQL | トライアルやフリーミアムで一定の利用行動をとったリード | 25〜40% | 高 |
| SQL | ISがヒアリングし商談化基準を満たしたリード | 40〜60% | 最高 |
| Inbound問い合わせ | フォーム経由の直接問い合わせ | 30〜50% | 高 |
PQLはプロダクトの価値を体感済みであるため、MQLと比べて商談化率が高い傾向にあります。ISの設計段階でPQLの検知条件と対応フローを組み込んでおくことが、SaaS型ISの第一歩です。
ゴールが「受注」ではなく「契約継続」に紐づく
売り切り型のビジネスではISのゴールは「商談設定」で完結しますが、SaaSではその先の契約継続までを視野に入れる必要があります。無理な商談設定でミスマッチな顧客を獲得しても、早期解約でARRは伸びません。
ISの段階で「この顧客が自社プロダクトで成果を出せるか」を見極めるフィルタリングの意識が求められます。
ARR/MRRを意識したパイプライン管理
SaaSのISは、商談件数だけでなくパイプラインの金額規模をARRベースで管理します。月額5万円のプロダクトなら、1件の商談は年間ARR 60万円分のパイプライン。月間目標ARRから逆算して、必要な商談数・SQL数・MQL数を算出する考え方が基本です。
| 指標 | 算出方法 | 例（月額5万円のSaaS） |
|---|---|---|
| 目標新規ARR/月 | 事業計画から設定 | 600万円 |
| 必要受注件数 | 目標ARR / プロダクト年額 | 10件 |
| 必要商談数 | 受注件数 / 受注率(25%) | 40件 |
| 必要SQL数 | 商談数 / SQL→商談転換率(80%) | 50件 |
| 必要MQL+PQL数 | SQL数 / MQL→SQL転換率(20%) | 250件 |
この逆算モデルがあれば、「マーケが月に何件リードを供給すべきか」「ISは何件のSQLを生成すべきか」が明確になります。データドリブン営業の始め方で解説しているファネル分析の考え方をISのパイプラインに適用する形です。
ISの組織設計とポジショニング
要点: IS専任1名からスタート可能。月間MQL30〜50件に対して1名が目安。
THE MODEL型の分業構造
SaaS企業のIS組織は、THE MODEL型の分業構造の中に位置づけるのが標準です。マーケティング → IS → フィールドセールス（FS） → カスタマーサクセス（CS）の4ファンクションで顧客ライフサイクル全体をカバーします。
| ファンクション | 主な責任範囲 | SaaS特有のポイント |
|---|---|---|
| マーケティング | リード獲得・MQL創出 | PLGではプロダクト内CTA設計も担う |
| インサイドセールス | MQL/PQLの精査・SQL化 | トライアル誘導の判断を含む |
| フィールドセールス | 商談・提案・クロージング | エンタープライズではPoCの設計も |
| カスタマーサクセス | オンボーディング・拡大・継続 | チャーン抑止がARRの命綱 |
SDR型とBDR型の使い分け
SaaS企業のIS立ち上げ期は、インバウンドリードをフォローするSDR（Sales Development Representative）型が基本です。MQLとPQLの対応に集中することで、早期に成果指標の基準値を確立できます。
ARR 1億円を超えてエンタープライズ開拓を始める段階では、ターゲットアカウントへ能動的にアプローチするBDR（Business Development Representative）型を追加します。SDRとBDRは兼任せず、役割を分けた方がパフォーマンスは安定します。
採用と人材要件
SaaS ISの人材要件は、汎用BtoBのISとやや異なります。プロダクトの機能理解と、顧客の業務課題をマッチングさせる力が問われます。
| 要件 | 汎用BtoB IS | SaaS IS |
|---|---|---|
| プロダクト理解 | サービス概要レベル | 機能・ユースケースの深い理解 |
| 業界知識 | 広く浅く | ターゲット業界の業務フロー理解 |
| デモ対応 | 不要なことが多い | 簡易デモやトライアル案内が発生 |
| データリテラシー | CRM入力レベル | プロダクト利用データの読み取り |
| 連携先 | マーケ + FS | マーケ + FS + CS + プロダクトチーム |
初期採用では、フィールドセールス経験者やカスタマーサクセス経験者を1名配置するのが有効です。商談の質を理解している人間がIS側にいることで、SQLの基準設定がスムーズに進みます。
PQLの定義と運用設計
要点: PQLはMQLの2〜3倍の商談化率を持つ。プロダクト内行動をトリガーにした定義と検知の仕組みを整備する。
PQLとは何か
PQL（Product Qualified Lead）は、プロダクトの利用行動から「購買の準備ができている」と判断されるリードです。MQLがマーケ施策上の行動（資料DL、セミナー参加など）で判定されるのに対し、PQLはプロダクト内の行動で判定されます。
PLG（Product-Led Growth）を採用するSaaSでは、PQLが最重要のリードソースになります。一方、SLG（Sales-Led Growth）主体の場合でも、トライアルを提供していればPQLの概念は適用できます。
PQLの検知条件を設計する
PQLの定義はプロダクトの性質によって大きく異なりますが、共通して使われるシグナルを整理します。
| シグナル種別 | 具体例 | スコア重みの目安 |
|---|---|---|
| 機能利用 | コア機能を3回以上使用 | 高 |
| 利用頻度 | 週3日以上ログイン | 高 |
| チーム利用 | 招待ユーザーが2名以上 | 非常に高 |
| 連携設定 | 外部ツールとのAPI連携を実施 | 高 |
| 利用量 | 無料プランの上限に近づいている | 高 |
| 閲覧行動 | 料金ページの閲覧 | 中 |
| サポート | チャットで機能の質問 | 中 |
特に「チーム利用の拡大」と「連携設定の完了」は、プロダクトが業務に組み込まれつつあるサインであり、PQLシグナルとして重みが大きい項目です。
PQLのISフォロー手順
PQLが検知されたら、ISは以下の流れで対応します。
- プロダクト利用データを確認し、利用状況を把握する
- メールまたはアプリ内メッセージで接触する（架電よりもまずメールが効果的）
- 利用中の課題や活用の広がりをヒアリングする
- 有償プランの案内、またはFSへの商談引き渡しを行う
PQLへのアプローチで重要なのは、「売り込み」ではなく「活用支援」の姿勢で入ることです。プロダクトの価値をすでに体験しているユーザーに対して、さらに深い活用方法を提案する形が自然です。
トライアル誘導とオンボーディング設計
要点: ARPAで判断。月額1万円以下ならトライアル優先、5万円以上なら商談設定優先。
トライアル誘導の判断基準
ISがリードと接触した際に、「商談設定」と「トライアル誘導」のどちらに進めるかは、プロダクトの単価と顧客セグメントで判断します。
| 条件 | トライアル誘導が適切 | 商談設定が適切 |
|---|---|---|
| ARPA | 月額3万円以下 | 月額5万円以上 |
| 顧客規模 | SMB（従業員100名以下） | ミッドマーケット以上 |
| 導入ハードル | セルフサーブで開始できる | 要件定義やPoC が必要 |
| 意思決定 | 担当者レベルで決裁可能 | 複数部署の承認が必要 |
| プロダクト特性 | 直感的に使える | カスタマイズや連携設定が前提 |
中間的なケースでは、「まずトライアルで触ってもらい、2週間後に商談を設定する」ハイブリッド型も有効です。
トライアル中のISフォロー設計
トライアル期間中のISフォローは、開始直後と終了直前に山場を作る設計が効果的です。
| タイミング | アクション | 目的 |
|---|---|---|
| 開始当日 | ウェルカムメール + 活用ガイド送付 | 初期設定の支援 |
| 3日後 | 利用状況の確認メール | 離脱防止 |
| 1週間後 | 架電でヒアリング | 課題把握・活用提案 |
| トライアル終了5日前 | 有償プラン案内メール | 契約判断の促進 |
| トライアル終了2日前 | 架電で最終フォロー | クロージングまたはFS引き渡し |
トライアル中に一度もログインしていないユーザーには、3日目の段階で「何かお困りの点はありますか」とサポート起点の架電を入れます。放置するとそのまま離脱し、リードとしての価値が消失します。
KPI設計とパイプライン管理
要点: MQL→SQL転換率、PQL→商談率、ARR貢献額の3軸でISのパフォーマンスを管理する。
SaaS IS特有のKPI体系
SaaS ISのKPIは、汎用BtoBのISとは異なるSaaS固有の指標を組み込みます。
活動指標（先行指標）
| 指標 | 目安（SDR 1名あたり） |
|---|---|
| MQLフォロー架電数/日 | 20〜30件 |
| PQLフォロー件数/日 | 5〜10件 |
| トライアル誘導数/週 | 8〜15件 |
| 有効会話数/日 | 8〜12件 |
| デモ実施数/週 | 3〜5件 |
成果指標（遅行指標）
| 指標 | 目安 |
|---|---|
| MQL→SQL転換率 | 15〜25% |
| PQL→SQL転換率 | 30〜50% |
| トライアル→有償転換率 | 10〜20% |
| SQL→商談化率 | 70〜85% |
| パイプライン創出ARR/月 | 事業計画に準拠 |
汎用BtoBのISでは「商談設定件数」が最重要KPIになりがちですが、SaaSではパイプライン創出ARRを最上位の成果指標に据えます。10件の商談を設定しても、すべてが月額1万円以下の小口案件であれば、ARRへのインパクトは限定的です。ARRベースで管理することで、商談の「数」と「質」のバランスが取れます。
パイプライン会議の運用
SaaS ISのパイプライン管理では、週次のパイプライン会議を設け、以下の観点でレビューします。
- 当月のパイプライン残高（ARRベース）と目標達成見込み
- ステージ別の滞留案件（2週間以上動きがない商談）
- トライアル→有償転換の進捗
- MQL/PQLの供給量とIS側の処理能力のバランス
- 失注・解約案件からの学び
CRM/SFAにパイプラインデータが正確に入力されていることが前提です。データの鮮度が落ちるとパイプライン会議の精度も落ちるため、ISメンバーの入力ルールを厳格に定めておく必要があります。
マーケティング連携の設計
要点: MQLの質フィードバックをマーケに返す仕組みと、リード引き渡しのSLAを明文化する。
MQLの引き渡しルール
マーケティングからISへのMQL引き渡しは、リードスコアリングの基準に基づいて行います。SaaSでは、スコアリングの属性項目にプロダクト利用に関連する情報を加味するのがポイントです。
| 属性スコア項目 | 配点例 |
|---|---|
| 従業員規模がICP合致 | +20 |
| ターゲット業種 | +15 |
| 役職（マネージャー以上） | +10 |
| 過去にトライアル経験あり | +15 |
| 行動スコア項目 | 配点例 |
|---|---|
| 料金ページ閲覧 | +20 |
| 事例ページ閲覧 | +10 |
| ホワイトペーパーDL | +10 |
| セミナー参加 | +15 |
| トライアル申込ページ訪問（未申込） | +25 |
スコア閾値を超えたリードが自動的にISに通知される仕組みをMAで構築します。MA導入・活用ガイドで解説しているワークフロー設計の考え方がそのまま適用できます。
ISからマーケへのフィードバック
ISが架電を通じて得た定性情報は、マーケ施策の改善に直結します。週次の連携ミーティングで以下を共有する運用を定着させます。
- どのチャネル経由のリードが商談化しやすいか
- リードが口にする「検討のきっかけ」として多い言葉
- 競合として名前が挙がるサービスの傾向
- 「まだ早い」と判断されたリードの共通特徴
このフィードバックがマーケの施策精度を上げ、結果としてMQLの質が向上するサイクルが回り始めます。
カスタマーサクセスとの連携
要点: 受注を境界にIS→CSへ引き継ぐ。トライアル中はCSが主担当、ISがフォロー架電のハイブリッド型が有効。
SaaS特有の「IS→CS」接続
SaaS企業のISは、フィールドセールスだけでなくカスタマーサクセス（CS）との連携も重要です。特にトライアル期間中のオンボーディング支援は、ISとCSの協業領域になります。
| フェーズ | IS の役割 | CS の役割 |
|---|---|---|
| トライアル開始前 | トライアル誘導・初期設定案内 | - |
| トライアル中（前半） | 利用状況確認・課題ヒアリング | オンボーディング支援 |
| トライアル中（後半） | 有償プラン案内・商談設定 | 活用レビュー・成功体験の創出 |
| 受注後 | - | オンボーディング本格化・定着支援 |
| 契約更新期 | アップセル/クロスセル商談の検知 | 更新確認・利用状況レビュー |
ISがトライアル中に把握した「顧客の課題」「利用目的」「期待する成果」の情報は、受注後にCSが引き継ぐべき重要なコンテキストです。CRMの商談レコードにこれらの情報を残す運用ルールを設けておきます。
エクスパンション商談の検知
既存顧客のアップセル・クロスセルの検知は、CSが主導しますが、ISが関与するケースもあります。たとえば、既存顧客の別部署からの問い合わせや、グループ会社への展開検討など、新規に近い商流が発生する場面ではISが初動を取ります。
ツール選定と運用環境の構築
要点: CRM+架電ツール+会議録画の3種が最小構成。MA連携はリード数が増えてから検討する。
SaaS ISに必要なツールスタック
| カテゴリ | ツール例 | SaaS ISでの活用ポイント |
|---|---|---|
| CRM/SFA | Salesforce、HubSpot | ARRベースのパイプライン管理 |
| MA | HubSpot、Marketo、Pardot | PQLシグナルとMQLスコアの統合管理 |
| CTI | MiiTel、Dialpad | 通話録音・トーク分析 |
| プロダクト分析 | Amplitude、Mixpanel | PQL検知のための利用データ取得 |
| CS基盤 | Gainsight、HiCustomer | トライアル→有償転換の進捗管理 |
| BIツール | Looker Studio、Tableau | パイプラインダッシュボード |
特にSaaS ISで見落とされがちなのが、プロダクト分析ツールとCRMの連携です。PQLの検知にはプロダクト側の利用データが必要であり、AmplitudeやMixpanelのイベントデータをCRMに流す仕組みがなければ、PQLベースのIS運用は回りません。
データフローの設計
プロダクト → 分析ツール → CRM → ISのアクション、という一連のデータフローを設計します。リアルタイム連携が理想ですが、初期段階では日次バッチで十分です。重要なのは、ISメンバーがCRMの画面を開いた時点で「今日フォローすべきPQL」が一覧で見える状態を作ることです。
セールスイネーブルメントの観点からも、ISメンバーが顧客情報にすぐアクセスできる環境づくりは生産性に直結します。
よくある質問
Q. SaaSのインサイドセールスは何名から始められますか？
専任1名からスタート可能です。月間MQL 30〜50件に対して1名が目安で、PLGモデルの場合はPQLの対応も加わるため、トライアル発生件数に応じて早めに2名体制を検討します。
Q. PQLとMQLはどちらを優先してフォローすべきですか？
PQLを優先します。プロダクト内で実際に行動しているリードは購買意欲が高く、商談化率もMQLの2〜3倍になる傾向があります。ただしPQL発生件数が少ないうちはMQLフォローを軸にし、PQLの定義と検知を並行で整備するのが現実的です。
Q. SaaSのISではトライアル誘導と商談設定のどちらを優先すべきですか？
ARPA（顧客単価）で判断します。月額1万円以下のプロダクトではトライアル誘導を優先し、プロダクト体験で価値を実感してもらう方が効率的です。月額5万円以上の場合は商談設定を優先し、導入支援や要件整理を対面で行う方が受注率は上がります。
Q. インサイドセールスとカスタマーサクセスの境界はどこで引くべきですか？
受注（契約締結）を境界にするのが基本です。ただしSaaSではトライアル中のオンボーディング支援が契約を左右するため、トライアル開始後はCSが主担当、ISはフォロー架電で連携するハイブリッド型が有効です。
まとめ
SaaS企業のインサイドセールスは、汎用BtoBのIS運用をベースにしつつ、SaaS固有の構造に合わせた設計が求められます。
- SaaS ISではMQLに加えてPQLが重要なリードソースになる。PQLの検知条件と対応フローを初期段階で設計する
- ISのゴールは商談設定だけではなく、ARRの積み上げに貢献するパイプライン創出にある
- トライアル誘導と商談設定の使い分けはARPAと顧客セグメントで判断する
- カスタマーサクセスとの連携は受注前のトライアル期間から始まる
- パイプライン管理はARRベースで行い、商談の「数」と「質」のバランスを取る
- プロダクト分析ツールとCRMの連携がPQL運用の技術的な前提条件になる
IS組織の立ち上げにリソースが足りない場合は、戦略設計から運用構築までを外部パートナーに委託する方法もあります。SaaS企業のマーケティング組織の立ち上げと合わせて、マーケティングからISまでの一貫した仕組みづくりを検討してみてください。
