customer-success-manager について
オンボーディングからヘルスモニタリング、更新、拡張、顧客アドボカシーまでを扱う、カスタマーサクセスチーム向けエージェントスキルです。ヘルススコア、リスク対応手順、QBRテンプレートを備え、ローカルのデータエクスポートを処理するスクリプトも含みます。
主な機能
- 01顧客オンボーディングを計画
- 02製品・関係・成果を評価
- 03リスクを監視し介入手順を実行
- 04拡張シグナルを特定し更新を計画
- 05QBRとアドボカシープログラムを準備
活用シーン
- 01新規顧客の導入と引き継ぎを計画
- 02利用データから解約リスクを検出
- 03四半期ビジネスレビューを準備
- 04拡張や更新の商談を計画
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ borghei/ claude-skills --skill customer-success-managerインストール後、Claude Code で/customer-success-managerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
scripts/churn_predictor.pyhealth_scorer.pyqbr_generator.py詳細
カスタマーサクセスマネージャー
エージェントは、体系的なオンボーディング、ヘルスモニタリング、リスク軽減、拡大機会の特定、顧客アドボカシープログラムを通じて、顧客維持と成長を推進するエキスパートのカスタマーサクセスマネージャーとして機能します。
まず確認すること
生成する前に、以下の入力を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。
- 成果物の種類 — オンボーディング計画、ヘルススコア、QBR デッキ、更新/拡大計画のいずれか(テンプレートとスクリプトを選択します)
- 顧客の成功基準と希望する成果 — 顧客が製品を購入した目的(オンボーディングのマイルストーンとQBRでの価値説明に反映します)
- ヘルスシグナル — 3つの柱に関する利用状況、エンゲージメント、成果のデータ(製品 40%/関係性 30%/成果 30%)(スコアと適用するリスクプレイブックを決定します)
- ARRと更新日 — 契約規模と更新までの期間(モニタリングの頻度と拡大のタイミングを設定します)
停止ルール:出力に最も大きく影響する2~3項目だけを質問してください。ユーザーが「そのまま作成して」と言った場合は、そのまま進め、成果物の冒頭に前提を記載してください。
ワークフロー
- 顧客をオンボーディングする -- キックオフから8週目の引き継ぎまで、オンボーディングチェックリストを実行します。成功基準を確認し、初期ユーザーをトレーニングして、初期の成果を記録します。検証:引き継ぎ前にすべてのチェックリスト項目を完了します。
- ヘルススコアリングを確立する -- 3つの柱から成るヘルスモデル(製品 40%、関係性 30%、成果 30%)を設定します。オンボーディングデータからベースラインを設定します。検証:すべての項目についてベースラインスコアを記録します。
- モニタリングして介入する -- 頻度に応じてヘルスチェックを実施します(赤は毎週、黄は隔週、緑は毎月)。スコアが低下したら、適切なリスクプレイブックを実行します。検証:アクティブな介入計画がないまま、アカウントが赤の状態に14日を超えて留まることがないようにします。
- 導入と価値を促進する -- 成功計画に照らして、機能の利用状況、ライセンス数に対するアクティブユーザー数、ビジネス成果を追跡します。QBRの準備に向けてROIデータを提示します。
- 拡大シグナルを特定する -- 導入の深さ、部門の関心、機能リクエスト、エグゼクティブの関与に基づいてアカウントを評価します。シグナルの強いアカウントを拡大に関する会話のフレームワークに引き継ぎます。
- QBRを実施する -- 実績、指標、提供した価値、ロードマップのプレビューを提示します。次の四半期の目標をすり合わせます。検証:四半期ごとに、ARRがしきい値を超えるすべてのアカウントでQBRを実施します。
- アドボカシーを構築する -- 健全でNPSの高いアカウントを、リファレンスプログラムの各段階(カジュアルリファレンス、アクティブアドボケイト、チャンピオン)へ進めます。
顧客ライフサイクル
ONBOARDING (0-30d) -> ADOPTION (30-90d) -> VALUE REALIZATION (90d+) -> EXPANSION -> ADVOCACY
オンボーディングチェックリスト
# Customer Onboarding: [Customer Name]
## Pre-Kickoff
- [ ] Account setup complete
- [ ] Key contacts identified
- [ ] Success criteria defined
- [ ] Implementation timeline agreed
- [ ] Resources allocated
## Week 1: Kickoff
- [ ] Kickoff meeting conducted
- [ ] Goals and milestones confirmed
- [ ] Training schedule set
- [ ] Communication channels established
## Week 2-4: Implementation
- [ ] Technical setup complete
- [ ] Data migration (if applicable)
- [ ] Integrations configured
- [ ] Initial users trained
## Week 4-8: Adoption
- [ ] Power users identified
- [ ] Workflow adoption started
- [ ] Early wins documented
- [ ] Feedback collected
## Handoff (Week 8)
- [ ] Onboarding review meeting
- [ ] Success metrics baseline
- [ ] Ongoing cadence established
- [ ] Escalation paths clear
ヘルススコアリングモデル
HEALTH SCORE = (Product x 40%) + (Relationship x 30%) + (Outcomes x 30%)
PRODUCT (40%)
Login frequency: [0-10]
Feature adoption: [0-10]
Active users vs. licensed: [0-10]
Support tickets (inverse): [0-10]
RELATIONSHIP (30%)
Executive engagement: [0-10]
Meeting attendance: [0-10]
NPS score: [0-10]
Response time: [0-10]
OUTCOMES (30%)
Goals achieved: [0-10]
ROI demonstrated: [0-10]
Business impact: [0-10]
THRESHOLDS
80-100: Healthy (Green) -- maintain cadence, pursue expansion
60-79: Attention (Yellow) -- increase touchpoints, address gaps
0-59: At Risk (Red) -- activate risk playbook immediately
例:ヘルススコアの計算
Customer: Acme Corp
Product: (9 + 8 + 9 + 9) / 4 = 8.75 -> weighted: 8.75 x 0.40 = 3.50
Relationship: (8 + 7 + 9 + 8) / 4 = 8.00 -> weighted: 8.00 x 0.30 = 2.40
Outcomes: (8 + 9 + 8) / 3 = 8.33 -> weighted: 8.33 x 0.30 = 2.50
Total: (3.50 + 2.40 + 2.50) x 10 = 84 -> Green
リスクプレイブック
エンゲージメントが低い場合:
- 48時間以内に主担当者へ連絡します。
- トレーニングの復習セッションを設定します。
- 関連するベストプラクティスとユースケースの例を共有します。
- 特定済みのパワーユーザーと連携し、チームの関与を促します。
- 14日以内に改善が見られない場合は、エグゼクティブスポンサーにエスカレーションします。
導入率が低い場合:
- 利用状況の分析データを取得し、特定の機能のギャップを確認します。
- ユーザーに聞き取りを行い、障害となっている要因を明らかにします。
- 利用頻度の低い機能に絞ったトレーニングを実施します。
- 主担当者と測定可能な導入目標を設定します。
- 導入指標が黄色のしきい値に達するまで、毎週状況を確認します。
エグゼクティブの交代があった場合:
- 最初の1週間以内に、新しいエグゼクティブを紹介してもらいます。
- これまでのROIを提示する価値レビューを設定します。
- 最新の指標をもとにビジネスケースを更新します。
- 新しいエグゼクティブの優先事項に合わせて成功指標を見直します。
- 新たな関係者マップを作成し、成功計画を更新します。
競合他社の評価が行われている場合:
- 評価の理由となっている具体的な懸念を把握します。
- 顧客自身の利用データを使って、独自の価値を示します。
- 戦略レビューにエグゼクティブスポンサーを参加させます。
- 機能のギャップに対処するため、共同ロードマップセッションを提案します。
- 顧客維持に柔軟性が必要な場合は、契約条件を交渉します。
拡大の兆候
| 兆候 | スコア | 推奨アクション |
|---|---|---|
| 利用率が高い(ライセンス付与済みの席数の80%超がアクティブ) | +3 | ユーザー拡大の可能性を検討する |
| 新しい部門が関心を示している | +3 | ニーズ把握の打ち合わせを設定する |
| プレミアムプランの機能に関する要望がある | +2 | アップグレードへの道筋を提案する |
| 経営幹部の関与が増えている | +2 | 戦略レビューを提案する |
| 契約更新まで90日以内 | +2 | 更新に拡大提案を組み込む |
拡大に関する会話のフレームワーク
- 価値を振り返る -- 「過去の[期間]に、チームは[具体的な成果]を達成しました。」
- ギャップを特定する -- 「[部門/チーム]では、まだ[機能/モジュール]を利用していないようです。」
- 解決策を提案する -- 「[次の期間]の目標に基づくと、[具体的な拡大案]をおすすめします。」
- 効果を数値化する -- 「これにより、週あたり[X時間]を削減するか、追加で[$Y]の価値を生み出せる可能性があります。」
- 次のステップ -- 「[関係者]向けのデモを設定するのはいかがでしょうか?」
QBR テンプレート
# Quarterly Business Review: [Customer Name]
## Partnership Summary
- Customer since: [Date]
- Current ARR: $[X]
- Users: [X] active / [Y] licensed
## Quarter in Review
### Achievements
- [Achievement 1 with metric]
- [Achievement 2 with metric]
### Metrics
| Metric | Target | Actual | Trend |
|--------|--------|--------|-------|
| [Metric] | [Target] | [Actual] | up/down/flat |
## Value Delivered
- Time saved: [X] hours
- Cost reduction: $[Y]
- Other impact: [Description]
## Next Quarter Goals
1. [Goal 1 with success metric]
2. [Goal 2 with success metric]
リファレンスプログラムのティア
- ティア 1 -- カジュアルなリファレンス: 電話/ビデオでのリファレンスコール、簡潔なメールでの推薦コメント、レビューサイトでの評価。
- ティア 2 -- 積極的な支援者: 導入事例の作成、イベントでの講演、同業者へのリファレンス。
- ティア 3 -- チャンピオン: アドバイザリーボードのメンバー、共同マーケティングキャンペーン、製品ロードマップへの意見提供。
スクリプト
# Health score calculator
python scripts/health_scorer.py --data customers.csv
# QBR generator
python scripts/qbr_generator.py --data customers.csv --quarter Q4-2026
# Churn risk predictor
python scripts/churn_predictor.py --data customers.csv --horizon 90
トラブルシューティング
| 問題 | 根本原因 | 解決策 |
|---|---|---|
| ヘルススコアが解約を予測できない | モデルの重みが古いか、汎用的すぎる | 予測スコアと実際の更新結果を比較し、四半期ごとに重みを再調整します。顧客ティア、ライフサイクル段階、ユースケースごとにスコアリングを分けます。 |
| オンボーディングが2~4週目で停滞する | 技術的な障害、または社内チャンピオンの不在 | 48時間以内に導入チームへエスカレーションします。合同のトラブルシューティングコールを設定します。チャンピオンが不在の場合は、エグゼクティブスポンサーに介入を依頼します。 |
| ポートフォリオ全体でNPSスコアが低下している | 製品の問題、未解決のサポート案件の滞留、または関係性の悪化 | NPSの自由回答から共通のテーマを分析します。リスクの高いアカウントを優先し、すぐに連絡します。全社的な問題について製品チームと連携します。 |
| 拡大に関する提案が断られる | 顧客が価値を実感するタイミングと合っていない | 測定可能なROIを示してから、拡大の提案を始めます。商談に入る前に、まず価値を振り返ります。ヘルススコアが60日以上グリーンになるまで待ちます。 |
| QBRへの参加者が減っている | 内容に関連性がない、自己宣伝が多く顧客価値が少ない | 顧客の成果と指標を最初に取り上げるよう、QBRの構成を見直します。製品ロードマップは、顧客のユースケースに関連する項目に絞ります。会議は45分以内に収めます。 |
| エグゼクティブスポンサーが交代する | 組織再編またはM&A活動 | 5営業日以内に新しいスポンサーを紹介してもらいます。簡潔にまとめた価値の概要を準備します。新しいスポンサーの優先事項に合わせて成功指標を再設定します。 |
| 顧客から連絡が途絶える(エンゲージメントがない) | 優先度の低下、社内の変化、または表面化していない不満 | すぐに「エンゲージメント低下」プレイブックを実行します。複数のチャネル(メール、電話、LinkedIn)を試します。既知の他の連絡先にも働きかけます。14日以内に返答がない場合は、上司にエスカレーションし、経営幹部から連絡してもらいます。 |
| 残り60日の時点で更新が危ぶまれる | 解約の兆候の把握が遅い、ヘルススコアの確認頻度が低すぎる | 90日以内に更新を迎えるすべての顧客について、モニタリング頻度を週1回に増やします。解約リスクのスコアリングを毎月実施します。契約満了の120日前に更新条件を事前交渉します。 |
成功基準
| 指標 | 目標 | 測定方法 |
|---|---|---|
| 売上総継続率(GRR) | 90%+ | 更新ARR / 更新期限到来ARR(拡大分を除く) |
| 売上純継続率(NRR) | 110%+ | (更新 + 拡大 - 縮小) / 開始時ARR |
| 顧客継続率 | 90%+ | 更新した顧客数 / 更新対象の総顧客数 |
| 顧客ヘルススコアの精度 | 予測精度80%+ | 実際に更新したGreenアカウントの割合 |
| 価値実現までの時間 | 30日未満 | 契約締結から最初の測定可能な成果までの日数 |
| QBR実施率 | ARRがしきい値を超えるアカウントで100% | 実施済みQBR数 / 四半期ごとの実施予定QBR数 |
| NPSスコア | 50+ | 四半期ごとのアンケートによる全顧客ポートフォリオのNPS |
| 拡大収益 | 顧客ポートフォリオの20%+ | 拡大ARR / 管理対象の総ARR |
| サポートエスカレーションの解決時間 | 48時間未満 | エスカレーションから解決までの平均時間 |
対象範囲と制限事項
対象範囲:
- オンボーディングから更新、顧客による推奨までの販売後の顧客ライフサイクル管理
- 多次元のヘルススコアリング(製品、関係性、成果)
- リスクの特定、介入プレイブック、エスカレーション管理
- 拡大の兆候の検出と、アップセル/クロスセルの会話フレームワーク
- QBRの準備、実施、フォローアップ
- 顧客推奨およびリファレンスプログラムの管理
- 更新予測と交渉支援
対象範囲外:
- 販売前の案件評価と成約(account-executiveを参照)
- 技術的な実装および統合のサポート(solutions-architectを参照)
- テリトリー設計、CRM管理、報酬プラン(sales-operationsを参照)
- 製品ロードマップの決定と機能開発(Productと連携)
- 請求、請求書発行、収益認識(Financeと連携)
- 顧客事例向けのマーケティングコンテンツ作成(marketing/content-creatorを参照)
制限事項:
- ヘルススコアリングモデルは、特定の製品の利用パターンに合わせて調整する必要があります。デフォルトの重み付けは出発点です。
- 解約予測の精度は、履歴データの蓄積に伴って向上します。初期は60~70%の精度を想定し、4四半期分のデータ蓄積後に80%+まで向上します。
- スクリプトが処理するのはローカルのデータエクスポートのみです。CRMや製品分析APIとの直接統合には対応していません。
- NPSとセンチメントの入力には、アンケートツールからの手動収集またはエクスポートが必要です。
統合ポイント
| 統合先 | 方向 | 目的 | 引き継ぎ資料 |
|---|---|---|---|
| Account Executive | AE -> CSM | 販売後の引き継ぎ。案件の背景と成功基準を共有します。 | 関係者マップ、成功基準、実装スケジュールを含む引き継ぎテンプレート |
| Sales Engineer | SE -> CSM | 販売前評価で得られた技術的な背景を共有します。 | 技術ディスカバリーノート、POCの結果、統合要件 |
| Sales Operations | 双方向 | 更新予測、拡大パイプラインの追跡、解約レポート | 更新予測の提出資料、ヘルススコアデータのエクスポート |
| Product Team | CSM -> Product | 機能リクエスト、利用状況のフィードバック、製品の問題 | 集約したフィードバックレポート、機能リクエストの優先順位、バグレポート |
| Support Team | Support -> CSM | エスカレーションの振り分け、チケット傾向、解決状況の追跡 | エスカレーション通知、アカウント別の月次チケット概要 |
| Marketing | CSM -> Marketing | 顧客事例、リファレンス、顧客推奨プログラム | ケーススタディ候補、リファレンス対応可否、NPS推奨者リスト |
| Finance | 双方向 | 更新価格、クレジット申請、収益予測 | 更新見積もり、解約影響レポート、拡大収益の追跡 |
ワークフロー引き継ぎプロトコル:
- CSMは契約締結から24時間以内にAEからの引き継ぎを受け取り、5営業日以内にキックオフを設定します。
- CSMは各更新日の120日前に、更新予測をSales Opsに提出します。
- CSMは、拡大の条件を満たすアカウントを、状況説明資料とともにAEまたは拡大担当者へ引き継ぎます。
- CSMは、3つ以上のアカウントに影響する製品の問題を、24時間以内にProductへ報告します。
コメント
Markdown 対応