← エピソード一覧に戻る Episode 237 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS のエクスパンション連携です。Benchmarkit の 2025 調査では、既存顧客からの Expansion ARR が総新規 ARR の 40% を占め、ARR 50Mドル超の企業では半分を超えました。もう新規だけで伸ばす時代ではないんです。
ミカ
40%ですか。しかも大きい会社ほど既存顧客の伸びが主役になるなら、CS は『解約を防ぐ係』だけでは済まないですね。むしろ営業と一緒に売上を作る前線に近い感じがします。
タカシ
その通りです。ただし、CS が直接売るかどうかより重要なのは、価値実感の兆候を誰が見つけ、誰が商談化し、誰が forecast に載せるかを決めることです。今日はその連携の型を整理します。
ミカ
なるほど。『アップセルを頑張ろう』だと雑すぎて動けないけど、発見、提案、クロージングの流れに分けると経営の設計問題として見えてきますね。
Chapter 2 なぜ連携が必要なのか
タカシ
Gainsight と RevOps Squared の調査が象徴的です。CS は 72% の会社で拡張機会の特定に関わっているのに、実際に closing responsibility を持つのは 17% しかありません。見つける人と決める人が分かれているんですね。
ミカ
それ、現場だと『良さそうなお客さんがいたのに、いつの間にか流れた』が起きそうです。CS は温度感を知っているのに、営業はその背景を知らないまま提案してしまう、みたいな。
タカシ
まさにそこです。さらに Gainsight の Evolution of Customer Success Report では、CSM の 79% が renewals と existing customer expansion の両方に紐づく評価を受けています。責任は増えているのに、運営が曖昧だと摩擦が増えます。
ミカ
評価だけ先に乗ってくると苦しいですね。『数字は持ってね、でも案件の定義や handoff は自分で考えてね』だと、部門間で気まずくなる未来しか見えません。
タカシ
だから経営が決めるべきは、CS が Customer Success Qualified Lead を上げる条件、Sales か AM が提案に入る条件、RevOps が記録するステージです。善意ではなく、台帳で連携する必要があります。
Chapter 3 どう設計すると機能するか
ミカ
では、CS は何を見て『この顧客は広がる』と判断すればいいんでしょう。ログイン回数が増えた、だけだと雑だし、担当者の感覚だけでも危ないですよね。
タカシ
おすすめは五つあります。席数利用率の上昇、新部門の利用開始、上位機能の試用、管理者からの権限相談、そして業務成果の言語化です。最後の『成果が言える』は意外と重要で、価値が言語化できる顧客ほど広がりやすい。
ミカ
なるほど。使っているだけじゃなくて、『他部署にも効きそう』『この機能にお金を払う理由が説明できる』まで見えて初めて expansion 候補なんですね。
タカシ
その通りです。もう一つ大事なのは、更新 90 日前まで待たないことです。価値が出た瞬間に仮説を立て、QBR や EBR で『次にどの部門へ広げるか』を顧客の目標と結びつけて話す。更新直前の提案はたいてい遅いです。
ミカ
確かに、更新月に急に上位プランを出されたら売り込みに見えますよね。先に成果を確認して、その延長として広げるなら、顧客も話を聞きやすそうです。
Chapter 4 うまく回る会社の事例
タカシ
Apollo.io は分かりやすい事例です。Vitally を Customer Success、Onboarding、Sales、Product、Leadership の共通基盤にし、upsell と cross-sell の Opportunity Indicators を自動化しました。さらに 140 の Playbook automation で現場の手作業を削っています。
ミカ
部門ごとに別の表を見ていたのをやめたわけですね。それなら『CS は熱いと言ってるけど営業は知らない』みたいなすれ違いが減りそうです。
タカシ
結果も出ています。Apollo は増員なしで同じ成果を回しつつ、expansion goal を四半期の最初の 1 か月で達成しました。仕組みがあると、勘の良い CSM だけに依存しなくて済むんです。
ミカ
いいですね。ヒーロー社員頼みじゃなくて、だれが担当でも拡張機会を拾える状態に近づく。経営としてはそこが一番ほしいはずです。
タカシ
Affise も参考になります。ChurnZero で拡張属性の Segments と Alerts を作り、複数アカウント利用などの buying signals を拾えるようにした結果、CLTV は前年の 2 倍、既存顧客内で 21 business units へ展開し、churn は 2% 未満まで下がりました。
ミカ
拡張と churn 低下が同時に起きているのが面白いですね。押し売りで売上を増やしたというより、ちゃんと広がる顧客を見つけて価値を深くした結果に見えます。
タカシ
公開企業の Snowflake も示唆的です。Q4 FY25 の Net Revenue Retention Rate は 126% でした。利用量が増えるほど契約価値も増える pricing と、顧客価値の拡大を捉える運営が噛み合うと、既存顧客だけで強い成長が作れます。
Chapter 5 失敗パターンと明日からの一歩
ミカ
逆に危ないのは、更新月にだけ値上げ提案をする会社、owner が曖昧な会社、そしてインセンティブだけ付けて運営を作らない会社、あたりでしょうか。
タカシ
その三つは典型です。加えて、顧客の KPI と関係ない機能を押し込むのも危険ですね。短期 upsell は取れても、長期では価値未実感から churn を招きます。拡張は単価アップではなく、成果拡大の延長であるべきです。
ミカ
売ること自体が悪いんじゃなくて、『なぜ広げるのか』を顧客の成果で説明できないのが危ないんですね。経営者としては、その説明ができる案件だけを pipeline に載せたいです。
タカシ
明日からの一歩は四つです。Expansion ARR と NRR を毎月並べる。CSQL の定義を決める。CS、Sales、RevOps の役割を一枚にする。商談化しなかった拡張候補も理由を残す。この四つだけで連携の精度はかなり上がります。
ミカ
今日は、既存顧客の拡張は営業の追加仕事ではなく、価値実感を起点にした全社運営だと分かりました。次に upsell を見たら、提案資料より先に『その価値、もう出ている？』と確認したくなりそうです。
タカシ
その視点が大事です。売って終わりでは NRR は伸びません。顧客の成果が見えた瞬間に、次の広がりを設計する。これが SaaS CS のエクスパンション連携です。それでは、また次回。