営業・商談管理

商談が「検討中」に溜まるときは、社内合意をステージとして切り出す

用語

CRM（顧客管理システム）

公開 2026年7月21日更新 2026年10月17日

パイプラインを見ると、案件の多くが「提案中」や「検討中」に溜まっている。営業に聞くと「先方待ちです」と返ってくる。

ステージを顧客の状態で定義し直す、という答え自体は新しくありません。

それでも直らない会社が多いのは、定義を書き換えたあとも、担当者が納得してから会社が決めるまでの区間が1つのステージに押し込まれたままだからです。日本のB2Bで案件が止まるのは、たいていここです。

この記事は、その区間を切り出す話と、切り出した定義を稼働中のパイプラインに入れるときの順番の話です。

「見積提出済み」の中で、相手の社内は何工程も進んでいる

多くの組織は、商談ステージを営業の行動で定義しています。「初回訪問済み」「提案書提出済み」「見積提出済み」。

この定義は、顧客側で何が起きているかを語りません。

見積を出したあと、相手の社内では比較、上長への説明、稟議と、複数の工程が進みます。営業の行動で切ったステージでは、これが全部「見積提出済み（先方検討中）」の一括りになり、止まっているのか進んでいるのか判別できません。

日本ではこの区間が長くなります。

IDEATECHと北川裕康氏の共同調査（2026年4月公表、n=307。年間契約額または一括導入費300万円以上の商材に2名以上で関与した回答者に限った調査PRで、大型・複数名関与の案件に偏る点に注意）では、発注までの承認が2段階以上の企業が8割を超え、検討開始から発注先決定までが3〜8か月の企業が63.6%でした。

同じ調査には、営業と本格的にやり取りが始まった時点で購買プロセスが平均約40%進んでいる、という数字もあります。

ただ、この4割は商談が作られる前の話です。商談ステージの定義をどう変えても、ここは映りません。映すなら、リードのライフサイクルの側で扱います。

ステージの定義で取り戻せるのは、商談が作られたあと、とくに担当者の納得から会社の決定までの区間です。

どこから商談ステージにするかを、先に決める

顧客の状態でステージを書こうとすると、「認知した」「課題を言語化した」まで並べたくなります。それらは商談が作られる前の状態で、商談パイプラインに入れると、何をもって商談を作るのかの基準が崩れます。

リードの状態と案件の進行を分ける理由はライフサイクルステージと取引ステージの違い、混同した結果に書きました。

商談ステージの入口は、「相手が、自社を候補の1社として検討すると言った」のように、商談を作る条件と同じ一文にします。そこから先を、顧客側で終わったことで区切ります。

完了条件は、顧客側の事実と、その確かめ方を対にする

各ステージの完了条件を、「提案済み」ではなく顧客側の事実で書きます。たとえば「顧客が候補を絞り、自社が最終候補に残っている」。

ただし、この条件をそのまま置くと、結局は営業の申告になります。売り手からは、相手が候補を絞ったかどうかを直接は見られないからです。

そこで条件ごとに、何を見たら完了とするかを添えます。

候補を絞った：相手から「残りは御社を含めて2社」などの発言があった。または、比較のための資料や条件の確認を求められた
社内に上げ始めた：稟議や社内説明に使う資料を求められた。決裁者の名前と、次の会議の日付が分かっている
決裁が下りた：発注の意思が書面かメールで届いた

確かめ方を添えると、ステージを進めるたびに営業が何を聞けばよいかも決まります。完了条件を初回商談のヒアリング項目にまで落とさないと、判定できないステージが残ります。

社内合意を独立した1段にし、止まった場所は別の欄で持つ

担当者の納得と会社の決定の間には、稟議という工程が挟まります。ここを「社内合意形成中」という独立した1段にします。

入る条件は「担当者が社内に上げると言い、そのための資料を求められた」、出る条件は「決裁が下りた」です。

この1段の中を、さらに「課長承認」「部長承認」と細かいステージに割る必要はありません。承認の段数は会社ごとに違い、全社共通のステージにすると、どの案件にも当てはまらない段が生まれます。

止まっている場所は、ステージとは別に「決裁の進捗」の欄で持ちます。現場が賛成、部長が承認、役員が承認、決裁完了。

この欄を予測にどう使うかは確度90%でも、決裁が止まっている商談はコミットに入れないに書いています。

このステージで止まったまま失注になった案件は、失注理由でも「社内承認で止まった」を選べるようにしておきます。

ステージ、決裁の欄、失注理由の3つが同じ区間を指していれば、「検討中」の中身が月をまたいで追えます。

失注理由の側の作り方は失注理由が毎月「価格」で埋まるのは、選択肢の設計の問題ですにあります。

進行中の案件を付け直す前に、止めるものと記録するもの

定義を変えたら、進行中の案件を新しいステージに付け直します。終了済みの案件は触りません。

ただ、稼働中のパイプラインで一括の付け直しをそのまま走らせると、2つのものが壊れます。

1つ目は自動化です。

ステージの変更をきっかけに動くワークフロー、通知、タスクの作成が、付け直した件数分、一斉に走ります。営業に「見積フォロー」のタスクが何十件も届く、顧客にステップメールが飛ぶ、ということが起きます。

2つ目は滞留日数のレポートです。

ステージに入った日を自動で記録するCRM（顧客管理システム）では、付け直した日が全件の「入った日」になります。翌月の「このステージに何日いるか」は、全件が付け直し日から数え直され、意味を持たなくなります。

付け直しは、次の順番で行います。

ステージの変更を起動条件にしている自動化を洗い出し、付け直しの間だけ止める。 止めたものは一覧に残し、終わったら1本ずつ戻す。
旧ステージと新ステージの対応表を作る。 あわせて、ステージごとの確度（勝率の重み）と、予測の区分（見込み、確約など）を新しいステージに対応させる。旧ステージの確度をそのまま引き継ぐと、予測の数字が付け直した日に跳ねます。
付け直す前に、各案件の旧ステージと、そのステージに入った日を書き出しておく。 書き出した値を残す項目を別に作るか、CSVで保存する。
移行日を記録し、レポートに注記する。 滞留日数は、移行日より前に入った案件を移行日から数えていることを、レポートの説明欄に書く。移行日をまたぐ比較はしない、と決めておく。
数件で試してから、残りを付け直す。 自動化が止まっているか、確度と予測の区分が対応表どおりに入るかを確かめてから全件に広げる。

ステージに入った日の記録のされ方、変更履歴の残り方、一括更新で自動化が動くかどうかは、ツールと設定によって違います。自社の環境で、上の5の試しで確かめてください。

よくあるつまずき

ステージを増やしすぎる。 承認の段をステージにすると、7段、8段と増え、営業が選ぶのに迷います。承認の段は別の欄に逃がします。
定義を変えただけで運用を変えない。 完了条件の確かめ方を、商談のヒアリング項目に入れないと、判定できないステージが残ります。
過去の案件まで付け直す。 終了済みの案件は旧定義のまま残し、移行日で区切って読むほうが、数字の連続性を保てます。

商談ステージは、営業が何をしたかではなく、顧客側で何が終わったかで定義します。担当者の納得と会社の決定の間にある社内合意は独立した1段にし、どこで止まっているかは別の欄で持ちます。

今週、「検討中」に入っている案件を10件開き、相手の社内で今どの承認を待っているかを書き出してみてください。書けない案件が、この1段を切り出す理由です。

パイプラインを営業の行動ではなく相手の意思決定で組み立てる考え方は、レベニューアーキテクチャとはにまとめています。