← エピソード一覧に戻る Episode 232 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS のステークホルダーマッピングです。ChurnZero が引用する Sturdy の分析では、顧客チャンピオンが離職すると 12 か月以内に 51 パーセントが churn、役員交代では 65 パーセントが非更新でした。更新事故の多くは、プロダクトではなく人の地図が欠けて起きます。
ミカ
51 パーセントは重いですね。つい利用率やサポート件数ばかり見がちですが、誰が味方で、誰が決めて、誰が止めるかを見ていないと、数字が緑でも更新でひっくり返るわけですね。
タカシ
その通りです。ステークホルダーマッピングは組織図を書く作業ではありません。導入責任者、現場管理者、日常ユーザー、決裁者、調達や IT まで含めて、役割と影響力、温度感、意思決定の流れを見える化する運営です。
ミカ
今日は、CS がなぜそこまで人間関係を構造化しないといけないのかと、どう更新や拡張の運用に落とすのかを知りたいです。
Chapter 2 地図に入れるべきもの
タカシ
Winning by Design は、関係性を可視化すると single-threaded なリスクを減らせると言います。見るべきは肩書きだけではなく、誰が賛成で、誰が懐疑的で、最終判断がどの順番で流れるかという decision flow です。
ミカ
なるほど。担当窓口が『前向きです』と言っていても、その人に予算権限がなく、しかも情報システム部が反対なら、地図としては全然足りないわけですね。
タカシ
はい。Gainsight の multi-threading では breadth、depth、height の三つで見ます。部署横断の広がり、現場から経営層までの高さ、そして関係の濃さです。つまり接点数ではなく、どの層とどれだけ継続接触できているかが重要なんです。
ミカ
友好的な一人と毎週話していても、それだけだと single-threaded なんですね。なんだか推し一人でバンドを支えるみたいで、抜けた瞬間にライブが終わります。
Chapter 3 SaaS での運用設計
タカシ
Gainsight は stakeholder roles を Champion、Decision Maker、Executive Sponsor などでタグ付けし、役割ごとに接触頻度を変えるべきだと勧めています。たとえば champion は週次、decision maker は月次、exec sponsor は四半期ごとです。
ミカ
ここが SaaS っぽいですね。売って終わりではなく、導入中は管理者と現場、定着後はスポンサーと経営層、更新前は調達や財務まで、見に行く相手が段階で変わる。
タカシ
しかも Gainsight は、3 交換を 90 日以内に満たせない関係は実質的に弱いとみなし、single-threaded alert を出しています。名刺があるだけでは関係ではない、という厳しさです。
ミカ
たしかに CRM に名前だけ並んでいても、半年話していなければ地図というより古い電話帳ですね。
Chapter 4 事例で見る差
タカシ
Affinio の CS チームは、Executive Sponsor、Adoption Champion、End User ごとに関わり方を分け、サポートで赤信号が出たら CSM と連携して sponsor まで対話を広げていました。窓口だけで処理せず、問題を上位関係者の課題として翻訳したわけです。
ミカ
現場の困りごとを、そのまま経営インパクトに翻訳しているんですね。誰に何語で伝えるかが違うから、地図がないと同じ説明を全員に投げて空振りしそうです。
タカシ
Pexip は Planhat で usage、CRM、stakeholder mapping を一つの 360 画面にまとめ、どの更新が近いか、規模はどうか、活用はどうかを CSM が即答できるようにしました。stakeholder map を別紙にしないことで、 churn と expansion を同じ運用で見られるようにしたんです。
ミカ
地図が会議資料の飾りではなく、更新とアップセルの判断画面に入っているのが大事ですね。
タカシ
Navattic も kickoff のたびに stakeholder、use case、implementation timeline を含む標準ノートを自動生成し、2023 年後半の月次 churn を 20 パーセント下げ、go live を 30 パーセント早め、オンボーディング量を 4 倍に伸ばしました。手渡しではなく仕組みにした強さです。
ミカ
人の情報を標準フォーマットで残すだけで、そんなに変わるんですね。引き継ぎのたびに『この人誰でしたっけ』から始める会社は、かなり損していそうです。
Chapter 5 失敗パターンと明日からの実践
ミカ
逆に失敗するのはどんな状態ですか。CSM の頭の中にだけ地図があって、営業やサポートは別の人と話している、みたいな会社は危なそうです。
タカシ
典型は四つです。仲のいい担当者だけを map する。反対者や調達、IT 管理者を抜かす。組織変更後も更新しない。QBR や renewal plan と切り離す。このどれかがあると、地図は飾りで終わります。
ミカ
ありますね。異動した瞬間に『次の窓口誰ですか』から始まり、更新二週間前にようやく決裁者の名前を知る、みたいな。あれは churn の原因というより、準備不足の積み上がりなんでしょうね。
タカシ
明日からやるなら、上位顧客ごとに champion、admin、利用責任者、決裁者、調達・IT を一枚に置き、役割、影響力、温度感、次回接点日を必須項目にしてください。異動や未接触アラートが出たら 48 時間以内に次の面談を取る。ここまでやると更新事故はかなり減ります。
ミカ
今日は、ステークホルダーマッピングは人脈メモではなく、継続売上を守るための指揮図だと分かりました。皆さんも次の QBR 前に、誰が味方で、誰が決めて、誰がまだ白地かを一枚に書き出してみてください。それではまた次回。