営業フェーズ定義と移管基準|各段階の”完了”と”次へ進む”を定義する詳細設計手順
「フェーズを設定したのに、担当者によって案件の進捗判断がバラバラになっている」「フェーズを更新するタイミングが主観になってしまい、マネージャーのレポートが当てにならない」という状況は、SFAを導入している組織でも珍しくありません。こうした問題の原因は多くの場合、フェーズ名を並べただけで「何をもってそのフェーズが完了したとみなすか」という移行条件が定義されていないことにあります。
この記事では、営業フェーズの基本定義と周辺概念の整理から始め、各フェーズの「完了条件」と「次へ進む判定基準」を設計するための具体的な手順を解説します。受注案件と失注案件の比較から移行条件を帰納的に導く方法、SFAのフィールドへの落とし込み方、フェーズ管理が形骸化する原因と対策まで、実務で使える粒度でまとめています。
営業プロセス設計とパイプライン管理では営業プロセス全体の設計からパイプライン管理の体系を解説しています。本記事はそのクラスター記事として、フェーズ定義と移行条件の詳細設計に絞って掘り下げます。
営業フェーズとは
営業フェーズとは、見込み客の獲得から受注・フォローアップに至るまでの営業活動を段階に分け、各段階の目的とゴールを定義した枠組みです。フェーズを設けることで、案件が「今どこにあるか」をチームが共通言語で把握できるようになります。ただし、フェーズ名を並べるだけでは機能しません。各フェーズの「完了条件」が明確でないと、担当者ごとの判断がブレ、データの信頼性が失われます。このセクションでは、営業フェーズの基本定義と、よく混同される周辺概念の整理から始めます。
営業フェーズの定義
営業フェーズとは、営業活動をいくつかの段階に分けた枠組みです。フェーズを設ける目的は2つあります。案件の現在地を組織で共有すること、そしてどのフェーズで問題が起きているかを特定することです。
フェーズを区切る基準として重要なのは、「活動の種類」ではなく「顧客の検討状況の変化」に対応させるという考え方です。売り手の都合(例:「提案書を送ったから提案フェーズ」)で区切ると、顧客の意思決定の実態と乖離が生じます。「顧客が検討をどこまで進めているか」を軸に設計することで、フェーズが実態を反映しやすくなります。
営業フェーズ・営業プロセス・営業ステージ・営業フローの違い
これらの用語は実務でも混用されることがありますが、それぞれ指している範囲が異なります。
- 営業プロセス 営業活動全体の流れ・仕組みを指す広義の概念です。フェーズはその構成要素にあたります。
- 営業フェーズ プロセスを段階に区切ったものです。案件ごとに「現在どの段階か」を表します。
- 営業ステージ フェーズとほぼ同義で使われることが多いです。ただし、Salesforceなど特定のSFAツールでは「商談ステージ」として固有の定義を持つ場合があるため、ツールの文脈では混同に注意が必要です。
- 営業フロー 各フェーズで誰が何をどの手順で行うかを定めた活動の流れです。フェーズよりも粒度が細かく、フェーズをオペレーション面から実装するための設計に相当します。
本記事では「営業フェーズ」に統一して使います。他の記事や社内資料でステージ・フローと呼ばれていても、指している概念が同じであれば読み替えてください。
営業確度(ヨミ)との関係
フェーズと確度は別の軸です。フェーズは「案件が今どの段階にあるか」を表し、確度(ヨミ)は「受注する可能性がどのくらいあるか」を表します。
フェーズが高くても確度が低い案件は存在します。例えばクロージングの段階に進んでいても、競合に押されて受注確率が低い案件はその典型です。逆に、ヒアリングの段階でも顧客のニーズが明確で確度が高い場合もあります。
両者をセットで管理することで、フォーキャストの精度が上がります。「フェーズ×確度」のマトリクスで案件を見ることで、今月着地する案件と来月以降の見込みを分けて整理できます。確度管理と売上予測の詳細な指標設計については、営業パイプライン指標で扱っています。
営業フェーズを設定・管理するメリット
営業フェーズの設定は、案件管理ツールの入力項目を増やす作業ではありません。フェーズが機能すると、マネージャーは「今月の受注は着地するか」という問いに対して個別ヒアリングに頼らず回答できるようになります。担当者は「次に何をすべきか」を迷わずに動けます。ここでは代表的な5つのメリットを、「なぜその効果が生まれるか」という構造から整理します。
営業活動の属人化を防ぐ
フェーズと移行条件が定義されると、担当者が変わっても案件の引き継ぎが成立します。「このお客様は自分しか知らない」という状態が解消され、営業情報やデータが組織資産になります。
特に効果が出やすいのは、引き継ぎが頻繁に発生する組織です。インサイドセールスからフィールドセールスへの移行、担当者の異動・退職時に「次の担当者がどこから始めればよいかわからない」という問題が、移行条件の定義によって軽減されます。
進捗と滞留がひと目で把握できる
どの案件がどのフェーズに何日いるかが可視化されることで、マネージャーが優先的に介入すべき案件を特定できます。週次のパイプラインレビューで「このフェーズに3週間以上止まっている案件はどれか」を確認する運用が可能になります。
フェーズ滞留日数の把握がここで機能します。「この案件、少し止まっているかも」という感覚的な状態から、「○○案件が提案フェーズに18日滞留している」という定量的な把握に変わります。営業パイプライン可視化の手法と組み合わせることで、この進捗把握がさらに精度の高いものになります。
ボトルネックを特定できる
フェーズ別の案件数と通過率を比較すると、どのフェーズで案件が詰まっているかがわかります。例えば「ヒアリング→提案の通過率が他フェーズより低い」という事実が見えれば、提案の質や提案前のヒアリング精度に問題がある可能性を検討できます。改善施策の優先順位を感覚ではなく数値で決められるようになることが、フェーズ管理の大きな価値です。
売上予測(フォーキャスト)の精度が上がる
各フェーズの案件数に過去の通過率と平均単価を掛け合わせることで、売上見込みを定量的に算出できます。「なんとなく今月は厳しそう」ではなく、「クロージングフェーズに5件あり、過去の受注転換率が60%なら着地見込みは○○円」という計算ができるようになります。
この精度を出すためには、フェーズデータが実態を正確に反映している必要があります。移行条件がなく担当者の感覚でフェーズが決まっている状態では、このフォーキャストは機能しません。
人材育成とマネジメントの強化
担当者ごとのフェーズ別通過率から「強いフェーズ・弱いフェーズ」が数値で見えます。Aさんは初回商談から提案への転換率が高いが、クロージングでの決裁者アプローチが弱い、という把握が可能になります。育成の打ち手を「全体的にもっと頑張ろう」ではなく「クロージングフェーズの決裁者アプローチを強化しよう」という根拠のある形で選択できます。
代表的な7つの営業フェーズと各フェーズの役割
営業フェーズの標準モデルとして、7段階構成が広く用いられています。ただし、これはあくまで設計の起点であり、業種・商材・セールスサイクルに応じてカスタマイズが必要です。このセクションでは各フェーズの目的と、実務で機能させるために押さえるべき判断のポイントを整理します。後続の「移行条件の設計方法」と合わせて読むことで、フェーズを実際に使える状態に仕上げられます。
フェーズ1:アプローチ
目的は、見込み客と初めての接点を作ることです。主な活動としては、展示会・Web広告・テレアポ・SNS・既存顧客からの紹介などがあります。
このフェーズで明確にすべきことは2つあります。接触手段の優先順位と、次フェーズ(リード見極め)への移行判断基準です。「接触後に何が確認できれば次に進むか」をあらかじめ決めておかないと、接触数を増やすことに集中しすぎて、接触後の対応プロセスが設計されないという状態に陥りやすくなります。
フェーズ2:リード見極め(クオリフィケーション)
目的は、自社商品・サービスを購入する可能性があるかを判断することです。判断基準の代表例としてBANT(Budget:予算、Authority:決裁権、Needs:必要性、Timeframe:導入時期)がよく使われます。
注意点は、BANTをすべて確認しようとすると、確認だけで初回コンタクトが終わってしまうことです。優先順位を決めておくことが現実的です。最初にNeedsを確認し、次にTimeframeという順序にするなど、自社の商材と顧客の購買プロセスに応じて絞り込みます。このフェーズの移行条件の例としては「予算と導入時期の目安が確認できていること」が挙げられます。
フェーズ3:ヒアリング・初回商談
目的は、顧客の現状・課題・理想の状態を把握し、提案の根拠を作ることです。このフェーズの成果物として期待するのは、課題整理メモと提案に必要な情報リストです。
「ヒアリングが終わった」と「提案に必要な情報が揃った」は別の状態です。移行条件をヒアリング完了ではなく「提案根拠が揃っているか」で定義することで、情報不足のまま提案フェーズに進む案件を防げます。
フェーズ4:提案
目的は、ヒアリング内容に基づいて自社商品・サービスで課題を解決できることを示すことです。このフェーズの移行条件として機能しやすいのは「提案資料を顧客に送付し、担当者の反応(次回アポイントの合意など)を確認済みであること」という形式です。
提案書を送付した時点でフェーズをクロージングに進める運用は避けるべきです。顧客が資料を確認し、関心や懸念を表明した段階で初めて次フェーズへの移行を判断します。顧客の反応なしに送付だけでフェーズを進めると、クロージングフェーズに「実質まだ提案中」の案件が積み上がることになります。
フェーズ5:クロージング
目的は、価格・条件・スコープを合意し、受注を確定させることです。BtoBの実務では、このフェーズに「担当者の合意」と「決裁権限者の合意」という2つのステップが存在することが多く、セールスサイクルが長い場合はこの2ステップを独立したフェーズとして設けることも検討に値します。
移行条件の例として「決裁者が参加する場を設定済みであること」「稟議書の提出日程が確認済みであること」が挙げられます。これらの条件を満たしていない状態でクロージングフェーズに案件を置くと、実質はまだ提案フェーズの案件が混入し、フォーキャストの精度が落ちます。
フェーズ6:受注・契約
目的は、契約書締結・発注書受領など、法的・業務的な受注確定を完了させることです。クロージングと受注を独立したフェーズとして設ける意義は、「口頭合意は済んでいるが契約の手続きが遅延している案件」の見落としを防ぐことにあります。
特に受注件数が多い組織や、契約手続きに時間がかかる業種では、このフェーズを設けることで「受注済み」と「手続き完了済み」の区別が明確になります。
フェーズ7:フォローアップ
目的は、受注後の顧客満足・継続・拡大につながる活動です。受注後のフォローアップをSFAで管理するかどうかは組織によって異なります。カスタマーサクセスと営業の役割分担を事前に定義しておくことが必要で、「受注後はカスタマーサクセスに移管してSFAの案件は完了扱い」とするか、「継続商談・アップセルの管理を引き続きSFAで行う」とするかを明確にしておきます。
移行条件(exit criteria)の設計方法
営業フェーズの定義が形骸化する最大の原因は、「次のフェーズに進んでいい」という判断が担当者の主観に委ねられていることです。移行条件(exit criteria)とは、そのフェーズが完了したとみなすための客観的な条件の定義です。この条件を組織で合意し、SFAのフィールドに組み込むことで、フェーズのデータは意思決定の根拠として機能するようになります。本セクションでは、移行条件を設計するための具体的なステップを示します。
移行条件とは何か
移行条件とは、「前のフェーズで確認すべきことが確認できている」という完了条件の定義です。具体的な形式で表すと、「提案フェーズからクロージングへ移行する条件は、決裁者への直接プレゼンを完了し、予算承認の見込みが確認できていること」のように書かれます。
移行条件がないと何が起きるかを整理します。担当者Aは初回商談の合意を取った時点でクロージングに移行し、担当者Bは口頭での前向きな反応をもってクロージングとします。フェーズ別の集計が担当者ごとの感覚の差を反映してしまい、「クロージングフェーズに10件ある」という数字が実態を表さなくなります。ボトルネックを特定しようとしても、データが担当者ごとの主観のばらつきを含んでいるため、正確な分析ができません。
受注案件と失注・停滞案件の比較から条件を抽出する
移行条件を設計する最も実務的な起点は、自組織の過去データの棚卸しです。直近6〜12か月の受注案件を対象に、各フェーズで「何が確認されていたか」を書き出します。次に同期間の失注・停滞案件と比較し、「受注案件に共通してあり、失注案件に共通してなかった状態」を抽出します。
このアプローチが有効な理由は、自組織の商材・顧客特性に基づく条件を帰納的に導けることにあります。汎用フレームワークをそのまま適用するより、現場への定着率が高くなります。担当者が「この条件は確かに受注につながる」と納得できる根拠があるからです。
サンプル数が少ない場合は判断が難しくなります。その場合は「現場の上位担当者へのヒアリング」と「汎用フレームワーク(MEDDIC・BANT等)の参照」を組み合わせて条件を仮設定し、運用しながら精度を上げていく方法が現実的です。
各フェーズの移行条件の設計例
各フェーズの移行条件を「完了条件(確認済みの状態)」と「確認手段(何を見れば確認できるか)」の2点で統一して示します。これはあくまで設計サンプルであり、自組織の商材・顧客の意思決定プロセスに合わせた修正が必要です。
- アプローチ → リード見極め:連絡が取れる担当者名と連絡先が確認できており、次回の会話設定の合意を取得済みであること。確認手段はアクションの実施結果欄への合意内容の記録。
- リード見極め → ヒアリング:BANT(予算・決裁権・必要性・時期)のうち少なくともNeedsとTimeframeが確認済みであること。確認手段は案件の「ヒアリング情報」フィールドへの記入済み確認。
- ヒアリング → 提案:顧客の現状課題・解決したい状態・評価基準が記録されており、提案書作成に必要な情報が揃っていること。確認手段は案件の課題欄への記入済みかつ次回提案日程の合意済み確認。
- 提案 → クロージング:提案資料を送付・説明済みであり、担当者から前向きな反応(次回アポイント合意または懸念事項の特定)を確認済みであること。確認手段はアクション記録への顧客反応の記載。
- クロージング → 受注:決裁権限者との商談を完了し、発注・契約の手続き開始の合意を取得済みであること。確認手段はアクション記録への決裁者合意内容の記載。
MEDDIC・BANTなど既存フレームワークの活用
移行条件の設計に活用できる代表的なフレームワークとして、BANT・MEDDIC・CHAMP・ANUMがあります。それぞれの特徴と向くケースを整理します。
| フレームワーク | 主な確認項目 | 向くケース |
|---|---|---|
| BANT | 予算・決裁権・必要性・時期 | 比較的シンプルな意思決定構造のBtoB商材 |
| MEDDIC | 指標・経済的購買者・意思決定基準・意思決定プロセス・課題の特定・チャンピオン | 複雑な購買プロセスを持つエンタープライズ向け |
| CHAMP | 課題・決裁権・お金・優先度 | 顧客の課題を起点にしたコンサルティング型営業 |
| ANUM | 決裁権・必要性・緊急度・予算 | 短サイクルで決裁権者へ早期アクセスを優先する営業 |
フレームワークはあくまで確認すべき観点の整理ツールです。「すべての項目を確認しないとフェーズを進められない」という運用にすると入力負荷が高くなり、形骸化します。各フレームワークの項目から自組織の商材に照らして優先度の高い2〜3項目を選び、移行条件として設定することが現実的です。
フェーズ数の決め方
「フェーズはいくつに分けるべきか」という問いに対する正解は、商材・顧客の意思決定構造・セールスサイクルの長さによって異なります。ただし、運用可能な範囲の目安として5〜7フェーズが標準的です。このセクションでは、フェーズ数を決めるための判断軸と、細かすぎる場合・粗すぎる場合それぞれの弊害を整理します。
フェーズ数を決める3つの判断軸
顧客の意思決定のステップ数が1つ目の軸です。顧客側で担当者の合意・上長承認・稟議という複数のステップがある場合は、それぞれを独立したフェーズとして設計する価値があります。意思決定の節目をフェーズの区切りとして対応させることで、各ステップの停滞を可視化できます。
管理したいボトルネックの数が2つ目の軸です。ボトルネックを特定したい箇所の数に合わせてフェーズを設けるという考え方です。4箇所の詰まりを管理したければ、少なくとも5フェーズは必要になります。「何を管理したいか」からフェーズ数を逆算します。
SFAの入力負荷と更新頻度が3つ目の軸です。フェーズを細かくするほど入力・更新の頻度が上がります。担当者が日常業務の中で継続して更新できる範囲に収めることが、フェーズ管理を形骸化させないための前提条件です。
細かすぎる場合・粗すぎる場合の弊害
細かすぎる場合(10フェーズ以上)の弊害は2つあります。入力・更新の負荷が高くなり、フェーズ更新が後回しにされて形骸化することと、隣接フェーズの違いが曖昧で担当者が判断に迷うことです。「このフェーズとあのフェーズの違いは何か」という問いが頻繁に出るようであれば、フェーズが細かすぎるサインです。
粗すぎる場合(3フェーズ以下)の弊害は、「商談中」という一塊に大量の案件が滞留し、どこで止まっているかが見えなくなることです。ボトルネック特定という機能を果たせなくなります。
適切な範囲の目安は5〜7フェーズです。Salesforceの標準ステージ(見込み・アプローチ・提案中・交渉中・成約)も同様の思想で設計されており、この範囲が実務で広く機能することを示しています。
業種別のフェーズ設計の考え方
営業フェーズの設計は、業種・商材・セールスサイクルの長さで大きく異なります。短サイクルのSaaS型と、複数の意思決定者が関与する長サイクルの製造業・インフラ系では、フェーズの分け方・移行条件の粒度・管理するKPIが変わります。このセクションでは、2つの典型パターンを比較し、自社の設計に転用するための考え方を示します。
SaaS・クラウドサービス型(短〜中サイクル)
セールスサイクルが1〜3か月程度で、意思決定者が比較的少ない(担当者と直属の上長)というパターンです。
フェーズの特徴として、リード見極めとヒアリングを分離し、デモ・トライアルを独立フェーズとして設ける設計が多く見られます。トライアル後の受注転換率が重要な指標になるため、「トライアル中」を独立フェーズとして置くことで、そこでの滞留や離脱を把握できます。
移行条件の例としては「デモ実施済みかつトライアル申込合意」「担当者の合意取得済みかつ稟議書提出日程の確認済み」が挙げられます。管理すべき指標は、リードからデモへの転換率、デモから商談化の転換率、トライアル後の受注転換率です。
製造業・設備投資型(長サイクル)
セールスサイクルが6か月から複数年にわたり、複数の部門・意思決定者が関与するパターンです。
フェーズの特徴として、「担当者の合意フェーズ」と「上位決裁者の合意フェーズ」を分離した設計が有効です。仕様確認・見積もり・稟議を独立フェーズとして設けることも選択肢になります。購買プロセスが長く複雑なため、どのステップに止まっているかを細かく把握する設計が求められます。
移行条件の例としては「製品仕様の適合確認が完了し技術部門からの承認が取得済み」「稟議書が提出済みであること」が挙げられます。管理すべき指標は、フェーズ滞留日数(特に稟議・社内検討フェーズの長期化の検知)と、フォーキャスト期間の設定(四半期ではなく半期・年度単位)です。
自社のセールスサイクルがSaaS型と製造業型の中間に位置する場合は、両パターンの要素を組み合わせて設計します。「平均的なセールスサイクルの長さ」と「意思決定に関与する人数」の2軸で自社のパターンを判断し、近い型を参照するのが出発点として機能します。より体系的な設計の進め方については営業プロセスの設計方法も参照してください。
営業フェーズ管理が機能しない原因と対策
営業フェーズを設定しても「担当者が更新してくれない」「レポートが実態と合わない」という状況は多くの組織で発生しています。原因を「担当者の意識の問題」に帰着させると改善できません。フェーズ管理が機能しない原因は構造的なものが多く、設計段階で対処できます。ここでは代表的な4つの原因と、それぞれの対策を整理します。
原因1:移行条件が曖昧で担当者の判断がブレる
症状は、フェーズの進め方が担当者ごとに異なることです。同じ状況でも、Aさんは「提案中」、Bさんは「クロージング」とマークします。この状態では、フェーズ別の集計データが担当者の感覚のばらつきを反映してしまい、ボトルネックの特定に使えません。
対策は、各フェーズの移行条件を「○○が確認済みであること」という形で文書化し、チームで合意することです。さらにSFAの必須入力項目として組み込むことで、移行条件の確認が業務プロセスの一部になります。
原因2:フェーズ更新が主観によって決まり、更新漏れが起きる
症状は、担当者が「良い感触を持ったとき」にフェーズを進めるが、根拠が感覚的であることです。更新タイミングも商談後ではなく週次レビュー前にまとめて行われるため、常にデータが実態より遅れた状態になります。
対策は、アクション(商談・電話・メール)の記録をトリガーにフェーズ更新を促す運用を設計することです。「商談を記録したら、フェーズの更新確認画面が表示される」という流れを設計することで、更新のタイミングを商談直後に引き寄せられます。SFAのCRMオートメーション機能(アクション完了をトリガーにした通知など)を活用することで、このトリガー設計が実装しやすくなります。
原因3:部署間のハンドオフで案件が取りこぼされる
症状は、インサイドセールスからフィールドセールスへの引き継ぎ時、マーケティングからインサイドセールスへの引き継ぎ時に、案件が宙に浮いて対応が遅れることです。「引き継ぎました」「まだもらっていません」という齟齬が発生します。
対策は、ハンドオフのフェーズを明示的に設けることです。例えば「MQL(マーケティングクオリファイドリード)」「SQL(セールスクオリファイドリード)」のように、担当部署の切り替え点をフェーズとして定義します。引き継ぎ時に必要な情報の記入を移行条件にすることで、「情報が揃っていなければ次の担当者に渡せない」という設計になります。
原因4:SFAへの入力負荷が高く形骸化する
症状は、フェーズ更新のために複数の項目を埋める必要があり、担当者が後回しにすることです。やがてフェーズデータが実態を反映しなくなり、「SFAのデータは信用できない」という空気が組織に広がります。
対策は2つあります。移行条件の確認項目を最小化すること(1フェーズあたり1〜2項目)と、入力補助機能を活用して入力コストを下げることです。アクションのテンプレートや、AIによる活動内容の要約・更新サジェストのような機能を使うことで、「記録すること」の負担を軽減できます。営業効率化の方法も併せて参照すると、入力負荷の軽減に向けた組織全体のアプローチが把握できます。
SFAへの移行条件の組み込み方
移行条件を設計しても、それが担当者の頭の中やドキュメントに留まっている限り、日常業務には定着しません。移行条件をSFAのフィールド・必須入力・フロー設計に組み込むことで、条件確認が業務プロセスの一部になります。このセクションでは、SFAへの実装方法の考え方を整理します。
フェーズ変更時の必須入力項目の設定
フェーズを変更しようとすると「確認事項を記入してください」という必須フィールドが表示される設計にすることで、条件確認が業務フローに組み込まれます。
具体的な例として、「提案→クロージング」に移行する際に「決裁者との面談日」の入力を必須項目として設定する方法があります。入力しなければフェーズを進められないため、移行条件の確認が自然に業務の一部になります。
必須項目を増やしすぎると入力負荷が上がり逆効果です。1フェーズ移行あたり1〜2項目が現実的な上限として機能します。まず最も重要な確認事項を1項目選んで設定し、運用が安定してから追加を検討する順序が定着を早めます。
案件ボードと滞留日数の活用
SFAの案件ボード(カンバン形式)を使うと、フェーズ別に案件を一覧表示できます。例えばMazrica Salesのような SFAでは、案件ボードで直近のアクション状況を色分け表示(青:1週間以内にアクション済み、黄:1か月以内、赤:1か月以上アクションなし)し、滞留している案件を視覚的に把握できます(ツールにより機能は異なります)。
案件発生日からのリードタイムとフェーズ滞留日数を組み合わせて追うことで、「どのフェーズで・どの担当者の案件が・何日止まっているか」を定量的に把握できます。案件ボードを週次レビューの起点として使い、赤くなっている案件を優先的に取り上げる運用が定着すると、フェーズデータの更新頻度も上がります。
フェーズ進捗レポートによる定期チェック
週次・月次のパイプラインレビューで、フェーズ別の案件数と移行数を確認する運用を設計します。確認すべき観点は2つです。前週比でフェーズが止まっている案件はどれか、通過率が低下しているフェーズはどれかという点です。
この定期チェックがあることで、フェーズ更新漏れが翌週には発覚し、担当者も更新する動機が生まれます。「レビューまでに更新しておかなければ、止まっている案件として取り上げられる」という構造が、更新の習慣化を促します。
フェーズ進捗レポートの詳細な活用方法やKPI設計については、営業パイプライン指標と営業パイプライン可視化も参照してください。
フェーズ設計を組織に定着させる3つのステップ
移行条件を設計してSFAに組み込んだだけでは、組織への定着は保証されません。定着には「設計→合意→運用→改善」というサイクルが必要で、特に最初の「合意形成」を省略するとルールが守られない状態になりやすいです。ここでは、フェーズ設計を組織に根づかせるための3つのステップを整理します。
ステップ1:現場の上位担当者と設計する
管理側だけで設計したフェーズは現場が使いにくいと感じやすい傾向があります。受注経験の豊富な担当者をフェーズ設計に参加させることで、現場感のある移行条件が作れます。
参加者の目安はマネージャー1〜2名と上位営業担当者2〜3名です。この規模であれば意見がまとまりやすく、「自分たちで決めた」というオーナーシップが定着率を上げる効果があります。設計会議を1回で終わらせようとせず、「まず叩き台を作り、1週間試してから修正する」という進め方が機能しやすいです。
ステップ2:小さく始めて四半期ごとに見直す
最初から完璧なフェーズ設計を目指す必要はありません。5〜6フェーズで始め、運用データが溜まったら通過率を確認してフェーズの分割・統合を判断します。
見直しのタイミングは四半期末のパイプラインレビューが適しています。「フェーズ滞留が長すぎて実態と合っていない」「このフェーズとあのフェーズの区別が現場でついていない」という声が出た箇所を優先的に改定します。フェーズ設計は一度決めたら固定するものではなく、運用しながら精度を上げていくものです。
ステップ3:マネージャーが活用例を示す
マネージャー自身がフェーズボードを使ってケーススタディを示すことで、フェーズの使い方が現場に伝わります。「この案件がなぜクロージングに進めないかをフェーズで考えると、決裁者との接点がまだ取れていないことが原因だとわかる」という対話を積み重ねることで、担当者はフェーズを単なる入力項目としてではなく、案件を前に進めるための思考ツールとして使えるようになります。
フェーズデータを使って「何をコーチングするか」を決める文化を作ることが最終目標です。「なぜ受注できなかったか」の振り返りをフェーズ別のデータを起点に行う習慣が定着すると、フェーズ管理が組織の営業力強化に直結します。
まとめ
営業フェーズを機能させる条件は、「フェーズ名を並べること」ではなく「移行条件を定義してチームで合意すること」にあります。移行条件がなければフェーズは担当者ごとの感覚の産物になり、データは意思決定の根拠として使えません。
設計の起点は自組織の受注案件と失注案件の比較です。直近6〜12か月の案件を棚卸しし、各フェーズで受注案件と失注案件の状態を比較することで、自組織の商材と顧客特性に合った移行条件を帰納的に導けます。外部フレームワーク(BANT・MEDDIC等)は参照軸として使いながら、優先度の高い2〜3項目に絞って設定します。
フェーズ管理が形骸化している組織は、原因が担当者の意識よりも設計の不備にあることが多いです。「移行条件がない」「入力負荷が高い」「ハンドオフの定義がない」という3点を優先的に確認します。
すでにSFAを使っている場合は、まず既存の案件データから「どのフェーズに何件あるか」「フェーズ滞留日数の長い案件はどれか」を確認するところから始められます。データを見ることで、どのフェーズの移行条件を最初に整備すべきかが見えてきます。
営業プロセス設計とパイプライン管理では営業プロセス全体の設計とパイプライン管理の体系を解説しています。フェーズ改善に着手したあとのパイプライン改善策についてはパイプライン改善を参照してください。
よくある質問
Q 営業フェーズとは何ですか?
見込み客の獲得から受注・フォローアップまでの営業活動を段階に分け、各段階の目的とゴールを定義した枠組みです。案件が現在どの段階にあるかをチーム全員が共通言語で把握し、どこで問題が起きているかを特定するために使います。
Q 営業活動のフェーズとは?
営業担当者が日々行うアクション(電話・商談・提案など)を、顧客の検討状況の変化に対応した段階に整理したものです。フェーズは「活動の種類」ではなく「顧客の意思決定がどこまで進んでいるか」を基準に区切ります。活動の種類で区切ると、同じ「提案書を送った」という活動でも顧客の検討の進み具合が異なる案件が同じフェーズに混在してしまいます。
Q 法人営業のフェーズは?
BtoB(法人)営業では、複数の意思決定者が関与するため、「担当者の合意フェーズ」と「決裁権限者の合意フェーズ」を分離した設計が有効です。稟議・社内検討のステップが長いケースでは、そのフェーズを独立させて滞留を可視化することが重要です。BtoB特有の「口頭では合意済みだが決裁が下りていない」という状態を、フェーズとして区別して管理することで、フォーキャストの精度が上がります。
Q 一般的な営業プロセスは?
代表的な7段階は、アプローチ(初接触)、リード見極め(クオリフィケーション)、ヒアリング・初回商談、提案、クロージング、受注・契約、フォローアップです。ただし商材・業種・セールスサイクルに応じてカスタマイズが必要です。自組織のセールスサイクルの長さと意思決定者の関与構造によって、フェーズの統合・分割を判断します。
Q 営業の7つのステップは?
接触(アプローチ)、見込み評価(クオリフィケーション)、課題のヒアリング、解決策の提案、価格・条件の合意(クロージング)、契約締結(受注)、関係維持・拡大(フォローアップ)の7ステップが代表的です。各ステップの移行条件を定義することで、ステップ間の引き継ぎ精度が上がり、どのステップで案件が詰まっているかを定量的に把握できます。
Q ビジネスの4つのフェーズは?
「ビジネスの4つのフェーズ」は事業ライフサイクル(創業期・成長期・拡大期・安定期)を指す場合が多く、本記事の「営業フェーズ」(商談の進捗段階)とは別の概念です。事業フェーズは経営戦略の文脈で使われ、営業フェーズは案件管理・パイプライン管理の文脈で使われます。混同されることがありますが、指している対象が異なります。







