← エピソード一覧に戻る Episode 235 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS の更新マネジメントです。更新って、契約満了日に判子をもらう仕事だと思われがちですが、それだと遅い。Planhat は更新を顧客価値の総決算だと整理しています。つまり更新率は、最終月より一年の運営で決まるんです。
ミカ
確かに『更新月だから何かしよう』って言い出した時点で、もうだいぶ危なそうです。お客さんの中では、続けるかやめるか、かなり前から空気ができていますよね。
タカシ
その通りです。Gainsight も、解約の原因として『更新を日付としてしか見ていないこと』を挙げています。更新はパイプラインです。オンボーディング、活用定着、QBR、関係者の合意、商務処理まで一本で見ないと外します。
ミカ
なるほど。営業の締め作業じゃなくて、継続売上を作る運営そのものなんですね。今日は、いつ何を管理すれば『更新が自然に決まる状態』になるのかを知りたいです。
Chapter 2 更新は誰の仕事なのか
タカシ
まず大事なのは ownership です。Planhat は、CS が価値実現、活用、ヘルス、QBR、チャーン予防を持ち、Sales や AM が契約条件、調達、価格交渉、最終署名を持つ設計を推しています。全員が見る、は大体誰も責任を持ちません。
ミカ
そこ、現場で曖昧になりがちですよね。お客さんとの関係は CS が持っているけど、値引きや契約は営業。なのに引き継ぎの瞬間だけ『誰がいつ何を言うの』がぼやける。
タカシ
ChurnZero の 2023 年調査では、1,200 人超の CS リーダー回答で、更新 ownership は年々少しずつ移り、専任の renewals team が増えています。ここで見えるのは、更新率を上げるには『良い関係』だけでなく、運営の役割定義が必要だということです。
ミカ
確かに、曖昧な善意より、明確な役割分担ですね。恋愛なら曖昧さも味ですが、更新管理でそれをやると forecast が壊れそうです。
Chapter 3 いつから動くべきか
タカシ
更新に強い会社は、満了日から逆算して三つの山を置きます。Planhat の型だと Day 90 が health check と社内方針合わせ、Day 60 が ROI と business outcome に絞った QBR、Day 30 が commercial conversation です。
ミカ
Day 60 で価値を証明して、Day 30 では価格や契約の話に集中するんですね。逆にここが一緒になっていると、価値が曖昧なまま『少し安くできますか』の話だけが残りそうです。
タカシ
その通りです。しかも本当の開始点は Day 90 より前です。Swoogo は以前、更新の 90 日前から監視していましたが、今は顧客参加後の早い段階から全アカウントを forecast しています。更新直前に初めて赤信号を知る運営をやめたわけです。
ミカ
つまり『更新準備は 90 日前から』ではなく、『90 日前には勝ち筋が見えている状態にする』が正しいんですね。言い方が変わるだけで、やることがかなり変わります。
タカシ
まさにそこです。Gainsight も recurring revenue は請求日に動くのではなく、オンボーディング、活用、QBR、更新準備の各瞬間で動くと説明しています。更新月だけ頑張るのは、期末だけ勉強して一年の成績を上げようとするようなものです。
Chapter 4 何を見れば更新を読めるのか
タカシ
更新管理で見るべきなのは、満足度の一枚絵ではありません。Gainsight の分析では、機能利用の breadth、DAU 比率、そして適切な support interaction が renewal の先行指標になり得ると出ています。使っていない静かな顧客は、健康とは限らないんです。
ミカ
サポート問い合わせが少ないと安心しがちですけど、実は『使っていないから聞くこともない』かもしれないんですね。静かなお客さんほど怖い、というやつだ。
タカシ
加えて stakeholder の変化も重要です。導入責任者が異動した、決裁者が変わった、 champion が弱った。こうした情報を usage や support と一緒に見ないと forecast は外れます。更新率は感覚より、複数信号の重ね合わせで読むものです。
ミカ
なるほど。ログ、感情、関係者、契約時期を別々の表で持っていたら危ないですね。更新管理って、実は『情報が一つの台帳に戻るか』の勝負でもあるんだ。
Chapter 5 うまく回る会社の実例
タカシ
Acquia は Gainsight で価値訴求と更新リマインドを標準化し、更新率を平均 12 ポイント改善しました。Swoogo もヘルスと forecast を早期からつなぎ、初年度で GRR を 7 ポイント改善しています。更新率は根性ではなく運営で上がる、という好例です。
ミカ
どちらも共通しているのは、更新月のお願い営業ではなく、もっと前から価値の確認とリスク検知を仕組みにしている点ですね。属人的な神対応より、再現できる運営のほうが強い。
タカシ
Apollo.io の事例も示唆的です。Vitally 上で 140 の playbook automation を動かし、CSM が更新や expansion の兆候をリアルタイムで追えるようにした結果、NRR と ARR が改善し、四半期の expansion 目標を初月で達成しました。更新運営は拡張運営と地続きなんです。
ミカ
更新だけ守るんじゃなくて、価値が見えている顧客はそのまま拡張にもつながるんですね。更新会議が守りの場だと思っていましたけど、実は攻めの起点でもあるんだなあ。
タカシ
その視点が大事です。明日からは、まず自社の更新案件に Day 90、60、30 の型があるか、次に CS と Sales の責任境界が文章で決まっているか、最後に health と stakeholder 変化が forecast に反映されているかを点検してください。更新は満了日の仕事ではありません。それではまた次回。