← エピソード一覧に戻る Episode 205 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS 営業のステージ定義です。地味に見えますが、ここが曖昧だと売上予測も採用計画も全部ぶれます。Ebsta の分析では、qualification criteria を stage 2 の終わりまでに満たした案件は、71 パーセント成約しやすかったんです。
ミカ
71 パーセントは大きいですね。正直、ステージって CRM の列名くらいに思っていました。商談が動いたら何となく次へ送る、みたいな運用でも回るのかなと。
タカシ
そこが危ないんです。ステージ定義は列名ではなく、案件が前に進んだと見なす証拠の定義です。営業がメールしたかではなく、顧客が何を確認し、何に合意したかで切らないと、前進した気分だけが増えていきます。
ミカ
なるほど、売り手の作業記録ではなく、買い手側の前進を測るんですね。今日は『なぜ経営に効くのか』までつながる形で知りたいです。
Chapter 2 ステージ定義は何をそろえるのか
タカシ
Insight Partners は、成熟した営業組織ほど各ステージに clear exit criteria を置き、それを verifiable outcomes で裏づけると整理しています。Clari も、progress criteria を文書化しないとパイプラインが混乱すると述べています。
ミカ
verifiable outcomes というのは、確認できる事実ってことですね。『感触はいい』ではなく、『決裁者が誰か分かった』『次回会議が入った』みたいな、誰でも見て判定できるもの。
タカシ
その通りです。ステージ定義の役割は三つあります。ひとつ目は案件レビューの共通言語を作ること。ふたつ目は forecast の前提をそろえること。三つ目は、どこで詰まっているかを再現可能に見つけることです。
ミカ
つまり、営業マネージャーが『その案件ほんとに proposal なの』と毎回口論しなくて済む世界ですね。経営会議でも数字の解釈がそろうから、だいぶ健全そうです。
Chapter 3 公開事例で見る良い定義
タカシ
実務例として分かりやすいのが GitLab の公開 handbook です。Discovery を抜ける条件に、pain point、主要ステークホルダー、next step、project timeline を recap email で確認し、scoping meeting まで設定することを置いています。
ミカ
へえ、単に初回商談をやっただけでは次に行けないんですね。ちゃんと顧客理解を文書化して、相手も次の段取りを飲んでいることまで必要なんだ。
タカシ
さらに Proposal を抜けるには、mutual close plan に合意し、procurement process と implementation strategy を確認し、paper process も整理する必要があります。提案書を送った事実ではなく、社内稟議と導入準備が進んだ事実で判断しているわけです。
ミカ
これ、すごく SaaS っぽいですね。受注だけ見ていない。導入後にちゃんと始められるかまで見ているから、あとで『契約したのに動かない』も減りそうです。
Chapter 4 数字が示す失敗の構造
タカシ
Ebsta の 2023 年レポートでは、MEDDPICC を stage ごとに採点し、weekly pipeline review に組み込んだ物流企業が win rate を 23 パーセント改善しました。逆に必要な qualification が後半まで残ると、判断が遅れて商談は一気に不安定になります。
ミカ
つまり、案件を進めながら後で必要情報を埋める運用は危ないんですね。テスト勉強を試験前夜に全部やるみたいなもので、最後にまとめて痛みが来ると。
タカシ
その比喩、かなり正確です。2024 年版では、主要な objection が初期に出た案件の 77 パーセントが slip し、top performer は discovery で next step や会議を定義できる確率が 412 パーセント高いと出ています。初期の曖昧さは後半で利子つきで返ってきます。
ミカ
怖いですね。前半で聞きにくいことを避けるほど、後半で『予算がなかった』『決裁者が違った』『法務で止まった』がまとめて来るわけだ。
Chapter 5 よくある誤解と明日からの運用
タカシ
よくある誤解は、sales stage をそのまま forecast category に使うことです。Gong は、早いが勝てる案件を見落とし、遅いが危ない案件を含める原因になると指摘しています。進捗管理と成約確率は、似ていて別物なんです。
ミカ
あと、ルールを細かくしすぎるのも危なそうです。Balderton も、五つある条件のうち四つしか満たしていないなら、その案件はまだそのステージではないと書いていましたよね。
タカシ
そうです。明日からやるなら、まず 5 から 7 段階に絞り、各ステージに 3 から 5 個の buyer evidence だけ置くこと。weekly review では『次の証拠は何か』を確認し、未充足なら stage を戻す勇気を持つこと。この二つでかなり変わります。
ミカ
今日は、ステージ定義は CRM 整備ではなく経営の精度を上げる仕組みだと分かりました。皆さんも自社の案件一覧を見て、『そのステージだと言える証拠は何か』を一度問い直してみてください。それではまた次回。