エグゼクティブ・サマリー
- インサイドセールス（IS）は、体制を作っただけでは機能しない。MQL→SQL→SQO→受注というファネルを共通言語で定義し、各段の転換率・速度・質を測って初めて「商談を生む工程」になる。
- 最重要は、部門をまたぐ接続点（マーケ→IS→FS）のマネジメントである。KPIは「数」だけでなく、段から段への転換率と、リードへの初速（初回応答時間）に置く。初速は商談化率を左右する決定的な変数だ。
- 目標受注から各段の転換率で逆算すれば、必要なMQL数＝マーケへの要求量が定まる。ファネルは連鎖なので、最も詰まった一段（ボトルネック）に資源を集中させると全体が動く。
- 数を追うと質が落ちる。これを防ぐのがフィードバックループ（差し戻し）だ。量のKPIと質のKPIを必ずペアで持つ。
- 本稿は、定義・役割設計・KPIカタログ・会話フレーム・逆算の計算例・SLA・ダッシュボード・90日立ち上げ計画・成熟度モデル・付録（用語集/チェックリスト）まで、そのまま自社に当てはめられる形で提示する。
なぜ、インサイドセールスはKPIで回さないと機能しないのか
多くの組織がインサイドセールスを立ち上げ、そして「思ったほど商談が増えない」と嘆く。原因は人材の質でも努力量でもなく、ファネルが数字で管理されていないことにある。
管理されていないファネルには、3つの症状が現れる。第一に、定義のばらつき。「商談」の基準が人によって違えば、数字は比較できず、部門間の受け渡しも壊れる。第二に、接続点の断絶。マーケが渡したリードにISがいつ触れたか、ISが渡した案件をFSがどう評価したかが見えず、責任が曖昧になる。第三に、感覚運用。「今月は調子が良い/悪い」という体感で意思決定し、どこを直せば効くのかが分からない。
これらはすべて、測っていないから起きる。逆に言えば、ファネルを定義し、各段を数値化し、接続点にKPIを置くだけで、インサイドセールスは「属人的な架電部隊」から「予測可能な商談創出エンジン」へと変わる。KPI設計は管理のための事務作業ではない。商談創出を再現可能にするための、事業設計そのものである。
ファネルの共通言語 —— MQL / SQL / SQO / 受注
すべての出発点は、各段階を組織で一つに定義することだ。ここが揃っていないと、以降のKPIは意味を持たない。
| 段階 | 定義 | 判定の責任 | 判定基準の例 | システム上の記録 |
|---|---|---|---|---|
| リード | 接点を持った見込み（名刺・DL・問い合わせ等） | マーケ | 連絡先が取得できている | MA/CRMにリード作成 |
| MQL | マーケ基準で「見込みあり」と判断したリード | マーケ | スコア閾値／特定行動（資料DL・料金ページ閲覧等） | ステータス=MQL |
| SQL | ISが精査し、営業が追う価値ありと認めたリード | IS | 課題・関心が確認でき、対話が成立 | ステータス=SQL |
| SQO | 商談化した案件（資格条件を満たす） | IS→FS | BANT等（予算・決裁・ニーズ・時期）の確認 | 商談（Opportunity）作成 |
| 受注 | クロージングに至った案件 | FS | 契約・発注 | 商談=Won |
ここで肝になるのが接続点だ。MQL→SQL はマーケとISの受け渡し、SQL→SQO はISとFSの受け渡しにあたる。KPIは、この受け渡しの点にこそ置く。段の「中」ではなく、段と段の「あいだ」でファネルは詰まるからだ。
定義でとくに注意すべきは、MQLとSQLの境界である。MQLは「マーケが渡してよいと判断した」段階、SQLは「ISが追う価値を認めた」段階だ。この二つを混同すると、マーケが「リードを渡した数」を成果と誤認し、ISが「質の低いリード」に忙殺される。渡す基準（マーケの責任）と受ける基準（ISの責任）を別々に、かつ明文で定義することが、後段すべての健全性を決める。
測るべきは、各段の「数」だけでなく、段から段への「転換率」と「速度」である。