Sales Process Playbook
顧客が実際に購買する方法に合ったPipelineステージの設計
ミッドマーケットのSaaS企業のVP of Salesがボードミーティング前にPipelineレポートを引き出したところ、「提案送付済み」に22件の案件がありました。自信を持って会議室に入りました。取締役会が各案件の予算確認について質問しました。担当者に電話しました。判明したのは:それら7件の案件では実際の予算の会話が一度もなかったということです。提案は出ていましたが、購買者は意思決定からはほど遠い状態でした。Pipelineは活動で満ちていて、進行状況ではありませんでした。
「デモ予定」はPipelineステージではありません。カレンダーの予定です。「提案送付済み」はPipelineステージではありません。タスクの完了です。それでもほとんどのCRMは、購買者が実際にどこにいるかではなく、営業担当者が何をしたかを説明する活動ベースのステージで埋まっています。結果は健全に見えるPipelineと30〜40%外れた予測です。
修正には外から内へステージを再構築する必要があります。内部の営業活動の代わりに観察可能な購買者マイルストーンを使用します。
ステップ1:営業プロセスではなく購買者の意思決定の旅程をマッピングする
現在のPipelineを完全に無視することから始めてください。ホワイトボードまたはスプレッドシートを取り出して、購買者が実際に契約署名前に何を通過するかをマッピングしてください。
クローズした最後の10件の案件を考えてください。各フェーズで購買者は実際に何をしましたか?
| 購買者のアクション | 観察可能なシグナル | 潜在的なステージゲート |
|---|---|---|
| 解決に値する問題があることを認識する | ディスカバリーコールを予約し、具体的なペインでディスカバリーの質問に回答した | 問題確認済み |
| ソリューションを評価することを決定する | 製品デモに同意し、2番目のステークホルダーを巻き込んだ | 積極的に評価中 |
| 技術チームと検証する | ITまたはセキュリティチームがコールに参加した | 技術評価 |
| 社内のビジネスケースを構築する | 価格、ROIテンプレート、または契約の法的レビューを要求した | ビジネスケース活性化 |
| 意思決定プロセスが始まる | 調達が関与、法的なマークアップを受け取った、経済的バイヤーから口頭での同意を得た | 決定進行中 |
| 契約レビュー中 | MSA進行中、法的なRedlineが交換されている | 契約レビュー |
このエクササイズから生まれるステージは「ディスカバリー」「デモ」「提案」「交渉」とは異なります。それらは購買者が実際に行うことに基づいており、各々を確認できます。
ステップ2:参入基準を観察可能な事実として書く
これがPipeline設計で最も重要なルールです:すべてのステージ参入基準は、解釈ではなく2人の異なる担当者が同意できる事実でなければなりません。
「エグゼクティブの賛同を得た」は観察可能ではありません。「CFOが3月10日に30分のコールに参加した」はそうです。「強い関心」は基準ではありません。「購買者が特定のユースケースのカスタムデモを要求した」はそうです。
参入基準を書く際に質問してください:案件ノートとCRM活動ログを見てこれが起きたことを確認できますか?答えに判断や推論が必要であれば、書き直してください。
良い参入基準の例:
- 「コンタクトが今年度の予算が存在し利用可能であることを確認した」
- 「少なくとも2人のステークホルダーがライブセッションに参加した」
- 「購買者が契約または価格の提案を要求した(概算だけでなく)」
- 「署名権限を持つ人物(経済的バイヤー)が名前で特定された」
弱い参入基準の例:
- 「見込み客が真の関心を示している」
- 「予算があると思われる」
- 「良い適合性が確認された」
これらのギャップは単に言葉の問題ではありません。弱い基準は異なる担当者が同じ案件を異なるステージに置くことを意味し、Pipelineレポートが虚構になります。
ステップ3:2担当者テストを使って退出基準を設定する
すべてのステージには退出基準も必要です:案件が進む前に真実でなければならない最小条件。
テスト:同じ案件を見ている2人の異なる担当者が次のステージに属することに同意しますか?答えが誰が聞いているかによる場合、基準は十分に具体的ではありません。
具体的な例。ステージが「口頭コミット」で退出基準が「購買者が購入に強い意図を示している」であれば、担当者は事実ではなく楽観主義に基づいて案件を進めるでしょう。「経済的バイヤーが録音されたコール、メール、またはCRMノートで『はい、進めたい』と言い、特定の意思決定日に同意した」と書き直してください。
これで案件を確認する誰もがその基準を満たしているかどうかを確認できます。
この2担当者テストは最も一般的なPipeline病をキャッチします:実際の進行状況ではなく勢いを示すために案件を進める担当者によるステージ膨張。
ステップ4:平均案件期間にステージ数を較正する
必要なステージ数はセールスサイクルがどのくらいかかるかによります。CRMを評価または導入中でもある場合、ステージ数の決定は初日から案件レコードとオートメーションルールをどのようにConfigurationするかに影響します。
30日未満のサイクル(典型的にはSMBやプロダクトリード営業)の場合、4〜5ステージで十分です。それ以上のステージは予測値を追加せずに管理上の摩擦を生み出します。
30〜90日のサイクル(ミッドマーケット)の場合、5〜7ステージが通常機能します。
90日以上のサイクル(エンタープライズ)の場合、7〜10ステージが意味をなすことがありますが、各ステージが購買者のコミットメントの意味ある変化を表す場合のみです。
有用なチェック:案件がステージを合理的にスキップできる場合、そのステージはPipelineに属さないかもしれません。すべてのステージはすべての案件が通過するべきものであるべきです。
ステップ5:誠実に勝率とのつながりを確立する
ここでほとんどのPipelineが2回目に間違えます。ステージ設計が完了した後、誰かが勝率を割り当てますが、データではなく直感または慣習に基づいて行います。
結果:「提案送付済み」がすべての案件で50%の確率が割り当てられます。しかし履歴データを実際に見ると、「提案送付済み」の案件は提案が出る前に予算が確認されたかどうかによって25%または70%でクローズするかもしれません。
勝率は直感ではなく、ステージ別の履歴クローズ率から来るべきです。直近50件のクローズウォンとクローズロスト案件を引き出して計算してください:
- ステージXに達したすべての案件のうち、何パーセントがクローズしましたか?
- それは案件サイズ、Industry、または担当者によって変わりますか?
「提案送付済み」がデータで28%でクローズするなら、28%に設定してください。50%ではありません。膨らんだ確率で重み付けされたPipelineは実際よりも良く見え、予測が意味をなさなくなります。
ステップ6:20件の履歴案件に対して新しいステージをテストする
新しいPipeline設計を立ち上げる前に、20件の履歴のクローズウォンとクローズロスト案件を通して実施してください。
案件ノート、メール、CRM活動ログを引き出してください。新しいステージ基準を適用して尋ねてください:この案件は各ステージにいつ進んだと思われますか?どこで停滞しましたか?どこで資格を失いましたか?
この回顧的監査は3つのことを行います:
- 参入基準が実際に案件がどのように動くかと一致しているかを明らかにします。
- クローズロストのパターンを浮上させます。10件の失注案件のうち8件が同じステージで同様の理由で停滞した場合、それはそのステージでのプロセスの失敗です。
- 前後の比較を提供します。新しい基準を使って現在のPipelineのすべてのアクティブな案件を再分類してください。案件の40%が「提案」から前のステージに移動する場合、Pipelineは膨らんでいました。
ステップ7:立ち上げ前に担当者のサインオフを得る
世界最高のPipeline設計も担当者が一貫して使用しなければ失敗します。最悪の結果は抵抗ではありません。静かな非遵守です。担当者が正確よりも良く見えるステージに案件を進めます。
立ち上げ前に、営業チームで30分のワーキングセッションを開催してください。新しいステージを完成品として提示しないでください。ほぼ最終ドラフトとして持参し、インプットを求めてください。
最も価値あるフィードバックを浮上させる質問:
- 「案件がステージXを合理的にスキップするシナリオはありますか?」
- 「ステージYの参入基準は30秒で確認できるものですか?」
- 「勝率の割り当てに同意しないものはありますか?あなたの経験は何を示唆していますか?」
Pipeline設計の形成に参加した担当者は、それを手渡された担当者とは異なる方法でそれを適用します。その30分の会話は次の12か月のデータ品質に効果をもたらします。
よくある失敗
担当者の解釈を必要とするステージ。 「明らかに」「強い」「真の」という言葉を含む参入基準はすべての担当者によって異なって解釈されます。判断の呼びかけを検証可能な事実に置き換えてください。
クローズロストのタクソノミーをスキップする。 Pipelineステージには対応するクローズロストの理由のタクソノミーが必要です。まだ構造化された失注案件レビューを実施していない場合、ここで構築するタクソノミーはそれらのレビューを有用にするものです。「競合他社に負けた」「予算なし」「タイミング」のような失注理由では何も学べません。
内部ドキュメントにちなんだステージ名。 「契約送付」と「MSA送付」はあなたのプロセスを説明し、購買者の状態を説明しません。購買者の状態に改名してください:「法的レビュー進行中」または「相互レビュー中の契約」。
短いセールスサイクルに対して多すぎるステージ。 平均的な案件が18日でクローズする場合、8つのステージは担当者が週に2回ステージを更新することを意味します。それはオーバーヘッドで、シグナルではありません。
次のステップ
1つのチームまたは1つの案件セグメントで再設計されたPipelineをパイロット実施してから、組織全体に展開してください。3つの指標を追跡してください:
- 予測精度:期間の予測されたクローズは15%以内の実際のクローズと一致しましたか?
- ステージ進行の不一致:マネージャーが担当者のステージ割り当てに反論した頻度は?
- クローズロストの明確さ:Pipelineのどこで各失注案件が実際に崩壊したかを特定できますか?
パイロットが3つすべての改善を示せば拡大してください。予測精度が改善しなかった場合、再設計する前に参入基準と勝率の割り当てを確認してください。
