多くの CS チームは、renewal が成立しなかったときに初めてアカウントが離脱しつつあると気づきます。その時点ではセーブの窓は何か月も前に閉じています。解決策はより良い health score ではなく、score が threshold を越えた瞬間に発火する固定された motion です。これにより CSM は renewal の前の最後の 30 日に反応するのではなく、低下の 1 週目に介入できます。この SOP がその motion です。trigger、診断ステップ、段階的な介入、エスカレーションのルール、そしてリスクのある全アカウントで同じように回る文書化の要件で構成されます。これは意図的に硬直的です。アカウントが赤になったときに各 CSM が正しい手を即興で出すことに依存するセーブの motion は、最高の CSM には機能し、ほかの全員には機能しない motion です。
artifact の bundle は apps/web/public/artifacts/churn-save-playbook-sop/ にあります。churn-save-sop.md(手順そのもの。Notion または Gainsight のナレッジベースに貼り付け可能)、save-plan-template.md(CSM がアカウントごとに記入する構造化されたセーブプランの doc)、slack-escalation-template.md(アカウントがエスカレートしたときに CSM が投稿する標準アラート)を同梱します。rollout の前に、3 つすべてを自社の score 名、セグメントの帯、チャンネルの慣習に合わせてください。
使うべきとき
Gainsight(または同等の CSP)で行動するに足る信頼を置いている health score を運用していて、アカウントが赤になったときに何が起きるかの書かれて enforced された motion をまだ持っていないとき、この SOP を使ってください。典型的な症状は、ある CSM がたまたま早期にそれを捉え、誰に電話すべきか知っていたために成功したセーブです。そして次の四半期に同一のアカウントが churn します。別の CSM が同じ赤い flag を見て QBR まで待ったからです。score は仕事をしています。score への応答こそ、これが埋める gap です。
定義された health score、CSM の book 構造、そしてエスカレーションのオーナーになれる CS リーダーを備えた、100 から 2,000 顧客の帯のチームに最も適します。~100 アカウント未満では CSM が各アカウントを直接読み、文書化された motion は overhead です。~2,000 を超えると、Slack の投稿と共有 doc ではなく、ネイティブの routing と SLA トラッキングを備えた Gainsight の CTA でセーブの motion を駆動したくなるでしょう。その規模では手作業のステップこそ飛ばされるものです。この SOP は、motion が重要だが playbook が人の頭の中に生きている帯で正しいツールです。
使うべきでないとき
自社の health score を信頼していないなら、これを採用しないでください。tagging のノイズや一度のログイン欠落で赤に発火する score によって駆動されるセーブの motion は、1 か月以内に CSM に trigger を無視するよう仕込みます。まず score を直してください。n8n のコンポジット health score と CS health score ビルダー はそのために存在します。そのうえでこの motion を上に乗せてください。ノイジーな trigger の上の精密な motion は motion なしより悪いです。行動してほしい唯一のシグナルに対するチームの信頼を焼くからです。
これを renewal フォーキャストのツールとして使わないでください。この SOP はセーブにスコープされています。健全だったが今は滑り落ちているアカウントで、目標は renewal に達する前に低下を反転させることです。どの CSM も動かせない理由で最初から離脱が決まっていたアカウント、つまり買い手が去った、会社が買収された、ユースケースが消えたアカウントはセーブの候補ではなく、motion に押し込むのは確定的な敗北に CSM の時間を浪費させます。診断ステップは、その判断を早期に下すために一部存在します。
エスカレーションを受け取る CS リーダーなしに回さないでください。エスカレーションの段は支柱です。要点は、重大度のラインを越えたアカウントが 1 人の CSM の問題であることをやめ、チームの問題になることです。エスカレーションが誰もオーナーでないチャンネルに流れるなら、motion は置き換えるはずだった同じ即興へと劣化します。
trigger
motion は Gainsight の score イベントで発火し、CSM の勘やカレンダーでは発火しません。2 つの trigger があり、どちらか一方が時計を始動させます。
- 赤への帯の低下 —コンポジット health score が黄から赤へ越える(リファレンスのスコアリングでは、コンポジットが 50 未満)。これが主要な trigger です。
- 帯の中での大きな負のデルタ —単一のスコアリングサイクルでの 15 ポイント以上の低下。アカウントが技術的にまだ黄であってもです。緑から中位の黄への落下は、安定した赤よりも鋭いシグナルであることが多いです。新しく、原因がまだ反転可能なほど最近だからです。
Gainsight はどちらかの条件で CTA を発火します。CTA の割り当ては担当の CSM です。SLA は、CSM が trigger から 2 営業日以内にセーブプランを開くことです。開始を週次レビューではなく score イベントに紐づけることが要点そのものです。レビューは再スケジュールされますが、SLA 付きの CTA はトラックされます。
motion
- 診断する(2 日目まで)。 いかなる outreach の前にも、CSM は
save-plan-template.mdの診断セクションを記入します。どの sub-score が動いたか(使用量、活動、sentiment)、具体的な数値とその baseline、そして原因の 1 行の仮説です。仮説は固定された集合の 1 つに強制されます。採用の停滞、champion の交代、価値の未実現、競合による置き換え、予算/経済、製品の gap です。原因のクラスが手を決めるからです。「彼らは不満そうだ」という診断は却下されます。CSM は sub-score と見込みのクラスを名指しするか、「原因不明、調査コールが必要」とマークします。 - 介入する(5 日目まで)、原因に応じて段階的に。 採用の停滞 → check-in ではなく、使われていない feature についてのワーキングセッション。champion の交代 → 何よりも先に新しい stakeholder をマッピングして勝ち取る紹介の motion。価値の未実現 → success plan と元の「なぜ買ったか」を引き出し、deal で定義した指標に対する価値レビューを設定。競合による置き換え → AE を巻き込み、正当なら即エスカレート。予算/経済 → CSM が単独でオーナーになれないかもしれない商談。製品の gap → 記録し、誠実に期待値を設定し、CSM が守れない roadmap の日付を約束しない。template はクラスごとに 1 つのデフォルトの手を載せているので、CSM は手を発明するのではなく、バリエーションを選んでいます。
- エスカレートする(重大度のラインを越えたとき)。 アカウントは次のいずれかで 1 人の CSM の motion の外へエスカレートします。赤であり、かつチームが設定する収益の threshold を超えている(例:上位四分位の ARR)、原因が競合による置き換え、またはセーブプランが帯の回復なく 30 日回った。エスカレーションは
slack-escalation-template.mdを使って#cs-savesに投稿します。アカウント、ARR、renewal 日、数値付きで動いた sub-score、原因クラス、これまでに回した手、そしてリーダーシップへの具体的な依頼です。CS リーダーは 1 営業日以内にスレッド内で承認し、依頼が値するなら exec sponsor または AE を割り当てます。 - 文書化する(継続的に、そしてクローズ時に)。 すべてのセーブプランは、trigger、診断、手、そして結果 —セーブ、churn、ダウングレード— を原因クラスに紐づけて記録します。これが複利になる motion の半分です。四半期後には、自社が実際にセーブできる原因クラスとできないクラスを読み取り、セーブ可能なものに CSM の時間を再び向けられます。文書化されないセーブはチームに何も教えません。
成功とは
4 つの数値を追ってください。第一に、trigger から最初の接触までの時間 —Gainsight の CTA が発火してから最初に記録されたセーブ行動までの日数。2 営業日の SLA は 1 か月以内に中央値を 2 日未満へ引き下げるはずです。それより長い遅れは、CTA が誰も作業しないキューへ発火していることを意味します。第二に、原因クラス別のセーブ率 —motion に入ったアカウントのうち、黄以上に回復して renewal した割合を、診断された原因で分けたもの。これが motion がどこで稼ぎを上げるかを告げる数値です。採用の停滞のセーブは競合による置き換えのセーブよりかなり上を走ると見込み、それに応じて人員を配置してください。第三に、エスカレーションの精度 —エスカレートされたアカウントのうち、リーダーシップの関与がもっともらしく結果を変えた割合。エスカレーションのほとんどがリーダーシップなしで解決したはずなら、重大度のラインが低すぎ、CS リーダーに課税しています。第四に、間に合った率 —churn したアカウントのうち、そもそもセーブの motion に入った割合。セーブプランなしの churn の率が高いのは、trigger が低下を十分早く捉えていないことを意味し、motion ではなく score へあなたを送り返します。
代替案との比較
QBR サイクルから回すアドホックなセーブとの比較。 多くのチームの status quo は、リスクが四半期レビューで表面化し、CSM が応答を即興することです。セットアップにコストはかからず、タイミングと一貫性で負けます。QBR は低下が始まってから 80 日後でありえ、応答の質はどの CSM がアカウントのオーナーかで揺れます。この SOP は 1 つの Gainsight CTA と 3 つの template のセットアップのコストで、応答を trigger から 1 週間以内へ動かします。アドホック版は、アカウント数が十分に少なく(~100 未満)、いずれにせよ CSM が各アカウントを毎週読む場合のみ選んでください。
書かれた SOP を背後に持たず、ネイティブに構築された Gainsight の Playbook / CTA との比較。 Gainsight は CTA を発火しタスクのチェックリストを添付でき、規模ではそれが正しい配信メカニズムです。しかし背後の診断から手へのロジックなしの CTA チェックリストは、タスク完了の劇場を生みます。CSM はボックスにチェックを入れ、それでも実際のセーブを即興します。Gainsight の CTA を trigger と SLA タイマーとして使い、この SOP の診断クラスと段階的な手を、CTA がリンクする内容として使ってください。両者は補完的です。Gainsight はメカニクス、SOP は判断です。
構造化された何もしないこととの比較。 自社の churn が本当に CS によって行動可能でない場合のみ実行可能です。人の接触のない純 PLG の motion、またはセーブが CSM の時間を決して回収しないセグメントです。関係駆動の renewal を持つどのチームにとっても、赤いアカウントへの非構造化な応答は防げる churn の最大の単一の源です。ある CSM ならしたであろうセーブを別の CSM が逃したもの、誰がたまたまアカウントのオーナーだったかで決まったものです。
注意点
- trigger が score のノイズで発火する。 health score が一貫しない使用量の tagging や一度の静かな週で赤になると、CSM は非問題に取り組み、CTA を信頼しないことを学びます。ガード:trigger を単一の sub-score ではなくコンポジットに gate し、大きなデルタの trigger が CTA を発火する前に 2 つのスコアリングサイクルにわたって持続することを要求してください。一晩の blip は自己修正し、決して CSM のキューに届きません。
- 診断が「リスクあり」という汎用ラベルに崩れる。 診断ステップが任意または自由記述だと、CSM はそれを飛ばして check-in コールへ跳び、それはあらゆる原因に対する手であり、どの原因に対しても正しい手ではありません。ガード:固定リストから原因クラスが選択されるか、調査コールを予約のうえ「原因不明」が明示的に選ばれるまで、セーブプランは介入ステップへ進みません。クラスこそが手を選ぶものです。
- 投げ捨て場としてのエスカレーション。 エスカレートが手を回すより簡単なら、CSM はすべてをエスカレートし、CS リーダーがボトルネックになります。ガード:エスカレーションの template は投稿の前にこれまでに回した手のフィールドと具体的な依頼を要求します。手の前歴も具体的な依頼もないエスカレーションは、CS リーダーによってスレッド内で CSM へ差し戻されます。
- クローズ時に文書化されないセーブ。 アカウントをセーブして原因と手を記録せずに先へ進む CSM はチームに何も教えず、次の同一の低下はゼロから即興されます。ガード:結果のフィールド(セーブ / churn / ダウングレード)と原因クラスが設定されるまで Gainsight の CTA はクローズしません。これによりクローズされた各セーブプランが原因別セーブ率のレポートに供給されます。
- motion がチューニングされた score より長生きする。 再重み付けされた health score や名前を変えた sub-score は、trigger の threshold と診断の sub-score 参照を静かに壊します。ガード:Gainsight の CTA の trigger threshold と
save-plan-template.mdの sub-score 名を、score の重みを再チューニングするのと同じレビューで、四半期に一度ライブの score に対して見直してください。
stack
- Gainsight —health score、trigger を発火する CTA、SLA タイマー、原因別の結果レポート
- Slack —エスカレーションチャンネル
#cs-savesとリーダーの承認スレッド - セーブプランの doc —
save-plan-template.md。チームがアカウントの doc を保管する場所(Gainsight、Notion、または Salesforce のカスタムオブジェクト)に、アカウントごとに 1 つの標準的な場所で保存