← エピソード一覧に戻る Episode 233 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS のチャンピオン育成です。ChurnZero が引用する Sturdy の分析では、顧客 champion が離職すると 12 か月以内に 51 パーセントが churn し、役員交代では 65 パーセントが非更新でした。更新を守るには、製品理解だけでなく、顧客社内の味方づくりが欠かせません。
ミカ
CS ってつい『担当者さんと仲良くする仕事』みたいに見えがちですけど、その一人が異動しただけで半分近く churn するなら、かなり危ない前提で動かないといけませんね。
タカシ
その通りです。しかも Gainsight は、champion program は customer advocacy と別物だと整理しています。登壇や紹介に協力してくれる人ではなく、顧客社内で同僚へ使い方を教え、業務を変え、導入を前へ進める人が本当の champion です。
ミカ
なるほど。社外向けに褒めてくれるファンではなく、社内で『このツールを使う理由』を言語化して広めてくれる推進役なんですね。今日はその育て方を知りたいです。
Chapter 2 誰をチャンピオンにするか
タカシ
まず大事なのは人選です。OpenView は champion を authority、role、influence で見ろと言っています。つまり肩書き、予算や意思決定への関わり方、そして他部署を動かせる影響力ですね。単なるヘビーユーザーでは足りません。
ミカ
ここ、すごく現場っぽいです。毎日使っていて好意的でも、周りに広げる力がない人は power user ではあっても champion ではない、ということですか。
タカシ
はい。OpenView は enterprise なら 1 executive sponsor、2 champions、3 power users を持つ 1-2-3 Rule を例示しています。更新や拡張を安定させるには、好きな一人を深掘るより、役割の違う味方を複線化するほうが強いんです。
ミカ
推し一人に全部任せる運営は危ないわけですね。ライブ会場でフロントマンだけ元気でも、バンド全体が鳴っていなければ広がらない、みたいな感じがします。
Chapter 3 育成を仕組みにする
タカシ
育成のやり方も重要です。Gainsight が紹介した OpenAI の champion program では、Champion Lead は社内戦略を設計し、Internal Champion は部門単位で研修やハッカソンを回していました。役割を分けることで、推進の責任が曖昧にならないんですね。
ミカ
面白いですね。ベンダーが全部教えるのではなく、顧客社内に先生役をつくる発想なんだ。しかもそれが正式な役割になると、導入が個人の善意に依存しにくくなりそうです。
タカシ
そうです。さらに彼らは Champion Lead 向けに定期 roundtable を開き、毎回 25 人から 30 人ほどが参加していたそうです。価値は製品説明より peer learning にあり、他社の進め方を持ち帰れることが champion の自信につながります。
ミカ
つまり champion を育てるなら、説明資料を送って終わりでは弱いんですね。社内で教える人が『自分だけ困っているわけじゃない』と思える場まで用意したほうが回りやすい。
タカシ
その通りです。しかも見るべき指標はログイン数だけではなく、OpenAI の事例でいう activation と sustained activation です。使ったかより、業務習慣として根づき、他人へ教える行動が続いているかを追わないと、本物の champion かは分かりません。
Chapter 4 事例と失敗パターン
タカシ
Lytho の事例も示唆的です。Gainsight でヘルススコア、success stage、renewal likelihood、NPS、利用状況から候補者を見つけ、advocacy program を再設計した結果、advocacy events は前年比 2 倍、顧客基盤の 19 パーセントが advocates として参加する状態になりました。
ミカ
いい顧客を見つけてお願いし続けた、ではないんですね。健康度や更新見込みまで見て、今この人に声をかけるべきかを判断している。育成って、熱量管理でもあるんだなと感じます。
タカシ
その点が大事です。Lytho では 180 日で 2 回 advocacy に参加した顧客は自動で候補から外していました。良い champion を酷使すると逆効果になるので、価値実感が高い瞬間にだけ依頼し、CSM が最終判断を持つ設計にしていたんです。
ミカ
確かに、毎回『登壇お願いします』『紹介お願いします』だと、応援していた気持ちが仕事みたいになってしまいますもんね。
タカシ
もう一つの失敗は、一人依存です。SaaStr は champion は平均 24 か月ほどで動くことがあると指摘していますし、ChurnZero では変化に 48 時間以内で反応すると renewal 可能性が 33 パーセント高まると紹介しています。だから後継 champion の準備は平時から必要なんです。
Chapter 5 明日からの実践
ミカ
では、経営者や CS リーダーが明日から始めるなら、何を固定化するといいですか。『良い人を見つけよう』だけだと、たぶん属人的に終わりますよね。
タカシ
まず champion の定義を利用頻度ではなく、影響力、業務変更の実行力、継続接触のしやすさで明文化します。そのうえで上位顧客は 1 executive sponsor、2 champions、3 power users の最低構成を置き、欠けている役割を risk として管理してください。
ミカ
さらに champion に、社内説明用の一枚資料や ROI、成功事例、次の展開案を渡しておけば、その人が社内営業しやすくなるわけですね。CS が裏方の資料班になるのも大事そうです。
タカシ
まさにそこです。良い champion は自然発生しません。見つけ、教え、社内で勝てる材料を渡し、複数化し、異動時にすぐ引き継ぐ。この運用ができる SaaS は、更新も拡張も強くなります。皆さんの顧客でも、次回の QBR までに『次の champion 候補は誰か』をぜひ一度書き出してみてください。