SQLとパイプライン寄与の測定|IS起点の商談・受注への貢献度を可視化して組織価値を証明する
アポ率も商談化率も改善している。それなのに期末に「インサイドセールスの成果は結局何だったのか」と問われると、数字で答えられない。多くのインサイドセールス(IS)部門がこの状態に陥るのは、評価が「渡した商談の数」で止まっていて、「渡した先がどれだけ受注に寄与したか」まで測れていないからです。
SQL(営業が引き継ぐ条件を満たした見込み客)を何件渡したかは活動の結果であって、部門の価値そのものではありません。この記事では、IS起点のパイプライン寄与を4つの指標で測り、経営にISの価値を数字で証明するための設計・運用手順を扱います。
KPI全体の体系的な整理はインサイドセールスのKPI設計と目標管理を参照してください。この記事はそのうちパイプライン寄与、つまりSQLの受注貢献の測定だけを深掘りします。
なぜSQLの「数」だけではIS部門の価値を証明できないのか
SQLを何件渡したかは活動の結果であって、成果ではありません。ISの成果はその先の受注寄与であり、SQL数だけを追うと「渡せば渡すほど良い」という圧力がかかって引き渡しの質が下がります。
渡したSQLがフィールドセールス(FS)に受理されず差し戻される、あるいは受理されても失注が続くなら、SQL数がいくら伸びても部門の貢献は増えていません。ここでは、SQL数をKPIに据えることの落とし穴と、測るべきは下流の受注貢献であることを整理します。
SQL(営業が引き継ぐ条件を満たした見込み客)の位置づけ
SQL(Sales Qualified Lead)は、営業が商談として引き継ぐ条件を満たしたと判断された見込み客を指します。マーケティングが評価・育成したリードであるMQL(Marketing Qualified Lead)が引き継ぎの前段にあり、そのなかで営業への引き渡し基準を満たしたものがSQLです。
MQLからSQLへの移行や、営業が正式に受理したSAL(Sales Accepted Lead)といった段階を細かく分ける組織もありますが、ここで重要なのは呼称の細分化ではなく、SQLが「IS部門が営業に手渡す境界線」に位置する点です。この境界を越えたリードがどうなったかまで追わなければ、ISの貢献は見えません。
「SQL数をKPIにする」ことで起きる質の低下
SQL数を唯一のKPIに置くと、商談化ありきの圧力が働き、受注に至りにくい案件まで無理に引き渡すようになります。結果として起きるのは、FSが「これは商談として成立しない」と判断して差し戻すケースの増加と、受理されても初回商談後に失注する案件の増加です。差し戻された分はISの再対応工数を生み、無理に受理された分はFSの商談準備・提案工数を浪費します。
こうした兆候、つまり差し戻し率の上昇と初回商談後の失注増は、SQL数だけを見ていると検知できません。数は伸びているのに受注が連動しない乖離が続くとき、KPIの設計そのものが下流を捉えていないと疑うべきです。
IS起点のパイプライン寄与を測る4つの指標
IS部門の受注貢献は、「有効商談化率」「SQL受注寄与率」「IS起点パイプライン創出額」「IS起点受注額」の4指標で測ると、渡した先までの貢献が数字になります。前者2つは件数ベースで引き渡しの質を、後者2つは金額ベースで経営への貢献を語る指標です。
件数だけでは経営の投資判断につながらず、金額だけでは引き渡しプロセスの改善点が見えないため、両方をそろえて追う必要があります。以下、それぞれの分母・分子と、なぜその指標が要るかを計算式と数値例で示します。
有効商談化率|渡したSQLのうちFSが受理した割合
有効商談化率は、FSが「商談として有効」と受理した数を、ISが渡したSQL数で割った値です。
有効商談化率 = FSが受理した有効商談数 ÷ ISが引き渡したSQL数
たとえば月に100件のSQLを引き渡し、そのうち70件をFSが有効商談として受理したなら、有効商談化率は70%です。残りの30件は差し戻し、つまり受理されなかったSQLで、この差し戻しを可視化することがこの指標の役割です。
数値を追うだけでなく、差し戻しの中身を見ることで引き渡し基準のズレが分かります。閾値は業界一律の正解がないため、まず直近実績を基準線に置き、差し戻し要因を潰しながら改善余地から目標を決めるのが現実的です。
SQL受注寄与率|渡したSQLがどれだけ受注に至ったか
SQL受注寄与率は、IS起点のSQL由来で受注に至った案件数を、IS引き渡しSQL数で割った値です。
SQL受注寄与率 = IS起点SQL由来の受注数 ÷ IS引き渡しSQL数
100件のSQLのうち最終的に15件が受注に至ったなら、SQL受注寄与率は15%です。注意すべきは時間差です。引き渡しから受注までにはリードタイムがあるため、今月引き渡したSQLの受注は数か月後に確定します。単月の引き渡し数と単月の受注数を単純に割ると寄与を過小評価するため、引き渡し月ごとにグループ化して追うコホート集計が前提になります。
IS起点パイプライン創出額|金額でISの貢献を語る
件数指標だけでは、経営に対して「ISは今期いくらの売上機会を生んだのか」を語れません。IS起点パイプライン創出額は、IS起点で発生した案件の想定金額の合計です。
IS起点パイプライン創出額 = IS起点で発生した各案件の想定金額の合計
有効商談化率が高くても、単価の低い案件ばかりでは経営への貢献は小さくなります。逆に件数は少なくても大型案件を生んでいれば貢献は大きい。この差は金額でしか語れません。「ISは今期○円のパイプラインを創出した」という一文が、部門の存在価値を経営の言語に翻訳します。
IS起点受注額|最終的な売上貢献
IS起点受注額は、IS起点案件のうち実際に受注した金額の合計で、KGI(重要目標達成指標)への直接の寄与を示します。
IS起点受注額 = IS起点で受注した各案件の金額の合計
パイプライン創出額が「生んだ機会」を表すのに対し、受注額は「確定した成果」を表します。両者を並べると、創出した機会がどの程度売上に転換したかという転換の質まで見えます。この指標が積み上がって初めて、IS部門は「売上にこれだけ貢献した」と証明できます。
SQLの引き継ぎ基準(SLA)を営業とそろえる手順
寄与を正しく測る前提は、ISとFSでSQLの引き継ぎ基準を合意していることです。この合意をSLA(Service Level Agreement:部門間で交わす引き継ぎ品質の取り決め)と呼びます。基準がズレていると、ISが「渡したSQL」とFSが「受理する商談」の定義が食い違い、有効商談化率そのものが測定できません。BANTやCHAMPといった一般的なフレームを出発点に、自社の受注要因へ落とし込む手順を示します。
引き継ぎ基準の言語化(BANT・CHAMPを自社仕様に)
BANTは、Budget(予算)・Authority(決裁権)・Need(ニーズ)・Timeframe(導入時期)の頭文字を取った、見込み客の検討度合いを測る古典的なフレームです。CHAMPはChallenges(課題)を起点に据えた派生型で、顧客の課題から入る点が異なります。
これらは出発点として有効ですが、型に固執すると自社の受注パターンと合わなくなります。たとえば予算が固まっていなくても、課題が明確で決裁者と接点があれば受注に至りやすい商材もあります。
過去の受注案件を振り返り、どの条件がそろったときに受注しているかを洗い出して、引き継ぎの判断ラインを自社仕様の言葉で定義します。「導入時期が半年以内かつ決裁者と接点あり」のように、ISとFSが同じ絵を描ける粒度まで具体化することが肝心です。
差し戻しルールと再ナーチャリングへの戻し
すべてのSQLが受理されるわけではありません。基準を満たさないと判断されたSQLをどう扱うかを、あらかじめルール化します。受理されなかったリードは失注扱いにせず、MAやISに戻して再ナーチャリング(継続的な情報提供による見込み客の育成)の対象にします。時期尚早だっただけで、数か月後に条件がそろえば再びSQLになり得るからです。
差し戻しを部門間の責任のなすり合いにすると、基準のすり合わせが進まず数字も歪みます。差し戻しは「引き継ぎ基準を改善するためのデータ」と位置づけ、なぜ受理されなかったかを記録して、四半期ごとの基準見直しに使います。
引き継ぎ時に渡す情報(コンテキストの伝達)
引き継ぎで基準を満たすかどうかだけでなく、ISが得たコンテキストをFSへ確実に渡すことが受注寄与を左右します。ヒアリングで把握した課題、過去の接点履歴、懸念事項が欠けたまま渡すと、FSは初回商談で同じ質問を繰り返し、顧客体験が悪化して受注寄与率が下がります。
引き継ぎ時に渡すべき項目を固定し、抜けを防ぎます。
- 顧客が抱える課題とその背景
- これまでの接点履歴(問い合わせ経緯・過去の商談有無)
- 予算・決裁体制・導入希望時期の把握状況
- 顧客が示した懸念や不安要素
- 次アクションの合意事項(誰がいつ何をするか)
受注寄与を可視化するデータ設計|SFA/MAで追跡する
4指標を継続して測るには、リード獲得から受注までを1本のパイプラインとして追える案件データ設計が必要です。ISのアクションと案件(フェーズ・受注確度・金額)が紐づき、案件の起点がIS・MA・インバウンドのどれかを識別できることが条件になります。
この土台がないと、いくら指標を定義しても数字を分離できません。ここでは起点の持たせ方、リードタイムを考慮した集計、レポートでの定点観測の3点を扱います。
起点(ソース)を案件に持たせる
案件に「IS起点」というフラグやリードソースを持たせないと、その受注がISの貢献なのか、インバウンドやマーケ経由なのかを分離できません。起点を識別できて初めて、IS起点受注額やSQL受注寄与率が計算できます。前提として、取引先・案件・コンタクト・アクションが1つのパイプライン上で紐づいている必要があります。
たとえばMazrica SalesのようなSFA/CRM(営業支援システム/顧客関係管理)では、取引先を起点に案件・コンタクト・アクションを紐づけて管理し、案件ごとにフェーズ・受注確度・金額を一元管理できます。取引先の下に案件がぶら下がり、そこにISが行った電話・メール・面談といったアクションが記録される構造であれば、どのアクションを起点に案件が生まれたかを追跡できます。起点フラグやリードソースを案件の項目として設計しておけば、後段の集計で貢献を分離できます。
リードタイムを考慮した集計(コホートで見る)
IS引き渡しから受注までは数か月かかることが多く、単月で寄与を見ると過小評価になります。今月引き渡したSQLの受注は来月以降に確定するため、「今月の引き渡し数」と「今月の受注数」を割っても実態を表しません。
そこで、案件発生日からのリードタイム(案件が発生してから受注までの経過期間)を使い、引き渡し月ごとのコホートで受注寄与率を追います。たとえば「4月に引き渡したSQL群が、その後どれだけ受注に至ったか」を数か月分の観察期間を取って確定させる見方です。あわせて、フェーズ滞留日数(案件が各フェーズにとどまっている日数)を使えば、どのフェーズで案件が停滞しているかを検知でき、寄与が伸びない原因の切り分けに役立ちます。
レポートで4指標を定点観測する
指標は一度計算して終わりではなく、定点観測して推移を追うことに意味があります。ファネル分析レポートや売上予測レポートを使えば、IS起点の商談数や受注額を継続的に観測できます。Mazrica SalesのようなSFA/CRMでは、設定不要で使える標準レポートが8種(売上予測・売上推移・売上実績・ファネル分析・アクション予測・アクション分析・アクション推移・フェーズ進捗)用意されています。
起点別の集計や独自の切り口で4指標を可視化したい場合は、カスタムレポートやダッシュボードを組みます。これらはGrowth以上のプランで利用できます。自社の指標定義に合わせて分母・分子を組み、月次で並べて見られる状態にしておくと、経営への報告がそのまま運用データから作れます。
パイプライン寄与レポートの作り方|経営にISの価値を証明する
測定した4指標は、経営が意思決定に使える1枚のレポートにまとめて初めて価値を持ちます。件数だけでなく金額(パイプライン創出額・受注額)を主役に置き、投下工数と対比して費用対効果で語ると、IS部門の増員や投資の判断材料になります。ここでは月次レポートに載せる項目、工数あたり貢献の出し方、差し戻し率を改善ストーリーに変える方法を示します。
月次レポートに載せる項目(テンプレート)
経営に見せるレポートは、多くの指標を詰め込むより、意思決定に効く項目に絞ります。月次で最低限そろえたいのは次の5項目です。
- IS引き渡しSQL数
- 有効商談化率
- IS起点パイプライン創出額
- IS起点受注額(コホートで確定した分)
- 各項目の前月比・目標比
この5項目を当月・前月・目標・達成率の列で並べると、活動量から金額貢献までが1枚で追えます。金額の行を目立たせ、件数指標は金額を裏づける補助として配置すると、経営の視線が売上貢献に向きます。
「工数あたりの貢献」で費用対効果を示す
金額の総額に加えて、投下した工数あたりの貢献を出すと、増員や投資の判断に直結します。
工数あたり受注額 = IS起点受注額 ÷ IS投下工数(顧客対応時間)
これで1人あたり、あるいは1時間あたりのIS起点受注額が算出できます。営業生産性は(商談数 × 受注率 × 単価)÷ 工数で表せますが、ISが効くのはこのうち商談数の創出と、引き渡し品質を通じた受注率です。
工数あたり受注額を示すと、ISが分子(受注額)をどれだけ効率的に生んでいるかを、分母(工数)とセットで経営に伝えられます。総額だけでは「人を増やせば増える当たり前の数字」に見えますが、工数あたりで語ると効率の証明になります。
差し戻し率の低減を改善ストーリーにする
レポートは成果の報告だけでなく、成長の証明にも使えます。差し戻し率(引き渡したSQLのうちFSに受理されなかった割合)の推移を載せ、SLA基準を調整した結果として有効商談化率が改善した経緯を語ると、単なる結果報告が改善の物語になります。
たとえば「引き継ぎ基準に決裁者接点の条件を追加した結果、差し戻し率が下がり、有効商談化率が改善した」という流れを数字で示せば、IS部門が自律的に品質を高めていることが伝わります。成果の絶対値だけを見せるより、改善のプロセスを見せるほうが、部門への信頼と投資につながります。
よくある失敗と点検の観点|寄与測定が機能しない典型パターン
寄与測定が回らなくなる原因は、「SQL定義がISとFSでズレている」「起点データが案件に入っていない」「単月で見て寄与を過小評価している」「差し戻しを放置している」の4つに集約されます。指標を定義しても運用が続かない組織は、たいていこのどれかでつまずいています。各パターンの回避策と、設計後に定期点検すべき観点を示します。
定義のズレ|有効商談化率が測れない
ISが渡す基準とFSが受理する基準が食い違っていると、有効商談化率の分子と分母が同じ土俵に乗らず、数字が意味を持ちません。回避策は、SLA基準を文書で合意し、四半期ごとに受注実績と突き合わせて見直すことです。市場や商材が変われば受注要因も変わるため、一度決めた基準を固定し続けないことが重要です。
起点データの欠落|寄与が分離できない
案件のソース入力が任意項目だと、現場は入力を後回しにして埋まりません。起点が入っていない案件が増えると、IS起点かどうかを分離できず、受注寄与率も受注額も計算できなくなります。
回避策は、案件作成時のソース入力を必須化し、誰がいつ何を入れるかの入力ルールを定めることです。ルールを決めたら、未入力案件の割合を定期的に確認します。
単月集計|リードタイム分の寄与を取りこぼす
単月で引き渡し数と受注数を割ると、リードタイムの分だけ寄与が過小に見え、「ISは受注に貢献していない」という誤った結論を招きます。回避策は、引き渡し月コホートでの集計に切り替えることです。自社の平均リードタイム以上の観察期間を取ってから受注寄与率を確定させます。
点検すべき項目(監査の観点)
指標を設計して運用に乗せた後は、測定が歪んでいないかを定期的に点検します。指標の作り方までで終わる記事が多いものの、運用の劣化を防ぐには監査の観点が欠かせません。点検すべきは次の項目です。
- 差し戻しSQLの発生源(特定のISや特定の獲得チャネルに偏っていないか)
- ソース未入力案件の割合(分離できない案件がどれだけ混ざっているか)
- SLA基準の陳腐化(直近の受注要因と引き継ぎ基準がズレていないか)
- 寄与率の異常値(急な上下がデータ入力の欠落や定義変更で起きていないか)
これらを月次または四半期で点検リストとして回すと、数字が経営を誤らせる前に修正できます。測定は作って終わりではなく、測定そのものの品質を保つ仕組みまで含めて設計します。
まとめ
IS部門の価値証明は、いま追っている数字の段階によって次の一歩が変わります。
SQL数しか追えていない組織は、まず有効商談化率、つまり渡したSQLのうちFSが受理した割合を1指標だけ測り始めてください。差し戻しの実態が見えるだけで、引き継ぎの質という新しい論点が立ち上がります。
有効商談化率は測れているが金額で語れていない組織は、IS起点パイプライン創出額をレポートに1行追加します。件数の話を金額の話に翻訳した瞬間、経営との対話が変わります。寄与が過小に見えて評価されていない組織は、引き渡し月コホートでSQL受注寄与率を追う運用に切り替えます。リードタイム分の取りこぼしがなくなり、実際の貢献が数字に表れます。
いずれの場合も、最初の一歩は「KPIツリーを全部書き出す」ような大きな作業ではなく、「有効商談化率を1つ測る」といった小さく具体的な着手から始めるのが続けるコツです。
3軸全体の設計はインサイドセールスのKPI設計と目標管理を参照してください。引き渡しの手前にあるアポ率や商談化率そのものを引き上げたい場合は、アポ率・商談化率の改善で率の改善手順を扱っています。
よくある質問
Q SQLとMQLはどちらの部門が定義を決めるべきですか?
営業とマーケティング、そしてISの三者が合意で決めるのが原則です。マーケが単独でMQLを、営業が単独でSQLを決めると、引き継ぎの境界で「これはまだ渡す段階ではない」「いや基準は満たしている」という衝突が起きます。定義は受け渡す双方が同じ絵を描ける状態で合意し、四半期ごとに受注実績と照らして更新します。
Q SQLの受注寄与を測るには何か月分のデータが必要ですか?
自社の平均リードタイム(案件発生日から受注までの期間)以上を1つのコホートとして見るのが目安です。たとえば平均リードタイムが3か月なら、ある月に引き渡したSQLの寄与は最低でも3か月後まで観察して確定させます。単月で区切ると、まだ受注が確定していない案件を分母に含めてしまい、寄与を実際より低く見積もることになります。
Q 有効商談化率の目標値はどのくらいに置けばよいですか?
業界一律の正解値はありません。まず直近の実績を基準線に置き、差し戻しの発生要因を1つずつ潰しながら、改善余地から目標を設定するのが現実的です。他社の数値をそのまま持ち込むより、自社の受注要因に合わせた引き継ぎ基準のもとで、前月比で改善しているかを見るほうが運用に役立ちます。
Q MAツールがあればSQLの寄与測定は自動化できますか?
MA(マーケティングオートメーション:商談化前のリード獲得・育成を担うツール)単体では、商談から受注までの下流が追えません。MAが得意とするのはリード獲得と育成、つまりSQLに至る手前までです。受注寄与を測るには、SFA/CRM側で案件に起点フラグを持たせ、フェーズ・確度・金額と紐づいて初めて、渡した先の受注まで追跡できます。MAとSFA/CRMが連携している前提で、下流のデータが揃うかを確認してください。
Q インサイドセールスとフィールドセールスで数字が食い違うときはどうすればよいですか?
まずSQLの引き継ぎ基準(SLA)と、案件の起点データの入力ルールを突き合わせます。数字がずれる典型は、ISが渡したと数えるSQLと、FSが受理したと数える商談の定義が違うケースです。あわせて差し戻しSQLの発生源を点検し、特定のチャネルや担当に偏りがないかを確認すると、食い違いの原因を具体的に特定できます。







