一般に、レベニューリーダーから Forecast を直してほしいと依頼を受けるとき、Forecast は問題ではありません。問題はその下にある Pipeline ステージで、Deal を動かす Rep たちにとって同じことを意味しなくなっているのです。Discovery はある Rep にとっては最初のコール、別の Rep にとっては署名済みのミューチュアルアクションプラン。Closed Won はあるチームでは契約署名済み、別のチームではキックオフがスケジュールされた状態。コンバージョンの算数は正しく、運用上は無意味です。誰も共有していない定義に対して数字だけが合っています。
なぜ今これが重要なのか
ステージ定義への圧力は、AI がファネル内に登場し始めて以来、よくなるどころか悪化しています。Sinha、Shastri、Lorimer、Mantrala らの 9 月の Harvard Business Review は、AI とともに伸びているチームは、AI を、すでにクリーンなセールスプロセスの上に乗るコーチングとオーケストレーションの層として扱っているチームだ、と指摘しました。代わりではなく上に、です。これが非対称性です。ステージ定義が締まっていれば、エージェント型ツーリングはすでに機能しているシステムを加速します。緩ければ、AI はそのドリフトをご機嫌に自動化し、すでに 3 つの違うことを意味しているステージシグナルに基づいて Deal をルーティングします。
診断：「Closed Won」が 3 人の Rep にとって 3 つの違うことを意味する
ご自身のインスタンスで小さなテストをしてください。proposal-sent から negotiation のようなステージに動いた直近数十件の Deal を引き出し、各 Rep にそのステージ遷移が何を意味したかを聞いてください。返ってくる答えはこうです。価格を送った。価格を送り、認知された。価格を送り、認知され、Procurement が関与している。価格を送り、Champion が口頭で yes と言った。4 つの運用上の現実、1 つのステージ値、それらを同等として扱う 1 つの Forecast モデル。
これは Rep のディシプリンの問題ではなく、定義の問題です。Rep は、システムが曖昧な入力を与えるときに人がいつもすることをしています。曖昧さを自分の作業定義で埋め、チームはそのギャップを中心に最適化していきます。だから Pipeline レビューは尋問のようになります。マネージャーは Deal をレビューしているのではなく、Rep がそのステージで何を意味していたかを逆算しているのです。
1 ページの入場/退場条件テンプレート
直し方は小さく、華やかさはありません。Pipeline のすべてのステージが、共有された 1 ページの上に 4 行を持ちます。
- 一文の定義。このステージが何であるか、入社 3 日目の新人 Rep が読んですぐに適用できる言葉で。一文で書けないなら、そのステージは 2 つの仕事をしており、分割が必要です。
- Entry 条件。そのステージに入るために、Deal レコード上で真でなければならない、具体的かつ検証可能なこと。「Champion が今会計年度の予算が存在することを確認しており、Budget Confirmed プロパティに記録されている。」
- Exit 条件。Deal がそのステージを前進方向に出るために、真でなければならない、具体的かつ検証可能なこと。Entry と異なります。それが要点です。
- オーナー。その遷移に責任を持つロール。AE のときも、SE のときも、Deal Desk のときもあります。オーナーを名指しすることが、ステージをラベルではなくプロセスステップにします。
これがテンプレート全体です。1 ページに収まります。コストは書くことではなく、書いている最中に表面化する不一致にあります。だからこのテンプレートは、1 人で起草するために渡されたドキュメントではなく、ワークショップとしてのみ機能します。
Deal の上で歩いてみる：各ステージの境界で起こること
たとえば最近一緒に仕事をした B2B SaaS チームには 6 ステージの Pipeline がありました。中盤のステージ、評価ステージと呼びましょう、には Entry 条件がなく、Exit 条件は次のステージの Entry 条件と単語レベルでほぼ一致していました。機能的に、そのステージは駐車場でした。Deal は他のすべてのステージより中央値で約 3 週間長くそこに留まり、チームはそれを Pipeline の中盤の動き方として静かに受け入れていました。再定義ワークショップを行ったとき、最初の 20 分で 2 つのことが起きました。AE たちは、そのステージを Deal が停滞しているが Forecast から落としたくないことを意味するために使っていたと気づきました。CRO は、そのステージは 5 年前に誰かが PoC を追跡する場所を欲しがって作られ、誰も再訪していなかったために存在していると気づきました。両方が同じページに乗ると、判断はシンプルになりました。分割する。PoC は独自の Entry と Exit を持つ独自のステージになり、駐車場版の中盤ステージは削除されました。
だからワークショップが重要なのです。最後の成果物は 1 ページです。仕事は表面化です。
定義できないステージ
再定義をきれいに生き残るステージもあれば、そうでないものもあります。十分な数の HubSpot インスタンスでこれを回した後のパターンは、約 3 分の 1 のステージは定義の引き締めが必要だが残る、約 3 分の 1 は 2 つの異なる運用上の仕事をしているため 2 つに分割する必要がある、残りはマージまたは削除する、というものです。部屋の中で一文の定義を書けないなら、そのステージはステージではありません。フラグです。Pipeline のポジションではなく、Deal レコードのプロパティとして存在すべきです。
運用上のステージ vs. レポート上のステージ
一方で、Rep には自分たちが日々実際にすること、アクションの形、次のコール、前進に必要な成果物、に合致するステージが必要です。他方で、CFO にはボードレベルで持ちこたえる Forecast モデルにきれいに集約できるステージが必要です。この 2 つのニーズは必ずしも同じ形ではありません。私の解決の仕方：Pipeline ステージは運用上（Rep フェイシング、アクション形、4〜6 個）に保ち、別の Forecast カテゴリプロパティ、Commit、Most Likely、Best Case、Pipeline、をマネージャーが所有します。Rep が Deal ステージを動かし、マネージャーが Forecast カテゴリを割り当てます。異なるフィールド、異なるオーナー、1 つのカラムが何を意味すべきかをめぐる争いはなし。
現場で見たパターン
DACH の B2B SaaS シリーズ B のチームから Forecast の支援依頼がありました。CRO の言う問題は、加重 Forecast が四半期ごとに大きく外れることでした。最初のセッション内で表面化した実際の問題は、8 ステージの Pipeline に Exit 条件が重複する 3 つのステージがあり、SDR チームが未認定リードのホールディングペンとして使っているステージが 1 つあったことでした。再定義は AE リード、SDR リード、CRO、RevOps リードを部屋に入れた 2 時間のワークショップで回しました。アウトプット：Pipeline は 8 から 5 ステージに縮小、1 つのステージはプロパティに昇格、1 つのステージは PoC と有料パイロットが異なるモーションだったため分割。新アーキテクチャに対して再構築された Forecast モデルは翌四半期、実績の 10% 以内で着地しました。算数が賢くなったからではなく、ようやく入力が意味を持ったからです。
解決策：再定義のプレイブック
ご自身のインスタンスでこれを回す場合、順序が重要です。
- 2 時間をブロックし、正しい人を部屋に入れてください。AE リード、ファネル上部を共有しているなら SDR または BDR リード、CRO、RevOps オーナー。傍観者なし。不一致が仕事です。
- 現在の Pipeline をステージごとに歩き、既存の定義を声に出して読んでください。書かれた定義がないなら、各 Rep に 60 秒で書いてもらい比較してください。デルタが診断です。
- すべてのステージで 4 行を埋めてください。Definition、Entry、Exit、Owner。3 分以内に部屋が一文の定義に合意できないなら、そのステージは 2 つの仕事をしています。分割してください。
- Entry と Exit の条件が一致するステージにフラグを立ててください。それはステージではなく、ステージのふりをした Deal プロパティです。プロパティに昇格させ、Pipeline から外してください。
- 運用 vs. レポートを今、後回しにせず決めてください。Pipeline ステージは Rep フェイシング、アクション形のまま。Forecast カテゴリはマネージャー所有の別フィールドへ。
- 誰かが部屋を出る前に変更を HubSpot に設定してください。ステージ名、必須プロパティまたはワークフローゲートとして捕捉された Entry/Exit 条件、オーナー割り当て。設定を後回しにすると、合意は 1 週間で減衰します。
- 新アーキテクチャに対して Forecast を再ベースライン化してください。古いコンバージョン率は転送できません。モデルを再び信用する前に、新しいステージに対して次の 2 つの Pipeline レビューを回してください。
Checkpoint がどう関わるか
Pipeline ステージの再定義は、Checkpoint で RevOps エンゲージメントの中で最もよく回すワーキングセッションの 1 つです。通常は最初の月、ほぼ常に Forecast やレポート作業の前に行います。Forecast が外れている、コンバージョンの算数が信頼できないと感じる、あるいは Pipeline レビューで Rep がステージの意味について争っているなら、誰も共有していない定義の上にもう 1 四半期モデリングを重ねる前に、回すべきはこのワークショップです。
Noah Charak