「この案件は提案中です」と報告されても、見積を作成している段階なのか、提出して返事を待っているのか、顧客が比較検討しているのかは分かりません。

担当者によってステージの付け方が違うと、一覧を見ても状況が伝わらず、会議のたびに経緯を聞き直すことになります。見込金額や受注予定を確認するときにも、同じ段階の案件を比べにくくなります。

案件ステージをそろえるには、名称だけでなく、その段階に入る条件、次へ進める条件、判断の根拠、次の行動を決めることが大切です。本記事では、定義表、更新の記録例、停滞の見方、受注確度との区別、運用を始める手順を紹介します。

案件ステージの基準が、人によって違うのはなぜか

「何をしたか」と「どこまで進んだか」が混ざっている

見積を作成したことと、顧客がその見積を受け取り、内容を評価していることは別です。電話をかけたことも、次の判断時期を確認できたこととは異なります。

作業の実施は活動履歴やタスクに残し、ステージは定義した条件に基づいて更新します。営業側の作業を基準にする段階があっても構いませんが、「提出済み」と「顧客評価中」など、何を表す名称かを明確にしましょう。

入る条件はあっても、次へ進む条件がない

「一度会ったら商談」「見積を出したら提案」と決めても、その後に何を確認すれば次へ進めるかが曖昧だと、担当者の感覚で段階が変わります。

目的、確認事項、根拠、完了の目安を一緒に定義します。次へ進めない場合も、不足している情報が分かれば、上長や技術担当へ支援を依頼しやすくなります。

集計や会議のためだけに、段階を動かしている

見込をよく見せるために先へ進めたり、長く止まっている表示を消すために戻したりすると、履歴から実際の進み方を読み取りにくくなります。

ステージの変更は、確認できた内容の変化に合わせます。期待や目標は別の欄で扱い、進んだ・戻った理由を残す運用にしましょう。

案件ステージと受注確度は、別の意味で管理する

ステージは進み具合、確度は見込みの評価

同じ「提案・評価中」でも、予算と判断日程が分かる案件と、どちらも未確認の案件では、見込みを評価する材料が違います。ステージが同じだから、必ず同じ確度になるとは限りません。

自動で初期値を入れる場合も、値の意味をそろえる

ステージに応じて確度の初期値を設定する運用なら、何を根拠にした値か、個別の状況をどう反映するかを決めます。入力済みの確度を、実際の受注確率が検証された数値とは扱わないようにします。

確度を使って加重見込を計算するときも、対象案件、金額、予定時期を確認します。ステージを進めたことだけで、売上や受注実績が増えたわけではありません。

案件ステージは、入る条件と次へ進める条件を定義する

商材に合う段階を、必要な数に絞る

ステージの数や名称に共通の正解はありません。見積を出してから決まるまでが短い取引と、技術評価・稟議・調達の確認が続く取引では、分けたい段階が違います。

まずは自社の代表的な案件を見て、次に確認することや必要な支援が変わるところで区切ります。細かな訪問や資料作成の作業を、すべてステージにしないことも大切です。

表は説明用の一例で、CRMの初期ステージや自動判定を示すものではありません。例えば「提出済み」と「評価中」を分ける会社なら、それぞれの条件を定めて使います。受注とする条件も、自社の受注処理に合わせて確認してください。

必須項目だけでなく、内容を確認する根拠を決める

「予算欄に文字がある」「文書が添付されている」だけでは、内容が確認済みかは分かりません。確認相手、日時、メールや商談記録の参照先を残し、判断する人が根拠をたどれるようにします。

分からないことは未確認として残し、何を確かめれば進めるかを明確にします。必須欄を埋めるために、仮の値を事実として登録しないようにしましょう。

ステージを進める・戻すときの運用例

変更理由と次の対応を、同じタイミングで残す

この例では、評価結果と判断手順が確認できたため、条件を詰める段階へ進めています。主要条件を合意していないので、発注手続きの段階へは進めていません。会社・日付・内容は説明用です。

前の段階へ戻るときも、変わった条件を残す

提案後に必須の仕様が変わった、対象範囲を組み直す必要が出たなどの場合は、前の段階へ戻ることもあります。戻す前後のステージ、変更された条件、再確認することを残します。

既存の活動履歴や見積を消す必要はありません。どの版から何が変わったかをたどれるようにし、段階を戻しただけで過去の滞留もなかったことにしないようにします。

保留・終了・再開の扱いも、最初に決める

顧客の会議待ちと、予算が立たず再検討時期も未定の案件では、確認することが違います。保留理由、待つ相手、再確認する条件や時期を残します。

保留を専用の状態にするか、ステージを維持して別の欄で管理するかは、自社の運用に合わせます。受注見込の集計に含める条件も決めてください。終了後の再開では、元案件を再開するか新しい案件に分けるか、過去の実績や履歴への影響を確認します。

停滞は、滞留日数・顧客の動き・次回対応を分けて確認する

「更新されていない」と「進んでいない」は同じではない

ステージごとに、確認する目安を置く

課題を確認する段階と、顧客の稟議や調達を待つ段階では、必要な時間が違います。すべてを同じ日数で停滞扱いにせず、商材や段階に合わせた確認の目安を置きます。

日数の超過は、事情を確認するきっかけです。顧客と合意した判断日が先にあり、次の確認予定も明確な案件まで、進んでいないと断定する必要はありません。一方、日数が短くても、約束した資料が未送付なら対応が必要です。

待つ理由があっても、次に確認する人と時点を残す

「先方の会議待ち」だけで止めず、予定している会議、共有する資料、会議後に確認する人と時期を残します。予定が未確定なら、日程を確認する仕事を登録します。

停滞の確認で決めるのは、単にステージを動かすことではありません。顧客への確認、社内の支援、提案の組み直し、保留・終了の判断のうち、今必要な対応を選びます。

ステージ変更の履歴から、戻りと滞留を読み取る

今回の経過日数と、同じ段階の累計を区別する

次は、課題確認から提案へ進んだ後、追加条件が見つかり課題確認へ戻った架空例です。同じ時刻の差を日数にしたもので、営業日数ではありません。

今回の課題確認の滞留は2日ですが、この案件で課題確認にいた時間の累計は3日＋2日＝5日です。全区間では11日になります。日々の対応では現在の区間、振り返りでは戻った理由や累計も見ると、確認する論点が変わります。

計測していない過去を、正確な履歴として埋めない

現在のステージしか残っていない場合、いつその段階へ入ったかは分からないことがあります。案件の作成日や最終更新日を、根拠なくステージ開始日へ置き換えないようにします。

観測を始めた日からの情報と、実際の変更履歴が残る期間を分けます。比較するときは、計測が一部の案件、不明な区間、途中から登録した案件をどう扱うかも明記しましょう。

営業会議では、ステージの説明から次の支援へつなぐ

会議前に、根拠と未決事項を更新する

会議で全件の経緯を読み上げるより、現在の段階、直近の確認、未決事項、次回対応を事前に更新します。管理者は、予定超過、次回未設定、条件が変わった案件等へ絞って確認できます。

• その段階にいる根拠：誰と、いつ、何を確認できたか。
• 次へ進むための不足：判断者、予算、仕様、条件、日程等で何が残るか。
• 必要な支援：上長、技術、事務等へ何を依頼するか。
• 次の仕事：誰が、何を、いつまでに行うか。
• 見込みの見直し：確度、予定日、金額の前提に変化がないか。

ステージを戻すことも、状況が分かった結果として扱う

前提が変わったのに段階を維持すると、必要な確認が一覧に出てきません。戻る理由を残し、何を支援すればよいかを話せる運用にします。

また、長く滞留した案件の件数だけで担当者を評価せず、商材、顧客の判断日程、支援の依頼、活動の内容を確認します。集計と個別の事情を照らし合わせることが大切です。

案件ステージの定義をそろえる、5つの手順

1. 実際の案件を集める：受注・失注・進行中から、代表的な事例を選ぶ。
2. 同じ記録で判定する：複数の担当者が段階を判断し、意見が分かれた条件を確認する。
3. 定義を文書にする：入る条件、進める条件、根拠、次の確認をまとめる。
4. 一つのチームで試す：更新の負担、判断に迷う場面、例外を確認して調整する。
5. 運用の責任者を決める：定義の変更、説明、設定、定期的な見直しを担当する人を決める。

過去データと、定義を変えた後のデータを分けて見る

名称を変えただけでも、旧ステージとの対応が曖昧だと、前月や前年との比較が難しくなります。定義の変更日、旧名称との対応、既存案件を見直す範囲を残します。

商材ごとに別のプロセスが必要なら、管理方法と集計条件を確認します。すべてを一つの細かな段階に詰め込まず、必要な共通部分と個別の確認事項を整理しましょう。

運用開始前の10項目チェックリスト

vtplusで、進行の基準と案件の履歴をつなぐ

案件進行ガイドで、今の段階の確認項目をそろえる

「IPDealGuide」は、営業ステージに合わせて目的、完了の目安、不足する登録情報、次の操作を示します。登録の有無を確認するもので、顧客の合意や入力内容の品質を保証する判定ではありません。確認率も受注確率とは異なります。

自社の基準とステージの対応を設定して使います。本記事の定義表がそのまま初期設定されるわけではありません。案件進行ガイドの紹介ページで対応範囲を確認できます。

ステージ管理で、変更履歴と滞留を確認する

「IPStageAdvisor」は、ステージ変更の履歴と区間の日数を記録し、設定に応じて画面内の注意表示や活動の提案を行います。既存案件は観測開始からの記録となり、導入前の履歴を復元するものではありません。詳しくは案件ステージ・滞留管理をご覧ください。

カンバンの表示と、滞留の計測基準を区別する

「IPOpportunityKanban」では、標準の案件をステージ別に表示・更新できます。カンバンの停滞表示は案件の最終更新日時が基準で、ステージに入ってからの日数とは別です。案件カンバンの紹介ページで表示・操作条件を確認できます。

必要な基準を先に整理し、どの機能で何を確認するかを決めることで、表示された数値や注意を営業の判断へつなげやすくなります。

案件ステージの定義・運用でよくある質問

見積を送ったら、次のステージへ進めてよいですか？

自社の定義によります。「提出済み」を表す段階なら送付の事実を残します。「顧客が評価中」を表すなら、受領や確認先等の条件も確かめます。見積を作成しただけなのか、提出・確認まで進んだのかを区別しましょう。

同じステージなら、確度も同じにした方がよいですか？

共通の初期値を使う方法はありますが、確度の意味と個別評価の方法を決めます。予算、判断日程、競合、未決事項等の情報が違うため、段階が同じことだけで受注確率が同じとは判断しません。

長く同じ段階にいる案件は、失注にすべきですか？

日数だけでは判断できません。顧客の判断予定、次の対応、未解決事項を確認します。保留や終了とする場合も、理由と再確認の条件を残し、自社の基準に沿って判断します。

CRMを入れれば、ステージの判定も自動でそろいますか？

登録された情報を確認する機能があっても、条件の意味を決め、顧客の状況や根拠を確認する運用は必要です。ガイドや入力チェックと、営業上の判断を分けて考えます。

まとめ：案件の現在地を、根拠と次の行動でそろえる

案件ステージの基準をそろえるには、名称、入る条件、進める条件、根拠を一緒に定義します。受注確度や予定日、次回対応は別の情報として確認し、停滞の数字も何を測っているかを明確にしましょう。

まずは同じ案件を複数の担当者で見て、どの段階と判断するかを確認してみてください。意見が分かれる箇所を定義に加えると、実際の業務で使える基準へ整えられます。