案件前進率とは？計算方法と営業改善での使い方

案件前進率の定義と計算方法

案件前進率は、あるステージにいた案件のうち、次のステージへ進んだ案件の割合です。基本式は「次ステージへ進んだ案件数 ÷ 対象ステージの案件数 × 100」です。たとえば提案ステージ20件のうち8件が合意形成へ進めば、案件前進率は40%です。

分母に新規流入だけを使うのか、期間開始時点の保有案件も含めるのかを固定します。チームごとに計算条件が違うと比較できないため、集計前に定義を一文で残します。

この記事で整理すること

受注率だけを見ても、どの営業プロセスに問題があるのかは分かりません。初回商談から提案へ進まないのか、提案から稟議へ進まないのか、稟議から契約へ進まないのかを分けて見ないと、改善施策は精神論になりやすくなります。この記事では、案件前進率を使って営業改善を見る方法を整理します。

背景

営業組織では、受注率、商談数、受注金額がよく見られます。これらは重要ですが、結果指標だけでは改善点が見えません。受注率が低いとき、課題はリード品質かもしれませんし、初回商談の見極めかもしれません。提案後フォローかもしれません。案件前進率は、どのステージで案件が止まっているかを見るための指標です。

よくある失敗

• 受注率だけで担当者やチャネルを評価している。
• ステージ定義が曖昧で、案件前進の意味が人によって違う。
• ステージ移動の条件が、営業が更新したか、になっている。
• 前進率を見ても、会議体や改善アクションにつながっていない。

実務での見直し方

まず、ステージごとの前進条件を決めます。初回商談から提案へ進む条件、提案から稟議へ進む条件、稟議から契約へ進む条件を、顧客側の判断や行動で定義します。次に、チャネル、担当者、商材、顧客規模ごとに前進率を見ます。数字を責めるためではなく、どこで支援や改善が必要かを見つけるために使います。

見落としやすいのは、前進率を担当者評価の数字としてだけ使うことです。前進率が低い背景には、ターゲット、資料、商談設計、価格、稟議支援、ステージ定義のどれかが影響します。数字を見た後に、どのプロセスを直すのかまで分けなければ改善にはつながりません。

現場で起きるサイン

このテーマで問題が起きている組織では、会議やSFA上に小さなサインが出ます。たとえば、受注率だけで担当者やチャネルを評価している状態が続くと、担当者は前に進んでいる感覚を持っていても、顧客側の判断は進んでいないことがあります。ステージ定義が曖昧で、案件前進の意味が人によって違う場合も、案件の見た目は整っていても、次の関係者や次の判断に進む材料が不足します。

案件前進率が役立つのは、受注率だけでは問題が見えない場面です。たとえば全体の受注率は同じでも、初回商談から提案へ進む率が落ちているなら質問設計やターゲット選定の問題かもしれません。提案から稟議へ進まないなら、資料や社内説明支援の問題かもしれません。

もう一つのサインは、会話が担当者個人の感覚に寄りすぎることです。温度感が高い、反応が良い、前向きそう、といった表現だけでは、営業組織として支援できません。実務で扱うには、誰が、何を、いつまでに、何のために判断するのかを記録する必要があります。記録できない情報は、商談中に確認できていない可能性があります。

チームで分担すること

この見直しは、営業担当者だけに任せると続きません。担当者は顧客との会話から事実を集め、マネージャーは案件レビューで不足している論点を確認します。営業企画やRevOpsは、SFA項目、会議アジェンダ、確認テンプレートを整えます。CSやプリセールスが関わるテーマでは、導入後や技術確認で必要になる情報を受注前の確認項目へ戻します。

分担を決めるときは、誰が入力するかだけでなく、誰がレビューするかまで決めます。入力欄を増やしても、レビューされなければ形だけになります。逆に、レビュー観点が明確であれば、営業担当者は何を確認すべきかを商談前から意識できます。運用の目的は管理を細かくすることではなく、顧客の判断を前に進めるための情報を欠かさないことです。

明日から使えるチェックリスト

• ステージごとの前進条件が顧客側の事実で定義されている。
• 初回商談、提案、稟議、契約の前進率を分けて見ている。
• チャネルや顧客規模別に詰まりを確認している。
• 前進率が悪いステージの改善アクションが決まっている。
• 案件レビューで前進条件の不足を確認している。

このチェックリストは、すべてを一度に完璧に埋めるためのものではありません。最初は、次の商談や次の会議で確認する項目を二つだけ選びます。たとえば、ステージごとの前進条件が顧客側の事実で定義されているかどうかを確認し、次に初回商談、提案、稟議、契約の前進率を分けて見ているかどうかを見ます。未確認の項目があれば、次回商談の質問、フォローメール、社内レビューのいずれかに戻します。

重要なのは、空欄を責めるのではなく、空欄を次の確認事項として扱うことです。商談は常に情報が揃った状態で進むわけではありません。だからこそ、何が分かっていて、何がまだ分かっていないのかを分ける必要があります。この分離ができると、案件レビューは報告ではなく支援の場になります。

運用に落とす方法

RevOpsは、まず現在のステージ定義を見直します。営業が更新しただけで前進扱いになっている場合は、顧客側の合意、次回アクション、稟議開始、契約確認などの事実を条件にします。ダッシュボードは複雑にせず、ステージ別の件数、前進率、滞留日数から始めます。会議では、前進率が低いステージごとに、質問設計、資料、フォロー、関係者確認のどれを改善するかを決めます。

月次レビューでは、受注率の増減を見た後に、どのステージの前進率が変わったのかを確認します。結果指標から一段戻ることで、精神論ではなく改善対象を選べます。

運用に落とすときは、既存の会議とSFAに接続します。新しいチェックシートを作っても、普段の案件レビューや1on1で見なければ定着しません。週次会議では、対象案件をすべて確認するのではなく、停滞している案件、次の判断者が不明な案件、未確認事項が多い案件に絞ります。限られた会議時間を、読み上げではなく次の打ち手に使います。

SFAでは、自由記述だけに頼らない方がよいです。自由記述は文脈を残すには便利ですが、集計や比較には向きません。最低限、確認済み、未確認、次回確認、対象外のように状態を分けられる項目を用意します。細かい項目を増やしすぎると入力されなくなるため、最初は営業が本当に判断に使う項目だけに絞ります。

見るべき指標またはレビュー観点

見るべき指標は、ステージ別前進率、ステージ滞留日数、後退理由、前進条件の未充足項目、次回アクション空欄率です。案件前進率は、営業を評価するためだけでなく、営業プロセスのどこに手を入れるべきかを判断するために使います。

指標を見るときは、単月の結果だけで判断しません。営業活動には案件のタイミング、顧客側の稟議時期、担当者の経験差が影響します。まずは30日単位で、入力品質、次回アクション、停滞理由、関係者確認、失注理由の具体性が改善しているかを見ます。数字が悪い場合も、すぐに担当者の能力問題にせず、プロセス、資料、会議、マネージャー支援のどこに詰まりがあるかを分けます。

最後に、改善した内容を標準化します。うまくいった質問、顧客が社内共有しやすかった資料、案件レビューで有効だった確認項目は、個人の工夫で終わらせず、テンプレートや会議アジェンダに戻します。営業組織の実務改善は、一度の施策ではなく、現場で見つけた良い型を繰り返し更新することで定着します。

公開前に確認すること

この記事のテーマを自社で扱うときは、最後に三つの観点で確認します。第一に、現場が明日から使える粒度になっているか。第二に、マネージャーやRevOpsがレビューできる記録として残るか。第三に、顧客の判断を助ける内容になっているかです。社内向けの管理項目だけを増やしても、顧客の検討が進まなければ営業実務としては不十分です。

最初にチームで確認する問いは、「どのステージの前進条件が一番曖昧か」です。条件が曖昧なステージほど、担当者ごとの判断差が数字に表れます。

また、記事の内容をそのまま全案件へ一律に適用しないことも重要です。新規商談、既存顧客、エンタープライズ、パートナー経由では、確認すべき相手やタイミングが変わります。まずは対象案件を絞り、運用してみて、会議で振り返る。そこで得た学びをチェックリストやSFA項目へ戻す。この小さな改善サイクルを前提にすると、営業組織に無理なく定着します。

関連して確認する実務ガイド

• Forecast会議の進め方: 前進率の変化を会議の支援判断へ使う
• 商談レビューシート: 停滞案件を15分で確認する

主な出典

• Salesforce: State of Sales Report

編集・監修について

この記事は営業実務ラボ編集部が企画、執筆、編集しています。制作過程で生成AIを構成案作成、草案整理、表現確認に利用する場合がありますが、公開前に編集部が事実関係、出典、表現を確認しています。外部専門家による個別監修が入る場合は、記事内で監修者名または監修有無を明記します。