実際の販売方法に合ったPipelineステージの設計

「提案送付済み」はB2B営業で最も無意味なPipelineステージであり、CRMの70%に存在しています。

提案を送るのは担当者が行うことです。購買者がどの段階にいるかは何も教えてくれません。担当者は午後に50件のリードに提案を送れます。だからといって50件の案件が前進したわけではありません。

ほとんどのCRM Pipelineステージの問題は、購買者の位置ではなく担当者の活動を説明していることです。ステージが担当者の活動を表すと、Pipelineはチームがどれだけ忙しいかを示しますが、クォータを達成できるかどうかは示しません。

このガイドでは、予測が実際に何が起きているかを反映するよう購買マイルストーンに基づいてPipelineステージを再構築する方法を説明します。

ステップ1：取引タイプの購買マイルストーンをリストアップする

購買マイルストーンは購買者にとって真実である必要があることです。担当者が完了するタスクではありません。すべてのステージについて聞くべき質問：「購買者はここに至るために何をしたか、何を理解したか、何にコミットしたか？」

最初に営業サイクルの実際のマイルストーンをリストアップしてください。最初の接触からクローズドまで、購買者の意思決定プロセスで何が真に変わりますか？典型的なB2B SaaSの案件には次のものが含まれるかもしれません：

購買者が解決に値する問題があると認識する
購買者がソリューションを評価することに同意する（評価に時間を割り当てた）
購買者が予算の存在と意思決定のタイムラインを確認した
購買者が製品を見て自社のユースケースと結びつけた
購買者の社内チャンピオンが経済的バイヤーにプレゼンした
購買者が法的および調達のレビューを完了した
購買者が署名した

リストに含まれていないもの：「担当者がアウトリーチを送った」「担当者がデモをした」「担当者が提案を送った」「担当者がフォローアップした」。それらは担当者の活動です。起こりますが、購買者がどこにいるかを定義しません。

ステージに名前を付ける前に購買マイルストーンを書き出してください。後で名前を付けられます。まず購買者の行動の順序を正しく把握してください。

ステップ2：ステージ名ではなく参入基準を書く

「見込み顧客」「提案」「交渉」のようなステージ名は曖昧です。2人の担当者が同じステージ名を使っても意味が異なり、結果は表面的には一貫しているように見えても実際にはそうでないPipelineになります。

参入基準は具体的です。検証可能です。そして担当者の意見ではなく購買者の状態についてです。

違いは次のとおりです：

悪い例（ステージ名が基準）： 「見込み顧客」— 担当者がリードをいつ見込み顧客と見なすかを決める

良い例（参入基準）： 「購買者が確認した事項：予算範囲、意思決定タイムライン、関与する少なくとも2人のステークホルダー、解決できる現行の問題。担当者が確認した事項：自社の会社規模とユースケースに対応している。」

参入基準は、担当者またはマネージャーがそれを読んで案件がそのステージに属するかどうかについて客観的な判断ができる場合に機能します。「担当者はこれが見込み顧客と信じている」は客観的ではありません。「購買者はQ3の予算と2か月の評価ウィンドウを口頭で確認した」は客観的です。

CRMに構築する前に、すべてのステージの参入基準を書いてください。チェックリストの形式にしてください：

ステージ：ソリューション適合性確認済み 参入基準：

購買者が製品デモを見た
購買者が主要ユースケースがサポートされていることを確認した
担当者が購買者の2〜3の主要要件をドキュメント化した
認定阻害要因が特定されていない（地域、コンプライアンス、インテグレーションのブロッカー）

担当者が案件がこのステージにあるかどうかわからない場合、基準を読み、楽観ではなく事実に基づいて判断します。

ステップ3：各ステージの退出基準を設定する

参入基準はステージに入るために何が真実でなければならないかを定義します。退出基準は案件が次に進む前に何が起こらなければならないかを定義します。

この違いが重要な理由は、案件がステージの中で停滞できるからです。退出基準がなければ、担当者は案件を45日間「評価中」に置いてアクティブと呼べます。

退出基準は通常次のステージの参入基準と同じです。しかし時には最初に起こらなければならないアクションがあります。例えば：

ステージ：ソリューション適合性確認済み 退出基準：

担当者が主要要件とソリューション適合性の書面サマリーを経済的バイヤーに送付した
購買者が受け取りを確認し、次のステップ（スコープコール、価格コール、またはLOI）に同意した

退出基準は責任を生み出します。これらのことが完了するまで案件は前進できません。HubSpotでは案件レコードのフィールドをステージ変更時に必須にできます。Salesforceでは同じ目的でバリデーションルールが機能します。

ステップ4：ステージ数を案件期間に合わせる

ステージが多ければ精度が上がるわけではありません。通常は混乱が増えます。

有用な経験則：購買者の旅程の意味ある意思決定ポイントごとに1つのステージ。短いサイクルの場合、4〜6ステージが適切です。複雑なエンタープライズの案件の場合、7〜10ステージが適切です。10ステージを超えると、通常は些細な違いを分けているだけです。

短いサイクル（30日以内、SMB）： 4〜5ステージが適切です。それ以上だと担当者は実際の販売ではなくステージ間で案件を移動することに時間を費やします。サンプル：

見込み顧客との接触（最初の意味のある双方向会話）
ディスカバリー完了（問題と適合性が確認された）
デモ完了（ソリューションが示され、ユースケースが検証された）
提案受諾（価格が確認され、購買者が進めたい）
クローズウォン / クローズロスト

中程度のサイクル（60〜90日、ミッドマーケット）： 6〜8ステージ。ステークホルダーの調整、技術評価、調達レビューなど、より多くの購買プロセスを反映する余地があります。

長いサイクル（90日以上、エンタープライズ）： 8〜12ステージ。ただし各ステージが真の購買者の意思決定ポイントを表す場合のみ。

ステージが6つか8つかわからない場合は、少ない方から始めてください。後でステージを分割できます。ステージを統合する方が厄介です。ステージの中で案件が費やした時間の履歴データが失われるからです。

ステップ5：1つのCRMで複数の案件タイプを処理する

ほとんどのチームには複数の取引スタイルがあります：SMB対エンタープライズ、新規ビジネス対拡張、製品Aと製品B。誘惑はそれぞれに別のPipelineを構築することです。時にはそれが正しい。多くの場合はレポートの断片化を生み出します。

質問すべきこと：これらの取引タイプは同じ基本的な購買の旅程を共有していますか、それとも本当に異なるプロセスですか？

同じ旅程をタイムラインが異なるだけで共有している場合、レポートのセグメント化のための「案件タイプ」フィールドを持つ1つのPipelineの方がよりクリーンです。ステージは同じで、各ステージの時間と確率のウェイトが異なります。

旅程が真に異なる場合、例えばプロダクトリードのセルフサーブスタイルとエンタープライズのダイレクトセールススタイルの場合、別々のPipelineが正当化されます。HubSpotは単一のポータル内で複数のPipelineをサポートしています。Salesforceにはワークフローを区別するOpportunityレコードタイプがあります。Pipedriveはアカウントレベルで複数のPipelineをサポートしています。

しかし2つのPipelineを構築する前に、購買マイルストーンが実際に異なることを確認してください。SMB PipelineとエンタープライズPipelineのステージが同じ6ステップになる場合、1つのPipelineを構築してレポートのフィルタリングに案件タイプフィールドを使用してください。

ステップ6：ステージを確率に結び付け、数式を理解する

ほとんどのCRMでは各ステージにクローズ確率のパーセンテージを割り当てられます。これは重み付けPipeline予測の基礎です：案件金額に確率を掛けて期待値を得ます。

問題：デフォルトの確率はほぼすべてのチームにとって間違っています。

HubSpotのデフォルト（アポイントメント設定時5%、購買適格時20%、契約送付時90%）はHubSpotの社内営業チームによって構築されました。あなたのコンバージョン率は異なります。「価格レビュー」ステージに達した案件の60%をクローズするなら、そのステージは60%であるべきで、20%ではありません。

ステージ確率を較正するには：

過去12〜24か月の案件（クローズウォンとクローズロスト）をエクスポートする
各案件について通過したステージを記録する
各ステージについて計算する：（このステージからクローズウォンした案件）/（このステージに入った案件の合計）
その比率がそのステージからの歴史的クローズ確率です

注意：確率が担当者のコンペンセーションと結びついていると、担当者は確率を操作し始めます。「重み付けPipelineターゲット」の達成でボーナスが得られる場合、担当者は数値を膨らませるために案件を高確率ステージに早期に移動させます。

ステップ7：新しいステージを最近の10件の案件でテストする

新しいPipelineステージをGo-liveする前に、履歴に対してテストしてください。最近のクローズウォンとクローズロストの案件を10件取り出して、新しいステージに沿って各々をトレースしてください。

各案件について：

各参入基準が満たされた瞬間を特定できますか？
案件が最も多くの時間を費やしたステージは、購買者の不確実性が最も高かった場所と一致しますか？
案件が失われたステージは、なぜ失注したかについて何か有用なことを示していますか？
この案件のステージ履歴を確認したマネージャーは介入すべき場所がわかりますか？

このQAエクササイズは、実際の案件でPipelineが埋まる前にステージ設計のギャップをキャッチします。一般的な発見事項：

すべての案件がスキップするステージ（実際のマイルストーンではない）
同じ日にすべての案件が通過する2つのステージ（同じマイルストーン、不必要に分割されている）
案件が入るが勝利してほとんど出ないステージ（最も高いコーチングの機会）

発見事項をドキュメント化してください。テストした10件の案件のうち3件が「技術レビュー」を完全にスキップした場合、そのステージはエンタープライズ案件にのみ適用されるか（エンタープライズのみに追加）、または実際のマイルストーンではありません（削除）。

よくある失敗

観察可能な事実ではなく担当者の判断が必要なステージ。 「強い関心」はステージではありません。「購買者がQ2予算と45日間の評価ウィンドウを確認した」はステージです。

短いサイクルに対して多すぎるステージ。 14日間のSMB案件に8つのステージがあると、案件はほぼ1日おきにステージを移動します。担当者はそれを維持しません。PipelineはPipelineの中にあるものではなく、レポートの演習になります。

ステージ設計に担当者を関与させない。 担当者がステージ構築に参加しなかった場合、信頼しません。ステージ定義を確定する前に、最優秀担当者2〜3名とワーキングセッションを開催してください。

会話ではなくCRMのために設計する。 ステージ定義は担当者とマネージャーの案件レビュー会話で有用であるべきです。マネージャーが「これはステージ4ですか？」と尋ねて、担当者が基準を調べなければならない場合、ステージは複雑すぎます。

次のステップ

ドラフトのステージを取り、1人の担当者を選んで実際の案件で30日間パイロット実施してください。まだチーム全体を移行しないでください。パイロット担当者に参入・退出基準を意識的に使用してもらい、うまくいかない場合をフラグ立てしてもらいます。

30日後、新しいステージを使用したパイロット担当者の予測精度と古いステージを使用した残りのチームを比較してください。パイロット担当者の予測が実際のクローズに近ければ成功です。そうでなければ、まだ修正すべき設計上の問題があります。

ステージが安定した後、次のステップはワークフローオートメーションです。案件がステージ間を移動するときに発動するオートメーションを構築し、担当者が自動的にタスクを受け取り、マネージャーが手動追跡なしにアラートを受け取れるようにしてください。

CRM Implementation Guide