商談フェーズは、自社が付けた管理上のラベルです。購買進捗は、顧客組織の中で条件がどこまで満たされたかという事実です。
この2つは別のものです。
- フェーズは、自社の活動（提案書を出した、見積を出した）で更新される
- 購買進捗は、顧客側の判断（技術審査が完了した、予算が計上された）でしか進まない
「提案中」というフェーズは、提案書を提出したことを意味します。顧客がその提案を評価したことも、承認プロセスが始まったことも意味しません。同じく確度Aは、担当者の手応えを表しています。顧客側で何が終わったかを表してはいません。
フェーズはラベルです。進捗には根拠が必要です。
本記事では、両者がズレる仕組みと、フェーズ定義に根拠を紐づける方法を整理します。
フェーズが示していること、示していないこと
| フェーズが示すもの | フェーズが示さないもの |
|---|---|
| 自社が何をしたか | 顧客組織で何が終わったか |
| 案件の管理上の区分 | どの部門が判断を下したか |
| 想定される受注時期の目安 | 未解決の条件がいくつ残っているか |
| 社内の報告単位 | 誰が承認するのかが特定できているか |
フェーズ自体に問題があるわけではありません。**自社の活動を管理する道具としては機能します。**問題は、それを顧客側の進捗の代わりに読むときに起きます。
なぜズレるのか
① 更新の契機が自社側にある
フェーズが進むのは、たいてい自社が何かを提出したときです。提案書を出せば「提案中」、見積を出せば「見積提示」。この設計では、顧客が何もしていなくてもフェーズは進みます。
② 確度が感触で決まる
確度やヨミの区分は、多くの組織で担当者の主観に基づいて付けられます。判断材料は「反応が良い」「前向きな発言があった」といった印象です。
印象は無価値ではありません。その場にいた担当者の観察には情報があります。ただし、印象と条件の充足は別の情報です。両方を確度という1つの値に押し込むと、どちらの情報も取り出せなくなります。
③ ステージが一本線である
顧客側の進捗は並行して進みます。使用部門は完了、情報システムは審査中、購買は未接触、経営は未起案。この4つの状態を1つのフェーズ値で表すことはできません。表そうとすると、最も進んでいる部門か、最後に接触した部門の状態が代表値になります。
従来のパイプライン管理と、購買進捗で見る管理
| 従来のパイプライン管理 | 購買進捗で見る管理（Sales Opportunity Intelligence） | |
|---|---|---|
| 管理の単位 | 案件ごとの1つのステージ値 | 条件ごとの充足状況 |
| 更新の契機 | 自社の活動 | 顧客側の判断の完了 |
| 進捗の根拠 | 担当者の入力 | 接点の記録に残った事実 |
| 表現できる状態 | 一本線上の位置 | 部門ごとに異なる状態 |
| 停滞の検知 | 更新日からの経過時間 | 未解決のまま残っている条件 |
| 確度の根拠 | 手応え・経験則 | 満たされた条件の数と種類 |
| 上長への説明 | フェーズと見込み時期 | どの条件が残っているか |
| 案件が動かないとき分かること | 動いていないこと | なぜ動かないか |
右側は左側を置き換えるものではありません。左側の下に、根拠の層を持つという関係です。フェーズは社内の共通言語として残しつつ、そのフェーズと言える根拠を別に保持します。
確度とヨミの精度が上がらない理由
確度の精度を上げようとする取り組みは、多くの場合「基準を厳格にする」方向に向かいます。A は80%以上、B は50%以上、といった定義です。
しかし、確率の数字を細かくしても、その数字を決めているのが手応えである限り精度は変わりません。変えるべきなのは、確度をどう定義するかではなく、何をもってその確度と言えるのかを条件で書けるようにすることです。
たとえば、次のように置き換えます。
| 従来の定義 | 条件ベースの定義 |
|---|---|
| 確度A：受注見込みが高い | 使用部門の評価完了、技術審査完了、予算計上済み、決裁者が特定済み |
| 確度B：前向きに検討中 | 使用部門の評価完了、技術審査が進行中、予算の裏付けは未確認 |
| 確度C：情報提供段階 | 接触している部門が1つのみ、条件が1つも確定していない |
右側は、自分で判定できます。判定した結果に確度のラベルを貼るなら、そのラベルには根拠があります。
この置き換えの副次的な効果として、案件ごとの比較ができるようになります。確度Aが2件あったとき、どちらが実際に固いかは手応えでは比較できません。満たされた条件で見れば比較できます。
例：「提案中」のまま止まっている案件
※ 以下は考え方を示すための仮想例です。実在の顧客事例ではありません。
案件：学校法人への基幹システム導入。SFA 上のフェーズは「提案中」、確度は B。最終更新から5週間。
フェーズが示していること 提案書を提出済み。担当者との定期的な接触あり。
購買進捗の実態
| 条件 | 状態 |
|---|---|
| 利用部門（事務局）の業務適合評価 | 完了 |
| 情報システム部門の技術審査 | 未完了（既存システムとの連携方式が未確定） |
| 学内ネットワーク・セキュリティ基準への適合 | 未着手（担当者が未特定） |
| 予算措置 | 次年度予算での扱いが未確認 |
| 決裁 | 決裁者が未特定 |
5つの条件のうち、満たされているのは1つです。フェーズ上の「提案中」も、確度Bも、この内訳を表していません。
この案件で起きていること 情報システム部門の技術審査が完了しないと、後続の条件が動きません。担当者との接触は継続しているため、SFA 上は活動が記録され続けます。活動量は十分に見え、フェーズも確度も動かないまま、時間だけが経過します。
フェーズ管理だけで見た場合の判断 「5週間動きがない。そろそろ確度を下げるか、値引きを検討するか」
条件で見た場合の判断 「5条件中1つのみ充足。律速は技術審査。確認項目と所要期間が合意されていないため、まずそこを確定させる」
同じ案件でも、見る単位が違えば次の行動が変わります。何が案件を止めているかの切り分けは ++商談が進まない理由の見つけ方++ で詳しく扱っています。
フェーズを廃止せず、根拠を持たせる
現実的には、SFA のフェーズ運用を個人の判断で変えることはできません。組織の管理単位として機能しているためです。
実務的な解は、フェーズを残したまま、その下に条件の層を持つことです。
手順
1. フェーズごとに「そう言える根拠」を定義する
| フェーズ | このフェーズと言える根拠 |
|---|---|
| 提案中 | 提案書を提出し、利用部門から内容への反応を得ている |
| 技術確認中 | 技術審査の担当者が特定され、確認項目が共有されている |
| 最終調整 | 技術・予算の条件が充足し、決裁者が特定されている |
| 内示・受注前 | 社内承認が起案され、条件交渉が合意に至っている |
2. 根拠が揃っていないフェーズには進めない
提案書を出しただけでは「提案中」に留め、反応が確認できるまで次に進めません。フェーズが進みにくくなりますが、進んだフェーズの意味が正確になります。
3. 未充足の条件を案件ごとに持つ
フェーズは1つの値ですが、条件は複数持てます。条件の書き方は ++意思決定単位で案件を捉える方法++ を参照してください。
上長への報告が変わる
条件で管理する実務上の効果は、報告の質に現れます。
フェーズだけで報告する場合
「A社は提案中です。感触は悪くありません。来月には動くと思います。」
この報告に対して上長ができる質問は「本当か」「いつ決まるのか」しかありません。答えは推測になります。
条件で報告する場合
「A社は5条件中1つ充足。律速は情報システムの技術審査で、確認項目は共有済み、回答期限は未合意です。今週中に期限を合意します。」
この報告には、検証できる事実と、次の行動と、その期限が含まれています。上長の側も、どこを支援すべきかが判断できます。
報告のために管理するのではありません。説明できる状態は、自分が状況を把握している状態と同じものです。
フェーズの裏側にある文脈を保持する ― VINEQRA の考え方
VINEQRA は、複数の関係者が関わる長期案件を担当する営業担当者個人のために設計された iOS 向けの AI CRM です。
従来の CRM は、多くの場合記録のシステムとして機能します。何が起きたか、どの活動が登録されたか、案件がどのステージにあるか。これは組織の管理に必要な機能です。
VINEQRA が加えようとしているのは、その上にある推論の層です。
| 記録のシステムが答えること | VINEQRA が答えようとすること |
|---|---|
| 何が起きたか | 蓄積された文脈は何を示しているか |
| どのステージにあるか | どの条件が未解決のまま残っているか |
| 誰と接触したか | どの関係者や判断が次に必要か |
| 最後の活動はいつか | 次に何を検討すべきか |
商談の文脈は次の構造で捉えます。
顧客接点 ＋ 関係者 ＋ 意思決定ポイント ＋ 阻害要因 → 次に取るべき行動（Next Best Action）
（VINEQRA Opportunity Context Model）
対応する AI 分析は、Apple Foundation Models を通じて端末内のシステム言語モデルで実行できます。
そして、前提となる原則があります。
VINEQRA は提案します。判断するのは営業担当者です。
なお、既存の CRM にステージや関係者の管理機能がないという意味ではありません。多くの製品が備えています。違いは、個人の営業担当者が、自分の担当案件の文脈を推論に使える形で持てるかどうかです。
よくある質問
Q. フェーズ管理はやめるべきですか？ やめる必要はありません。組織の管理単位として機能します。必要なのは、フェーズを購買進捗の代わりに読まないことと、フェーズごとに「そう言える根拠」を定義することです。
Q. 確度は何%と答えるべきですか？ 数字を精緻にするより、その数字の根拠を条件で言えるようにする方が効果があります。「70%です」より「5条件中3つ充足、残りは予算と決裁」の方が、自分にも上長にも使える情報です。
Q. 顧客側の条件は、どこまで把握できるものですか？ すべては把握できません。把握できていない部分を「不明」として持つことに意味があります。不明が多い案件は、進んでいないのではなく見えていない案件で、必要な行動は提案ではなく確認です。
Q. フェーズが進まないと社内で評価されにくいのですが。 短期的にはその通りです。ただし、根拠のないフェーズ更新は、失注時に説明できない案件を作ります。条件で管理していれば、進まなかった理由を事実として説明できます。
Q. 受注予測の精度は上がりますか？ 条件ベースの管理は、予測を保証するものではありません。顧客側の事情は外部要因で変わります。改善が見込めるのは、予測が外れたときに理由を特定できることです。
ラベルではなく、根拠で案件を見る
フェーズも確度も、自社の管理のために存在します。それ自体は必要なものです。問題は、それが顧客側で何が起きているかを表していないことに気づかないまま使うことです。
フェーズはラベルです。進捗には根拠が必要です。
VINEQRA は、記録された顧客接点を関係者・意思決定ポイントと結びつけ、どの条件が未解決のまま残っているかを手がかりとして提示します。
フェーズの裏にある実際の状況を見る。 → VINEQRAをApp Storeでダウンロード