← エピソード一覧に戻る Episode 231 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS のリスクアカウント管理です。Gainsight の data.world 事例では、Risk CTA と Scorecards を整えた四半期に更新売上の損失をゼロにし、年間では ARR の 15 パーセント相当のリスクを緩和しました。守りの運用に見えて、実はかなり経営ど真ん中のテーマなんです。
ミカ
リスクアカウント管理って、危ない顧客を赤で並べる作業だと思っていました。でも ARR の 15 パーセントが動くなら、かなり重いですね。今日は、何を見て危険と判断し、どう動けば手遅れを防げるのか知りたいです。
タカシ
結論から言うと、リスクアカウント管理は顧客を赤く塗ることではありません。異変を早く見つけ、どの部門が何をするかを決める運営です。SaaS は問題が表面化した頃には更新まで時間がなく、説得より先に介入設計が必要になるんですね。
ミカ
なるほど、通知表というより早期警報システムですね。今日は、どういう信号を拾うのかと、CS だけで抱え込まない運用の組み方を中心に聞かせてください。
Chapter 2 何をもってリスクとみなすか
タカシ
Gainsight は at-risk account を、介入しなければ更新より解約の可能性が高い顧客と説明しています。大事なのは、問題が起きてからではなく、起きる前の兆候を見ることです。同社の A.R.T. モデルでは、Absolute、Relative、Trend の三方向で異変を捉えます。
ミカ
A.R.T. は覚えやすいですね。でもそれぞれ何を見るんですか。単月の利用低下だけで赤にすると、季節変動の大きいサービスでは誤報だらけになりそうです。
タカシ
そこが肝です。Absolute は『48 時間ログインがない』『導入マイルストーン未達』のような閾値。Relative は同規模顧客や同業平均との比較。Trend は数週間から数か月の悪化傾向です。単発異常と継続劣化を分けるので、ノイズを減らしつつ隠れた危険を拾えます。
ミカ
同じ赤でも意味が違うわけですね。設定が遅れている赤、スポンサーが抜けた赤、利用が落ちている赤を一緒にすると、結局『で、誰が何をするの』で止まりそうです。
Chapter 3 リスク理由ごとに動かす
タカシ
まさにその通りで、先進企業は理由別に管理します。Totango の Detect Risk は champion loss、leadership change、competitive threat、support tickets 増加、license utilization 低下、支払い遅延、低 NPS など、理由ごとの SuccessPlay を最初から持っています。
ミカ
危険度を一本の点数で見るより、『何が原因か』で playbook を変えるわけですね。たしかにスポンサー離脱とバグ多発では、CSM が送るメールも呼ぶ人も全然違います。
タカシ
さらに Gainsight の実例では、実装遅延は Services、重大バグは Engineering、会社都合の再編やスポンサー離脱は CS など、カテゴリごとに owner を置いています。リスクアカウント管理は CS の孤独な頑張り大会ではなく、全社で責任を分ける設計なんです。
ミカ
ここを曖昧にすると、会議で『プロダクト課題ですね』『でも窓口は CS ですよね』とボールが浮くんですよね。リスク管理というより、責任の所在管理でもあるわけだ。
Chapter 4 事例で見る運用の差
タカシ
data.world は Risk CTA と Scorecards を整えたことで、導入後の四半期に Zero Renewal Revenue Lost を達成しました。年間でも ARR の 15 パーセント相当のリスクを緩和しています。重要なのは、CS だけでなく全社が『どのリスクがいくらの売上に響くか』を同じ言葉で見られるようになった点です。
ミカ
それは強いですね。感覚的に危ない、ではなく、金額付きで危険が見えるから、上の意思決定も速くなる。経営会議で扱える形に翻訳されているわけですね。
タカシ
ChurnZero 系の事例も面白いです。Cofense は renewal hot list を作って三週間ごとにレビューし、Sales へ週次で health、usage、sentiment を渡し、危険度上昇は Slack で即時共有しています。Birdie は onboarding health が赤になった顧客に標準フローを当て、危なかった SME を 70 パーセント近く救いました。
ミカ
更新会議と Slack と playbook がつながっているんですね。しかも Birdie の 70 パーセント救済を見ると、リスク管理は大口顧客だけの話ではなく、ロングテールを少人数で守る仕組みでもあると分かります。
タカシ
HackerRank はさらに分かりやすく、利用量が 25 パーセント以上落ちたらアラートと Play を自動発火させました。その結果、立ち上げ三か月で at-risk 顧客の churn を 50 パーセント減らし、 account coverage も 4 倍に増えています。勘ではなく運用にした強さですね。
Chapter 5 失敗パターンと明日からの実践
ミカ
逆に失敗するのはどんな会社ですか。週次で赤い顧客一覧は見ているのに、四半期末になると突然解約が出る会社って、何を外しているんでしょう。
タカシ
典型的には五つです。赤い顧客を並べるだけで理由別 playbook がない。CS だけで抱える。更新直前だけ見る。単発数値だけで判断する。スポンサー離脱や請求遅延のような定性シグナルを捨てる。このどれかがあると surprise churn が起きやすくなります。
ミカ
たしかに、赤信号の件数管理だけだと運用ではなく観察日記ですね。『なぜ危ないか』『誰が受け持つか』『いつまでに何をするか』がないと、安心のためのダッシュボードになってしまいそうです。
タカシ
明日からやるなら、まず implementation、support、sponsor、commercial、usage などのリスクカテゴリを分けて owner を決める。次に renewal date、ARR、risk reason を一画面で見られる hot list を作る。最後に検知から介入までの日数と救済できた ARR を毎月見直してください。これが運用化の入口です。
ミカ
今日は、リスクアカウント管理は赤い顧客リストではなく、継続売上を守るための指揮系統だと分かりました。皆さんもまず、自社でよく起きるリスク理由を三つだけ決めて、理由別の打ち手を作るところから始めてみてください。それではまた次回。