追ってからでは救えない ― SaaS CS の解約予防

今日は SaaS CS の解約予防です。驚く数字から入ると、Gainsight と Staircase AI の調査では、解約した顧客の 51% が大きな予告もなく突然キャンセル通知を出していました。つまり、危なくなったら教えてくれる前提はかなり危ないんです。

その通りです。解約予防は、更新月の説得術ではありません。価値が落ち始めた瞬間、関係者が弱り始めた瞬間を先に見つけて、運営で手を打つ仕組みです。今日はその見方と実務の型を整理します。

まず、解約率を件数だけで見ないことです。Gainsight の churn guide でも、何社減ったかという logo churn と、いくら失ったかという revenue churn を分けて追うべきだと整理しています。大口 1 社の離脱は、小口数社よりはるかに重いからです。

そして、解約予防はアンケート待ちではありません。同じ調査では、更新した顧客は解約した顧客より QBR 実施回数が 2 倍多く、エンゲージメントも高かった。つまり、防ぐ鍵は『不満を聞く』より前に『価値を一緒に確認し続ける』ことなんです。

まさにそうです。さらに見るべきは利用低下だけではありません。複数接点を持てていたのは、解約顧客では 33%、更新顧客では 64% でした。担当者が一人だけ、しかもその人が異動した、という状態は典型的な赤信号です。

おすすめは五つです。ひとつ目がコア機能の利用低下。二つ目が QBR や定例の未実施。三つ目がチャンピオンや決裁者の変化。四つ目がサポート悪化。五つ目が更新接近です。これを別々の表ではなく、一つの at-risk 定義にまとめます。

そうです。もうひとつ大事なのが、全部を高タッチで救おうとしないこと。低 ACV まで人手で抱えると、本当に守るべき大口に時間がなくなります。SMB は自動アラートと教育、戦略顧客は人が入る、という切り分けが必要です。

具体例を見ましょう。data.world は Gainsight の Risk CTA と Scorecard を軸に、毎週の Tiger Team で危険顧客を横断レビューする形に変えました。その結果、導入後の四半期で更新失注をゼロにし、年間では ARR の 15% 相当のリスクを緩和しています。

Cin7 も示唆的です。オンボーディング後のつまずきに条件分岐付きの play を差し込み、必要なら追加支援へつなぐ設計に変えたところ、四半期ベースで churn を 60% 減らしました。更新直前より、立ち上がり直後のほうが効くわけです。

Navattic も同じ流れです。Vitally で QBR と更新プロセスを標準化した結果、2023 年後半は前半比で月次 churn が 20% 低下し、time to go live も 30% 短縮しました。早く立ち上がり、定例で価値を確認するほど、解約は減るんです。

その三つは典型です。加えて、解約理由を『価格でした』で閉じるのも危険ですね。表面は予算でも、その前に価値未実感や社内浸透不足がある。失注後インタビューと改善 backlog までつながないと、同じ churn を繰り返します。

明日やることは三つです。まず logo churn と revenue churn を分けて見る。次に、利用低下、QBR 未実施、チャンピオン離脱を一枚の at-risk 定義にする。最後に、週次で CS、Sales、Support が危険顧客を見直す場を作る。解約予防は、お願い営業ではなく早期警戒の運営です。