← エピソード一覧に戻る Episode 227 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS CS のサクセスプランです。Planhat が紹介した調査では、12 カ月の success plan を入れていた CSM は、更新案件の 51 パーセント超を upsell 付きで閉じていました。計画の有無が売上を変えるんです。
ミカ
へえ、それは大きいですね。でもサクセスプランって、名前は立派でも実態は会議メモになりがちな印象があります。何を書けば、本当に更新や拡張に効く計画になるのか、その線引きを今日は具体例つきで知りたいです。
タカシ
本質はシンプルです。顧客が何を達成したいかを、指標、期限、担当者、マイルストーン、リスクつきで共有すること。仲良くするための資料ではなく、双方が同じ地図を見ながら成果を前に進めるための共同運営表なんですね。
ミカ
なるほど。『この機能を説明しました』ではなく、『この成果をこの日までに出します』を顧客と握るわけですね。今日は、形だけの計画と生きている計画の違いを、実務の目線でしっかり具体的に知りたいです。
Chapter 2 サクセスプランの基本
タカシ
Totango は success plan を、顧客と共有しながら business goals、milestones、success metrics を追う文書化されたロードマップと定義しています。つまり社内だけのメモではなく、顧客も見て進捗を確認できることが前提です。
ミカ
共有されていない時点で、もう半分失敗なんですね。CS 側だけが『このお客さんはヘルスが黄色です』と思っていても、顧客が次に何をすべきか分からなければ、現場では何も前に進みませんもんね。本当にその通りです。
タカシ
さらに Totango は、良い objective の条件として VALUE フレームワークを出しています。測定可能で、承認済みで、期間と範囲が限定され、顧客固有で、戦略課題に結びついているか。ここが曖昧だと、計画はすぐ空中戦になります。
ミカ
たしかに『活用を増やしましょう』では弱いですね。『どの部門で、いつまでに、何をどれだけ改善するか』まで言わないと、会議のたびに話がふわっと戻ってしまって、誰も動けなくなりそうです。かなり危ないですね。
Chapter 3 勝っている会社の運用
タカシ
GitLab の公開 Handbook はかなり参考になります。100k ドル以上の net ARR を伴う Strategic や Enterprise 案件では、stage 2 から Mutual Customer Success Plan を作り、stage 4 前に顧客レビューまで求めています。
ミカ
受注後じゃなくて、かなり前から計画を仕込むんですね。しかもその時点で顧客レビューまで入れるなら、営業トークと導入後の現実がずれるのをかなり防げそうですし、社内の handoff もかなり楽になりそうです。
タカシ
そうなんです。GitLab はその中で、business outcomes、key stakeholders、current and desired state に加え、30・60・90 日や 3・6・12 カ月の milestones まで引き継いでいます。Sales、SA、CS の handoff を一枚でつなぐ発想ですね。
ミカ
いいですね。顧客からすると、買った瞬間にチームが入れ替わっても『この会社、ちゃんと前の約束を覚えているな』となる。信頼って、こういう連続性や文脈の引き継ぎで作られるんだなと、改めて強く思いました。
Chapter 4 更新と拡張に効く理由
タカシ
Planhat が紹介した調査では、更新に強い CSM は、ロードマップ共有、QBR、12 カ月の success plan、更新契約レビューの四つをそろえていました。しかも更新日の 120 日前から動くと、前倒し更新や net retention の確率が上がるそうです。
ミカ
更新直前に慌てて ROI 資料を作るより、かなり健全ですね。12 カ月の plan があれば、『この一年で何を達成したか』『次にどこを伸ばすか』を自然につなげられそうですし、値引き以外の話がしやすくなりそうです。
タカシ
ChurnZero や Catalyst、Totango が面白いのは、その計画を会議資料で終わらせていない点です。goals achieved や due date、pacing、owner をシステム上で持ち、health score や renewal、expansion の判断材料につなげています。
ミカ
なるほど。サクセスプランを作ること自体が目的じゃなくて、ヘルス管理や更新管理と連動して初めて意味が出るんですね。言い換えると、見返されない計画は存在していないのと同じだし、経営数字にも効かないわけですね。
Chapter 5 崩れるパターンと実践
タカシ
崩れる会社には共通点があります。目標が抽象的、顧客と共有していない、exec sponsor が不在、Sales からの handoff で前提が消える、この四つです。加えて全顧客を完全 bespoke で設計しようとすると、すぐスケールが止まります。
ミカ
ありますね。立派なスライドはあるのに、顧客側の owner が空欄だったり、次の会議まで誰も更新していなかったり。あれは plan じゃなくて、会議のための発表資料なんだなと今なら分かります。かなり違いますね。
タカシ
明日からやるなら、事業目標、成功指標、期限、顧客側と自社側の owner、主要 milestones、risk を一枚にまとめてください。そして更新 120 日前には見直す。SMB はテンプレート化し、Enterprise だけ深く個別化するのが現実的です。
ミカ
今日は、サクセスプランは親切なメモではなく、更新と拡張を前倒しで作る運営装置だと分かりました。皆さんもまず一社だけでいいので、次回更新日から逆算した成果計画を一枚で作ってみてください。それではまた次回。