ほとんどの B2B SaaS Pipeline は 3 ステージに集約されます。qualified、proposal、closed。「問題確認」と「契約署名」の間で死ぬすべての Deal は、Legal で失われた、または無決定で失われた、と記録されます。Pipeline は Deal を失ったのではなく、それをモデル化できなかったのです。確認と署名の間に何が起きるかを記述できない Pipeline は、なぜ Deal が停滞したかを教えられません。つまり次に何をすべきかを教えられません。以下の 5 ステージモデルは 3 つのライブ B2B SaaS 実装との接触を生き残っており、各ステージが別個のバイヤー行動と別個のセラーアクションにマッピングされるから生き残ります。
なぜ今これが重要なのか
B2B 購買は容易になっておらず、混雑しただけです。Adamson、Dixon、Toman は Harvard Business Review でソリューションセリングは行き詰まっていると論じました。Procurement チームが今、自分の診断とショートリストを持って到着するからです。セラーに残されたレバーは、バイヤーが Procurement を回す前に引かれます。バイヤーが持っていると思っていた問題を再フレームし、結果を定義する権利を得る。3 ステージの Pipeline はその仕事ができません。Deal ステージアーキテクチャは簡略化メカニズムです。ステージがバイヤー行動とセラーの仕事のために命名されているとき、チームは次に何をすべきかの強制関数を持ちます。「qualified、proposal、closed」と命名されているとき、チームはファイリングキャビネットを持ちます。
ステージ 1、Educate：機能セリングではなくビジョンセリング
Educate ステージは、バイヤーがまだ言語化していなかった問題のフレームに出会う場所です。セラーの仕事はプロダクトをデモすることではなく、プロダクトが扱う運用問題への語彙と、それがなぜ良くなる前に悪くなるかについての視点をバイヤーに与えることです。バイヤー行動：何も売られないミーティングを取る意志。セラーアクション：再フレーム、バイヤーの市場、ステージ、商業圧力に根ざした問題の 1 ページの明確化。Exit 条件：バイヤーが、自分の言葉で、議論しに来た問題を述べること。できないなら、Educate を出ていません。
ほとんどのチームはこのステージをスキップし、最初のコールを「Discovery」と呼びます。教育なしの Discovery は、バイヤーがあなたが望むと思ったもので答えた、Pain ポイントのチェックリストです。
ステージ 2、Discover：提案する権利を得るためのワーキングセッション
Discovery は認定質問のスクリプトではありません。理想的にはバイヤーの運用リーダーの 1 人を部屋に入れたワーキングセッションで、セラーが Educate のフレームに対してバイヤーのワークフローをマッピングします。バイヤー行動：データを持ってくる、同僚を連れてくる、これを取るためにミーティングをキャンセルする。セラーアクション：フレームをプレッシャーテストし、それが成立する 2〜3 か所と成立しない 1 か所を名指しし、24 時間以内にバイヤーに書き戻す。Exit 条件：バイヤーが、書面またはコールで、記述された問題が解決すべき問題であることに同意する。それなしには、解決策に価格を付けられません。
ステージ 3、Value：Deal を閉じるワークショップ
ここはほとんどのチームがスキップするステージで、それをスキップすることが Deal が Legal で死ぬ理由です。Discovery の後の本能は、提案、価格、条件、スコープ、レッドライン、を送り、バイヤーの Procurement 機能に残りをやらせることです。提案は Educate のフレームを見ていない、Discover ワーキングセッションにいなかった、Deal を擁護する商業的理由がない委員会に着地します。Deal は Procurement デスクで死に、セラーはそれを Legal の問題と呼びます。
直し方は、提案が出る前に、バイヤーのフルコミッティを伴う Value ワークショップです。1 つのデック。1 時間。セラーは結果のビジョンを売っています。12 か月後にバイヤーのレベニューモーションがどう見えるか、24 か月後に更新カーブがどう見えるか、解錠する Advocacy と Expansion パターン、ソフトウェアでもシート数でもありません。ワークショップは委員会が結果に整合する瞬間で、それが提案を交渉ではなく形式にするものです。バイヤー行動：フルコミッティが現れる。セラーアクション：価格ではなく結果を提示する。Exit 条件：ワークショップがカレンダーにあり、起きた。ワークショップが終わるまで Value から動けません。
なぜこのステージはほとんどの Pipeline から欠けているか
チームの誰もそれを所有しないからです。マーケティングはファネル上部を所有し、セールスはクローズを所有し、バイヤーが実際に下している運用判断、「これは合意した結果を提供するか」、はその間の無人地帯で起きます。Value ステージはそのギャップに名前を付け、オーナーを与えます。
ステージ 4、Setup：契約、キックオフ、CS が継承するステージ
Setup は商業的に Deal が獲得されたが、運用的には未定義のステージです。契約は Legal レビュー中、またはキックオフスケジューリング待ちで署名済み。バイヤー行動は評価からオンボーディングへ移行します。実装タイムライン、変更管理、Buying Committee から運用チームへのハンドオフ。セラーアクション：キックオフを必然に感じさせる。確認済みのキックオフ日、両側で名前付きオーナー、カスタマーサクセスオーナーがすでに読んだ 1 ページの実装計画。Exit 条件：契約署名済みでキックオフがスケジュールされている。継承の清潔さが、最初の 90 日がスムーズなオンボーディングか、回復プロジェクトかを決めます。
ステージ 5、Closed Won：単一の防御された定義
Closed Won は B2B SaaS Pipeline で最も乱用されたステージ名の 1 つです。引き継ぎの HubSpot や Salesforce インスタンスでは、契約署名済みを意味することもあれば、キックオフスケジュール済みを意味することもあれば、売上認識を意味することもあれば、しばしば Rep が四半期を達成するために必要とした意味を取ります。5 ステージモデルはそれを 1 つのこととして定義します。契約署名済みでカウンター署名済み、実装スケジュール済み、カスタマーサクセスオーナー命名済み、Finance に認識可能な売上イベント。それより前は依然として Setup です。ステージ定義はクリーンなレポーティングの強制関数で、Forecast が依存する唯一のものはクリーンなレポーティングです。
現場で見たパターン
DACH のシリーズ B の B2B SaaS チームから、4 ステージ Pipeline（new、qualified、proposal、closed）を抱えてご相談がありました。Proposal からの勝率は 30% を下回って推移しており、チームはそれを価格問題として扱っていました。違いました。ステージ定義の問題でした。90 日分の履歴 Deal に対して 5 ステージモデルを回したところ、Proposal から失われた Deal の約 3 分の 2 が、私たちが今 Value ワークショップと呼んでいるものをスキップしていました。Pipeline を 5 ステージに対して再構築し、Value ワークショップをハードな Exit 条件にし、ステージごとに 1 文の定義、Entry 条件、Exit 条件、オーナーで HubSpot の Deal ステージ定義を書き直しました。新 Pipeline での最初の四半期は、ステージ 5 Deal の勝率を、ファウンダーがボードデックに入れる気になる数字に動かしました。
解決策：5 ステージ Pipeline プレイブック
セールス Pipeline を再設計または監査しようとする B2B SaaS チームへ。
- ステージをバイヤーの行動とセラーのアクションに対して命名してください。「qualified」や「proposal」ではなく、Educate、Discover、Value、Setup、Closed Won。名前は Rep に次の動きを伝えなければなりません。
- 各ステージに 1 文の定義を書いてください。明示的な Entry 条件、明示的な Exit 条件、命名されたオーナーを追加します。一文で定義できないなら、そのステージはやりすぎています。
- Value ワークショップをハードな Exit 条件にしてください。バイヤーのフルコミッティとのワークショップがカレンダーにないと、Deal は Setup に動きません。強制関数を弱めないでください。
- 新ステージに対して 90 日の履歴 Deal を監査してください。勝った Deal と失った Deal を、それが実際に死んだステージにマッピングします。レガシーラベルと現実のギャップが診断です。
- 新ステージ定義に対して HubSpot または Salesforce Pipeline を再構築してください。1 つの Pipeline、5 つのステージ、ステージごとに 1 オーナー。マッピングしないレガシーステージは削除します。
- ステージ名ではなく、ステージ遷移についてチームをトレーニングしてください。チームは Educate のスペル方法ではなく、何が Deal を Educate から Discover へ動かすかを知る必要があります。
- 集約勝率ではなく、ステージ間コンバージョンをレポートしてください。ステージがバイヤー行動にマッピングされた Pipeline は、すべての遷移で速度の読み取りを与えます。それが Forecast のはずだったものです。
Checkpoint がどう関わるか
Pipeline アーキテクチャは、最初の四半期で元が取れる RevOps 作業です。5 ステージモデルは、Checkpoint で引き継ぎおよびグリーンフィールド Pipeline で回す標準フレームの 1 つで、典型的な HubSpot Pipeline での監査・再構築サイクルは 4〜6 週間です。Pipeline が 3 ステージに集約され、チームが停滞した Deal を「Legal の問題」と呼んでいるなら、直し方は提案が出る前に仕事を強制するステージアーキテクチャです。Pipeline を 2 度目に再設計する前に、ご相談ください。