カスタマーサクセスプランとは、買い手のビジネス成果を一連のマイルストーン、両サイドの指名されたオーナー、そしてレビューのケイデンスに結び付ける共有ドキュメントです。作り方は、顧客が購入した成果（あなたが提供した機能ではなく）から始め、それを証明するマイルストーンへ逆算し、それぞれにオーナーを割り当て、renewal の前にズレを捉えるレビューのリズムを設定します。プランは相互的なものです。顧客がサインオフするか、さもなければそれは単なる社内メモにすぎません。
最もよくある失敗は、実際には機能採用のチェックリストでしかない「success plan」です。ログインする、CRM をつなぐ、ユーザーを招待する、といった具合です。採用は先行指標であって、成果ではありません。顧客がサポートの応答時間を8時間から1時間に短縮するためにあなたのツールを購入したなら、プランは応答時間をトラッキングし、採用のステップはその数字を動かすからこそ存在します。
前提条件
- 営業サイクルで買い手が表明したビジネス成果。MEDDPICC のノート、mutual action plan、または受注した deal の Gong コールから引き出します。書き留められていなければ、最初のタスクはそれを得るための discovery call です。
- 顧客のベースライン指標（「from」の数字）へのアクセス。ベースラインがなければ動きを示せません。
- プランをホストしマイルストーンのステータスをトラッキングする CS プラットフォーム。Gainsight、Planhat、Catalyst、または Vitally です。最初のプランには共有の Notion や Google Doc で十分です。トラッキングするアカウントが約15を超えたらプラットフォームに移行します。
ステップ1 — 成果を測定可能な文として書く
曖昧な目標を from/to/by の文に変換します。「平均初回応答時間を Q3 末までに8時間から2時間未満へ削減する」。3つの要素すべてが必須です。指標、target、日付です。顧客から数字を得られないなら、その成果は検証されていません。何かを構築する前に champion のところへ戻って確定させます。「効率を改善する」の上に構築されたプランは、何も完了としてマークできないため、レビューできません。
ステップ2 — マイルストーンへ逆算する
成果を3〜6個のマイルストーンに分解します。各マイルストーンは成果が軌道に乗っていることのチェックポイントです。応答時間の例では:
- 第2週 — 実装完了。 ツールをヘルプデスク（例: Zendesk や Intercom）に接続し、routing ルールを稼働。
- 第4週 — 最初の価値。 最初の50チケットを自動トリアージ、エージェントをトレーニング。これは time-to-value のマイルストーンです。time to value を参照。
- 第8週 — target の半分。 パイロットチームで初回応答時間が4時間に低下。
- 第12週 — target 達成。 全チームで2時間未満、成果が検証済み。
各マイルストーンは、それが動かす先行指標を名指しします。採用タスク（トレーニング、インテグレーション）はマイルストーンの下に置き、決してマイルストーンそのものにはしません。
ステップ3 — 両サイドにオーナーを割り当てる
各マイルストーンには、あなたのサイドに正確に1人のオーナー（CSM または実装リード）、顧客サイドに1人（経済的買い手の代理、通常は admin またはチームリード）がいます。オーナーが2人ということはオーナーがいないということです。executive sponsor は両サイドで別途名指しします。彼らはエスカレーションの経路であって、実行者ではありません。顧客があるマイルストーンの社内オーナーを名指しできないなら、そのマイルストーンは初日からリスクです。フラグを立てます。
ステップ4 — レビューのケイデンスを設定する
ケイデンスはマイルストーンの密度に合わせ、固定の社内カレンダーには合わせません:
- オンボーディング（第0〜12週）: 週次の30分チェックポイント。プランが最も速くズレるのはこの時期です。
- 定常状態: 月次のワーキングセッション、executive sponsor 向けには四半期ごとの QBR。
- リスクのあるアカウント: health score が回復するまで週次。
各レビューは3つのことを行います。マイルストーンを完了/リスク/ブロック済みとしてマークし、成果指標がまだ正しいものか再確認し、ブロッカーを指名されたオーナーへ上げます。ブロッカーを動かさずステータスを報告するだけのレビューは演劇です。
ステップ5 — health score に接続する
プランは単独のアーティファクトではありません。マイルストーン遅延のステータスは customer health score に赤信号として供給され、プランから外れていくアカウントが、CSM が手動で気づく前にポートフォリオビューに浮かび上がります。Gainsight や Planhat では、プランをマイルストーンの期日を持つ Success Plan オブジェクトとしてモデル化し、マイルストーンが期日を過ぎたら CTA（call-to-action）をトリガーします。
成功の基準
チェックリストではなく本物のプランがあるのは次の場合です。トップラインが顧客が合意した from/to/by の指標であること、各マイルストーンがそれが動かす指標を名指ししていること、各マイルストーンにサイドごとに1人のオーナーがいること、レビューのケイデンスが両方のカレンダーに入っていること、そしてマイルストーンのステータスが health score に接続されていること。
よくある落とし穴
- プランを装った機能チェックリスト。 Guard: 各マイルストーンは、それが前進させるビジネス指標を名指ししなければなりません。機能しか名指ししないなら、指標を担うマイルストーンの下に書き直します。
- ベースラインがない。 「from」の数字がなければ、活動は示せても進捗は決して示せません。Guard: ベースライン指標がプランオブジェクトに記録されるまでプランを確定しません。
- 片側だけのオーナーシップ。 CSM サイドのオーナーしかいないプランは、相互プランではなくあなたの ToDo リストです。Guard: 顧客側のオーナーが名指しされていないマイルストーンはデフォルトでリスクとしてマークします。
- 設定して放置。 ケイデンスが課されなければ、プランはキックオフの翌週には陳腐化します。Guard: レビューを逃すとアカウントの health score が自動的に下がり、キューへ戻されます。
- 成果のドリフト。 契約時に顧客が気にしていた指標が、renewal 時に重要な指標とは限りません。Guard: 成果の文をキックオフだけでなくすべての QBR で再確認します。
関連
- Customer success playbook — プランが実行する反復可能なプレイ
- Customer health score — プランから外れたステータスが浮かび上がる場所
- Time to value — どのプランにも必要な最初のマイルストーン
- Renewal management — プランが最終的に守るもの
- Customer onboarding — プランが最も密になるフェーズ