商談停滞の理由コード設計｜滞留日数から次回行動と失注判断へつなぐ

案件一覧に「提案中」が並んでも、相手の決裁待ちと自社の見積待ちでは打ち手が違う。商談段階は進捗の位置、停滞理由コードはその位置から動かない原因を表す。二つを混ぜないことが出発点だ。

最小の案件項目はスプレッドシートの案件管理表、営業結果を指標へつなぐ方法は営業報告をKPIへ変える方法、人数別の案件管理設計は営業チームの案件管理設計が扱う。この記事は滞留中の案件を次回行動または失注判断へ進める運用に絞る。

滞留日数は段階に入った日から数える

最終更新日では、メモを追加するだけで停滞が解消したように見える。段階へ入った日時を保持し、現在日との差をdays-in-stageとして見る。段階を戻した場合も履歴を消さない。

理由コードは行動が変わる粒度にする

相手条件待ち
予算、決裁、時期、要件など相手側の条件が未確定
自社対応待ち
見積、提案、確認、体制回答が未完了
競合・比較中
比較対象と判断予定日が分かっている
優先度低下
課題はあるが他案件が優先されている
連絡不能
合意日を過ぎ、次回接触条件も確認できない

「検討中」「その他」だけでは次が決まらない。一方、顧客ごとの事情をすべてコードにすると選べない。主理由は集計可能な少数にし、相手が示した条件、根拠となる発言、確認日を補足する。

次回行動には相手の条件も置く

自社の「電話する」だけでなく、誰が、誰に、何を確認し、いつまでに、何が分かれば段階を進めるかを書く。相手の予算確定日や会議日が分かるなら、その前の催促を増やさず、合意した日を基準にする。

SalesforceはSales InsightsのStage Progressionで、案件段階の進行や各段階で費やした時間を確認する考え方を案内している（Salesforce Help「Stage Progression」）。機能を導入する前でも、段階変更日と滞留理由を同じ案件に残せば運用できる。

失注判定を担当者の気分にしない

顧客が見送りを明示した
案件期限を過ぎ、再開条件がない
合意した確認を重ねても相手条件を確認できない
自社が必須条件を満たせない
責任者が保留継続より終了を承認した

閉じた案件には主な失注理由、判断日、判断者、再開条件を残す。将来見込みという理由で無期限にパイプラインへ残さない。

来週できる一歩：一段階だけ監査する

案件数が多い一つの段階を選ぶ。
段階へ入った日と滞留日数を出す。
古い案件に主理由と相手条件を付ける。
次回行動、期限、責任者を置く。
週次会議で進行、保留、失注のどれかを決める。

営業を含む業務改善の関連記事は業務改善カテゴリで確認できる。

よくある質問

商談停滞は何日で判定しますか？

全案件を同じ日数にしません。商談段階ごとの通常所要日数を実績から確認し、基準を超えたら理由と次回行動を必須にします。長期検討が通常の案件は相手と合意した次回日を優先します。

停滞理由は自由記述ではだめですか？

自由記述だけでは集計できません。主理由を少数のコードから選び、相手の発言や条件は補足欄へ残します。該当なしが増えた時だけコードを見直します。

返信がない案件はすぐ失注にしますか？

無返信だけで自動失注にしません。合意した次回日、連絡回数、案件期限、相手側の状況を確認し、自社の失注基準と責任者の判断で閉じます。再開条件と見直し日も残します。