← エピソード一覧に戻る Episode 258 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
皆さんこんにちは、タカシです。今日は SaaS RevOps の基礎中の基礎、ライフサイクルステージを扱います。実はここが曖昧な会社ほど、マーケは渡したと言い、営業は質が悪いと言い、CS は情報がないと言い始めます。数字を見ているのに会話が噛み合わない、その原因がここにあるんです。
ミカ
ありますね、その会議。みんな同じ CRM を見ているはずなのに、言っていることが微妙に違う。ライフサイクルステージって、正直 CRM の項目名くらいに思っていたんですが、そんなに重いテーマなんですか。
タカシ
かなり重いです。HubSpot Academy も lifecycle stages を CRM 戦略の backbone と呼んでいて、部門横断で定義、トリガー、運用、レポート、定着まで作るべきだと教えています。つまり属性ではなく、会社全体の状態遷移図なんですね。
ミカ
なるほど。名札じゃなくて、顧客が今どこにいて、次に誰が何をするかを決める地図なんだ。今日はその地図をどう描くか、SaaS ならではの考え方まで知りたいです。
Chapter 2 SaaS でステージ設計が重くなる理由
タカシ
Winning by Design の Bowtie Standard では、顧客旅程を Awareness、Education、Selection、Mutual Commit、Onboarding、Retention and Adoption、Expansion の七段階で見ます。重要なのは、契約後まで同じデータモデルで追うことです。SaaS は受注のあとに収益の本番が来るからです。
ミカ
たしかに、契約した瞬間に売上が全部確定する商売じゃないですもんね。オンボーディングで詰まれば更新に響くし、活用が進めば拡張も起きる。営業だけのステージでは足りない理由が見えてきました。
タカシ
その通りです。だから lifecycle stage と opportunity stage は分ける必要があります。RevOps Co-op も、営業の案件進捗と、会社全体の顧客状態を同じフィールドに押し込むと壊れると指摘しています。前者は売り方、後者は経営の共通言語なんです。
ミカ
ここ、混ぜがちですね。案件は前に進んでいるのに、アカウント全体ではまだ教育段階とか、逆に契約はしたけど活用が止まっているとか、同時に起きますもんね。一列の表現では足りないわけだ。
Chapter 3 具体例で見るステージ運用
タカシ
HubSpot の事例では、SaaS 企業 iAdvize が lifecycle stage に応じて smart CTA と smart list を切り替え、marketing の履歴を sales と共有し、sales-qualified lead への handoff を明確化しました。その結果、リードは 4 倍、営業サイクルは 50パーセント短縮しています。
ミカ
すごいですね。コンテンツを出し分けただけじゃなくて、どの状態になったら sales に渡すかが見えたから、マーケの努力が営業の生産性につながったんだ。handoff の設計が数字に直結している例ですね。
タカシ
OpenPhone も参考になります。五万社超の顧客基盤を前に、trial 利用の深さと firmographic fit で PQL を定義し、sales-ready な顧客だけを上位ステージへ上げる運用に変えました。結果は conversion が 10パーセント向上、ACV が 32パーセント向上、さらに担当者の週 13時間削減です。
ミカ
面白いのは、ただ選別して終わりじゃないところですね。OpenPhone は既存顧客も Grow、Defend、Maintain に分けて見ているから、拡張の芽と解約リスクを同じ基盤で追える。ライフサイクルステージって、営業よりむしろ会社全体の優先順位づけなんだ。
Chapter 4 失敗パターンと見落とし
タカシ
よくある失敗は五つあります。ステージを増やしすぎる、lifecycle と案件進捗を混同する、customer をゴールにする、recycle 条件がない、そして owner と SLA がない。このどれかがあると、立派な定義書があっても現場では回りません。
ミカ
ステージを細かくしすぎるのは、すごく分かります。あれもこれも見たくて増やした結果、入力者が迷って結局更新されない。経営が欲しいのは百科事典じゃなくて、次の一手が決まる粒度なんですね。
タカシ
その通りです。Intercom は retention から逆算して、setup、activation、utilization、maturity の milestone を定義していますし、Keen では onboarding 中の適切な支援で顧客満足度が 30パーセント向上し、churn が 0.5パーセント下がりました。契約後の状態を粗く扱うコストは大きいんです。
ミカ
受注したから安心、は SaaS だと危ないわけですね。first value まで行けたか、使い続けているか、更新に不安はないかを追わないと、売上は取れても事業の筋肉はつかない。customer の後ろを粗くすると後で効いてきそうです。
Chapter 5 明日からの実務
タカシ
明日から始めるなら、まず person と account のどちらで追うかを分けて、主要ステージを七から十個に絞ること。次に各ステージの entry 条件、exit 条件、owner、必要データ、SLA を一枚にまとめること。この二つだけで会議のズレはかなり減ります。
ミカ
その時に、customer の後ろ側も忘れない、と。オンボーディング、adoption、renewal risk、expansion を補助指標として見える化して、月次で conversion や velocity を見直す。定義して終わりじゃなく、運用しながら磨く必要があるんですね。
タカシ
ええ。ライフサイクルステージの本質は、顧客をラベル分けすることではありません。どの状態の相手に、誰が、何を、どれだけの速度で届けるかを揃えることです。そこが揃うと、マーケ、営業、CS、財務が同じ未来を見ながら動けるようになります。
ミカ
今日は SaaS RevOps のライフサイクルステージを見てきました。CRM の項目に見えて、実は会社全体の意思決定速度を決める土台だったんですね。皆さんの会社でも、まずは customer の前後で言葉が揃っているか、ぜひ見直してみてください。