商談フェーズ定義と進捗基準｜初回訪問から受注までの段階で進捗を可視化する

「提案中」のまま3週間動かない案件があり、担当者に状況を聞くと「まだ検討中です」としか返ってこない。フェーズを更新するタイミングも人によってバラバラで、パイプライン全体の数字を見ても、どこまで本当に進んでいるのか確信が持てない。こうした状態の根っこには、商談フェーズの解釈が担当者ごとに違い、進捗の判断が属人化している問題があります。

この記事では、案件の進捗を客観的に可視化するために欠かせない2つの設計、「商談フェーズの定義」と「各段階の進捗基準（次に進むための移行条件）」を、セットで組み立てる方法を解説します。フェーズをどう区切り、各段階に何を満たしたら次へ進めるのかを明文化する具体的な手順まで扱います。

パイプライン全体の設計・運用の体系的な全体像はパイプライン管理の手法と実践を参照してください。本記事はそのなかの「フェーズ定義と進捗基準」に絞って深掘りします。

商談フェーズとは何か

商談フェーズとは、案件が受注に至るまでの進行状況を「初回訪問」「提案」「クロージング」のように段階で区切ったものです。パイプライン上で案件がいまどこにいるかを示す座標であり、進捗を共通言語で語るための土台になります。

設計で最も大事なのは、フェーズを「営業担当の行動」ではなく「顧客の状態・案件が到達した状態」で定義することです。ここを外すと、後で決める進捗基準がすべて主観的になり、パイプラインの数字が信用されなくなります。

本記事では受注までの一連の活動全体を「案件」、その進行段階を「商談フェーズ」または「フェーズ」と呼びます。個別の交渉・提案を指すときは「商談」を使いますが、進行段階を語る場面ではフェーズに統一します。

フェーズ・受注確度・ネクストアクションの違い

フェーズの設計に入る前に、混同しやすい3つの言葉を区別しておきます。この3つを取り違えると、フェーズの中に確度の話やアクションの話が混ざり込み、定義が崩れます。

• フェーズ 案件がどこまで進んだか（段階）。例：提案フェーズ
• 受注確度 どれだけ受注に近いか（％やヨミ）。例：確度70％
• ネクストアクション 次に何をするか（具体的な行動）。例：来週、意思決定者へ最終見積を提示

フェーズが進めば確度も上がる関係にありますが、両者は同じものではありません。同じ提案フェーズでも、競合が優勢な案件と自社が本命の案件では確度が違います。

受注確度をどう数値化・スコアリングするかは設計の別テーマなので、詳しくは受注確度のスコアリングを参照してください。本記事はフェーズそのものの定義と移行条件に集中します。

なぜ「状態」で定義するのか

フェーズを行動で切ると、進捗の水増しが起きます。「初回訪問した」を初回訪問フェーズの条件にすると、訪問しただけで案件が一歩も前進していないのにフェーズが進んだように見えてしまいます。訪問後にキーマンの興味が薄いと分かっても、パイプライン上は「初回訪問済み」として前向きにカウントされ続けます。

対して「顧客が課題を認識し、次回の提案の場を約束した」という状態で切ると、フェーズの進行がそのまま案件の前進を意味します。行動は自社側の都合で発生しますが、状態は顧客側の反応に基づくため、より客観的です。フェーズは「自分が何をやったか」ではなく「顧客と案件がどこまで来たか」で定義する、この原則が進捗可視化の出発点になります。

初回訪問から受注までのフェーズ設計例

標準的なフェーズの並びは、アポイント獲得から始まり、初回訪問・ヒアリング、提案、クロージング、受注へと進みます。この流れに沿って、各段階を「顧客がどんな状態に到達したか」で定義していくと、誰が見ても解釈が揺れないフェーズになります。

ただし段階数は固定ではありません。低単価で検討が単純な商材ほど段階は少なく、高単価で関与者が多く検討が長い商材ほど段階を増やして進捗を細かく追う必要があります。ここでは標準的な並びと各段階の状態定義、そして細分化しすぎの弊害まで見ていきます。

標準的なフェーズの並びと各段階の状態定義

各フェーズを「フェーズ名：到達した顧客の状態」の形で定義した例です。行動ではなく状態で書いている点に注目してください。

• アポイント獲得 商談日程が確定した状態
• 初回訪問／ヒアリング 顧客の課題・予算・意思決定体制の一次情報を取得した状態
• 提案 意思決定者に対して提案内容を提示した状態
• クロージング 見積提出・条件交渉に入り、意思決定者が導入を前向きに検討している状態
• 受注 契約・発注が確定した状態

この定義があると、担当者が「提案フェーズです」と言ったとき、それを「意思決定者に提案を提示済み」という同じ意味で全員に持たせられます。マネージャーが個別に状況を聞き直さなくても、フェーズ名だけで案件の到達点が伝わる状態が理想です。

フェーズ数は何段階が適切か

段階が多いほど精密に管理できるわけではありません。フェーズを増やすほど1件あたりの更新箇所と判断が増え、現場の入力負荷が上がります。負荷が上がると更新が後回しになり、結局フェーズが実態を反映しなくなって形骸化します。

判断軸は商材の検討期間と関与者数です。検討が短く関与者が少ない単純な商材なら、アポイント獲得から受注まで4〜5段階で十分です。検討が数か月に及び、担当者・決裁者・情報システム部門など複数の関与者が絡む複雑な商材なら、6〜8段階に分けて各局面の進捗を追う価値があります。迷ったら少ない段階から始め、運用しながら足りない粒度を足していくほうが定着します。

失注・保留の扱い

前進していくフェーズだけを設計して満足すると、実務でつまずきます。案件は必ずしも前に進むとは限らず、失注したり、先方の都合で長期保留になったりするからです。前進フェーズだけしかないと、動かなくなった案件が「提案フェーズ」のまま居座り、パイプラインの金額を水増しし続けます。

そこで、前進フェーズとは別に「失注」と「保留（ペンディング）」の状態も定義しておきます。失注は必ず失注理由をセットで記録する前提で設計します。理由なく失注に落とすだけでは、後から敗因を振り返れません。

失注理由を蓄積して分析する具体的な進め方は失注分析の進め方を参照してください。本記事では、失注・保留も「定義すべきフェーズの一部」だという設計上の位置づけにとどめます。

フェーズの移行条件（進捗基準）を定義する方法

進捗を客観化する鍵は、各フェーズに「次の段階へ進むための移行条件」を明文化することです。フェーズの名前と状態を定義しただけでは、担当者が「そろそろ提案フェーズかな」と主観で判断してしまい、結局フェーズの意味が人によってぶれます。

移行条件は「担当者が主観で判断できる表現」ではなく「Yes/Noで判定できる客観的な事実」で書く、これが設計の原則です。ここでは条件の書き方、そのまま使えるチェックリスト形式のテンプレート、そして条件を形骸化させない運用までを扱います。

移行条件を客観的な事実で書く

移行条件でありがちなのが、感覚的な表現をそのまま条件にしてしまうことです。

悪い例：「顧客が乗り気になったら提案フェーズへ」

「乗り気」は担当者の主観であり、人によって基準が違います。楽観的な担当者は少しの好感触で乗り気と判断し、慎重な担当者は同じ反応でもまだと判断します。これでは同じフェーズでも案件の実態がそろいません。

良い例：「意思決定者と面談日が確定し、課題・予算感をヒアリング済みなら、ヒアリングフェーズを完了して提案フェーズへ進む」

こう書くと、面談日が確定しているか（Yes/No）、課題と予算感をヒアリングできているか（Yes/No）で判定でき、担当者の気分に左右されません。移行条件は、第三者が案件情報を見て真偽を判定できる粒度まで落とすのがコツです。

移行条件テンプレート（フェーズ×3つの確認項目）

移行条件を書き出すとき、抜けなく客観的にするための整理軸として、各フェーズを次の3観点で確認する方法があります。フェーズごとにこの3つを埋めていくと、Yes/Noで判定できる条件が自然に組み上がります。

1. 誰と会えたか（キーマン接触） 意思決定者・決裁者に接触できているか
2. 何を確認できたか（課題・予算・時期） 導入の判断に必要な情報を取得できているか
3. 次回の約束があるか（ネクストアクション設定） 次のアクションの日程が確定しているか

この3観点でヒアリングフェーズと提案フェーズの移行条件を書き出すと、次のようになります。

ヒアリングフェーズを完了して提案フェーズへ進む条件：

• 誰と会えたか：導入判断に関わる担当者と面談できている
• 何を確認できたか：解決したい課題・想定予算・導入時期を確認できている
• 次回の約束があるか：提案を提示する日程が確定している

提案フェーズを完了してクロージングフェーズへ進む条件：

• 誰と会えたか：意思決定者に提案を提示できている
• 何を確認できたか：提案内容への反応と、競合・比較検討の状況を確認できている
• 次回の約束があるか：見積提示または条件交渉の場が確定している

3観点すべてがYesになって初めて次のフェーズへ進める、というルールにすると、進捗基準が担当者間でそろいます。全フェーズをこの粒度で書き出したものが、そのままフェーズ設計のチェックリストになります。

移行条件を形骸化させない運用

移行条件を決めても、フェーズが更新されなければ設計は絵に描いた餅になります。条件を守らせる仕組みは、更新のタイミングを行動に紐づけることと、フェーズ移行時の入力を促すことの2つで作ります。

更新のタイミングは、アクションを登録するときにフェーズを見直す運用にすると自然です。商談や電話の結果を記録する瞬間は、案件が前進したかどうかを判断する好機だからです。加えて、フェーズごとに必須項目を設定し、移行条件にあたる情報が入力されていないと次のフェーズへ進めない、あるいは入力を求められる仕組みがあると、条件が守られやすくなります。

例えばMazrica SalesのようなSFA（営業支援システム）では、案件管理でフェーズごとに必須項目を設定でき、移行時の入力の抜け漏れを防げます。移行条件にあたる確認事項を必須項目にしておけば、条件を満たさないままフェーズだけ進める運用を抑えられます。他のSFA/CRMでも同種の設定は珍しくないので、ツールを選ぶ際はこの入力制御ができるかを確認するとよいでしょう。

フェーズを使って案件の進捗を可視化する方法

移行条件つきで定義したフェーズは、3つの見方で案件の進捗を可視化できます。フェーズ別の案件分布（どこに何件・いくら滞留しているか）、各フェーズの滞留日数、フェーズ進捗レポートの3つです。

なかでも滞留日数で停滞案件を検知する視点は、フェーズ別の件数を見るだけの管理では見落とされがちで、停滞の早期発見に直結します。それぞれの見方を具体的に掘り下げます。

フェーズ別の案件分布で滞りを見る

まず見るべきは、フェーズごとに案件が何件・いくら分布しているかです。カンバン形式のボード表示や一覧で、フェーズごとの件数と金額の偏りを眺めると、どこで案件が詰まっているかが分かります。提案フェーズに案件が大量に溜まり、クロージングフェーズがスカスカなら、提案からクロージングへの移行でつまずいていると読めます。

この分布は、次に手を打つべき局面を教えてくれます。特定のフェーズに案件が滞留しているなら、そのフェーズの移行条件が厳しすぎるのか、営業スキルにボトルネックがあるのかを掘り下げる入口になります。

滞留日数で停滞案件を検知する

フェーズ別の件数だけでは、個々の案件が「いつからそこにいるか」は分かりません。そこで、案件が各フェーズに滞在している日数を見ます。「提案フェーズに30日以上ある案件」のように、滞留日数で停滞案件を洗い出す視点です。冒頭の「提案中で3週間止まったまま」という案件は、まさに滞留日数で検知すべき対象です。

例えばMazrica SalesのようなSFAでは、案件ボードで案件カードを直近アクションの経過に応じて色分けし、青は1週間以内にアクションあり、黄は1か月以内、赤は1か月以上アクションなしといった形で、動いていない案件を一目で見つけられます。あわせて「フェーズ滞留日数」という指標で、各案件が同じフェーズにどれだけ留まっているかを把握できます。

こうした自動的な停滞検知は、Excelでの手作業管理では再現しにくい部分です。手作業でフェーズと確度を追う関連ツールとして表計算ソフトを併用しているチームも多いですが、案件数が増えると滞留日数の算出が追いつかなくなります。

フェーズ進捗レポートで俯瞰する

日々の停滞検知に加えて、フェーズ全体の進捗を定期的に俯瞰する視点も必要です。各フェーズに案件がどれだけ進んでいるか、どのフェーズが薄いかをレポートで見て、次に注力すべきネクストアクションにつなげます。パイプライン会議などで案件を全員で見える化する場面での使い方はパイプライン会議での案件の見える化も参考になります。

例えばMazrica Salesには標準レポートが8種あり、そのうちの1つが「フェーズ進捗レポート」です。設定不要で各フェーズの進捗状況を俯瞰でき、レポート作成の手間なくフェーズ管理の状態を確認できます。こうしたフェーズ単位のレポートがツールに備わっているかも、選定時に見ておく観点になります。

フェーズ管理でよくある失敗と回避策

フェーズ管理が機能しなくなる原因は、大きく3つに集約されます。フェーズを行動で定義してしまう、移行条件が主観的でデータが信用されない、段階を細かくしすぎて更新されない、の3つです。

いずれも運用が始まってから直すのは難しく、設計の段階で先に手を打てる問題です。上位の解説記事が省きがちな失敗パターンなので、回避策とセットで押さえておきましょう。

フェーズが「行動」で定義され進捗が水増しされる

「初回訪問した」「提案書を送った」のように、自社の行動をフェーズの条件にすると、案件が実際には前進していなくてもフェーズだけが進みます。結果、パイプラインの金額が実態より膨らみ、着地見込みを読み間違えます。

回避策は、フェーズを顧客の状態で定義し直すことです。「提案書を送った」ではなく「意思決定者が提案内容を確認し、次の交渉の場を設定した」のように、顧客側の反応を条件に据えると、行動だけで進むことがなくなります。

移行条件が主観的でパイプラインの数字が信用されない

「顧客が前向きになったら」「感触が良ければ」といった主観的な条件でフェーズを運用すると、担当者ごとに基準がずれ、フェーズ別の集計を見てもマネージャーが数字を信じられません。信じられない数字は使われなくなり、フェーズ管理そのものが放置されます。

回避策は、移行条件をYes/Noで判定できる客観的な事実に書き換えることです。前述の3観点（キーマン接触・確認事項・次回の約束）で条件を書き出すと、感覚語を排除しやすくなります。

フェーズを細分化しすぎて更新が滞る

精密に管理しようとしてフェーズを10段階以上に刻むと、現場は1件ごとに細かい判断を迫られ、入力が負担になります。負担が続くと更新が後回しになり、フェーズが実態から遅れて、可視化の意味が失われます。

回避策は、まずシンプルな段階数で始めることです。運用しながら「この局面をもっと分けて追いたい」というニーズが出てきたら、そのとき段階を足します。最初から完璧なフェーズ体系を作り込もうとせず、使いながら育てるほうが定着します。

フェーズ管理を仕組み化するツールの選び方

案件数が少なく営業チームが立ち上げ期なら、Excelなどの表計算ソフトでもフェーズ管理は始められます。フェーズと確度を列で持たせ、手作業で更新していけば、少数の案件は十分に追えます。

一方で、案件数とメンバーが増え、フェーズ移行条件の入力徹底やリアルタイムでの情報共有、滞留案件の自動検知が必要になってくると、SFA（営業支援システム）のほうが運用に合ってきます。判断は「手作業でどこまで追えるか」の限界で考えると現実的です。

Excelで管理できる範囲とその限界

Excelでも、フェーズを列にし、案件ごとに現在のフェーズと確度を記録すれば、一覧としてのフェーズ管理は成り立ちます。案件が数十件で、更新する人が1〜2人なら、この方法でも回ります。

限界が来るのは、移行条件の入力を強制したいとき、滞留日数を自動で算出したいとき、複数人が同時にリアルタイムで更新したいときです。Excelでは、移行条件を満たさないとフェーズを進められない、といった入力制御を作り込むのは手間がかかります。滞留日数も関数で計算はできますが、案件が増えるとメンテナンスが煩雑になります。

Excelが使えないわけではなく、手作業での運用が追いつかなくなる境目がどこかで来る、という理解が実務的です。

ツール選定で確認する観点

SFA/CRMを検討する際、フェーズ管理の観点では次を確認するとよいでしょう。

• フェーズと移行条件（必須項目）の柔軟な設定 自社のフェーズ定義をそのまま反映でき、移行時の必須入力を設定できるか
• 滞留日数の可視化 各案件がフェーズに留まっている日数を自動で把握できるか
• フェーズ進捗レポート フェーズ単位の進捗を俯瞰できる標準的なレポートがあるか
• 複数営業プロセスへの対応 商材や事業ごとに異なるフェーズ構成を並行して管理できるか

複数営業プロセスへの対応は、扱う商材が複数あり、それぞれ検討の流れが違う組織で効いてきます。例えばMazrica Salesでは「案件タイプ」として案件ごとに異なるフェーズ構成を設定できますが、これはGrowth以上のプランで利用できる機能です。

ツールごとにプラン条件が異なるため、必要な機能が自社の契約プランで使えるかは事前に確認しておきましょう。SFAの導入・比較の総論はパイプライン管理の手法と実践に譲り、本記事ではフェーズ管理に絞った観点にとどめます。

まとめ

商談フェーズは「顧客の状態・案件が到達した状態」で定義し、各段階にYes/Noで判定できる移行条件（進捗基準）をセットで持たせる、これが進捗を客観的に可視化するための前提です。フェーズを行動で切ると進捗が水増しされ、移行条件が主観的だとパイプラインの数字が信用されません。

最初の一歩は小さく始めるのが現実的です。全フェーズを一度に設計しようとせず、まず「提案フェーズへ進む条件は何か」を1フェーズ分だけ、キーマン接触・確認事項・次回の約束の3観点で言語化してみてください。1つ書けると、他のフェーズも同じ型で展開できます。

案件数が少なく手作業で追える段階は、Excelでフェーズ管理を始めて問題ありません。案件数・メンバーが増え、移行条件の入力徹底や滞留案件の検知が課題になってきたら、フェーズ・確度・移行条件を一元管理し、滞留日数を自動で可視化できるSFA/CRMへの移行を検討する、という順が無理のない進め方です。パイプライン全体の設計はパイプライン管理の手法と実践で体系的に解説しています。

よくある質問

Q 商談フェーズは何段階がベストですか

A

一律のベスト段階数はなく、商材の検討期間と関与者数で変わります。検討が短く関与者が少ない単純な商材なら4〜5段階、検討が長く複数の決裁者が絡む複雑な商材なら6〜8段階が目安です。迷ったら少ない段階から始め、運用しながら足りない粒度を足していくと定着しやすくなります。

Q 失注した商談はフェーズ上でどう管理すべきですか

A

前進フェーズとは別に「失注」の状態を定義し、失注理由をセットで記録する運用にします。理由なく失注に落とすだけでは後から敗因を振り返れないため、失注理由を必須項目にしておくのがおすすめです。蓄積した失注理由の分析は別テーマなので、詳しくは失注分析の進め方を参照してください。

Q フェーズの入力ルールはどこまで厳しくすべきですか

A

移行条件にあたる情報は必須項目にして入力を促す一方、それ以外の項目まで細かく強制すると現場の負荷が上がり、更新が滞ります。まずは移行判定に必要な最小限の項目だけを必須にし、運用が定着してから項目を追加するバランスが現実的です。

Q 商談フェーズと確度は同じですか

A

同じではありません。フェーズは案件がどこまで進んだかという段階を示し、確度はどれだけ受注に近いかを示します。同じ提案フェーズでも、競合が優勢な案件と自社が本命の案件では確度が異なります。確度の数値化・スコアリングの詳細は受注確度のスコアリングで扱っています。

Q フェーズを更新するのは誰のタイミングですか

A

案件の担当者が、アクション（商談・電話・面談など）を登録するタイミングで更新するのが運用しやすい形です。活動の結果を記録する瞬間は、案件が前進したかを判断する好機だからです。この運用を徹底すると、フェーズが実態から遅れにくくなります。