mcpField
C
conditional-customer-success

conditional-customer-success

github.com/magnus919マーケティング・グロース15358 回インストール今日更新
リポジトリ

conditional-customer-success について

Conditional Customer Success は、更新や QBR、専任のカスタマーサクセスチームなど、継続的な顧客関係があるプロダクトチーム向けの条件付きスキルです。適用可否を先に判断し、証拠に基づく記録、人による判断、プライバシー境界を含む実務を支援します。

主な機能

  1. 01カスタマーサクセスの適用可否評価
  2. 02顧客成果プランの作成
  3. 03ヘルスとリスクの根拠記録
  4. 04人が確認するエスカレーション経路
  5. 05引き継ぎとフィードバック完了の調整
  6. 06プライバシーと人の判断の保護

活用シーン

  1. 01企業アカウントの目標と測定可能な節目の計画
  2. 02観察可能な根拠に基づく顧客の状態とリスクの確認
  3. 03顧客フィードバックをプロダクトへ渡し、対応結果を伝達

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/magnus919/agent-skills --skill conditional-customer-success

インストール後、Claude Code で/conditional-customer-successを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
evals/
evals.json
references/
discovery-brief.md
privacy-and-human-judgment.md
templates/
applicability-decision.md
escalation-and-feedback-closure.md
health-risk-record.md
success-plan.md

詳細

条件付きカスタマーサクセス

継続的な人間関係を伴う製品向けの条件付きスキルです。このスキルをあらゆる製品コンテキストで決して読み込まないでください。アカウント、契約更新、QBR、または専任のカスタマーサクセスチームがある製品に限り読み込まれます。これらの条件が当てはまらない場合、つまり内部ツール、純粋なトランザクション型の製品、またはアカウントベースのエンゲージメントがない公共サービスの場合、このスキルは適用を辞退し、呼び出し元を別のスキルへ案内します。

読み込む条件(読み込み対象の例)

例該当する理由
担当アカウントマネージャーがいるB2Bサブスクリプション製品アカウント、契約更新、専任のカスタマーサクセスチーム
四半期ごとのビジネスレビューを実施するエンタープライズSaaSQBRの実施頻度、アカウント階層に応じたエンゲージメント
契約ポートフォリオの更新リスク分析が必要契約更新の根拠、解約リスクの兆候
専任のカスタマーサクセスチームがヘルスプランを管理する製品サクセスプラン、ヘルス状況の追跡
アカウント拡大の機会が特定されたものの、利用状況の兆候がまちまち関係性を踏まえた拡大機会
顧客フィードバックのループ — インサイトが明らかになり、製品が変更され、顧客への連絡が必要顧客の声を活用したクローズドループ

使用しない条件

アカウント、契約更新、QBR、またはカスタマーサクセスチームがない製品では、このスキルを読み込まないでください。以下の読み込み対象外の例を参照してください。

読み込まない条件(読み込み対象外の例)

必要な前提条件を製品コンテキストが満たしていない場合、このスキルを読み込んではいけません。このスキルは適用を辞退し、呼び出し元を別のスキルへ案内する必要があります。

例該当しない理由
アカウント、契約更新、QBRのない社内開発者ツール継続的な人間関係がなく、カスタマーサクセスチームもない
純粋なトランザクション型のEコマース製品 — 1回限りの購入で、アカウント管理がないアカウント、契約更新、QBR、カスタマーサクセスチームがない
公共サービスの給付申請ポータル — アカウント階層に応じたエンゲージメントがなく、カスタマーサクセスチームもない(カスタマーサクセスの意味での)アカウント、契約更新、QBRがない
サブスクリプション課金はあるが、人間によるカスタマーサクセスの関係がない消費者向けモバイルゲームサブスクリプションだけでは不十分で、人間によるカスタマーサクセスの関係がない
有料アカウントはないが、コミュニティサポートがあるオープンソースプロジェクトアカウント、契約更新、カスタマーサクセスチームがない
単一チーム向けの社内分析ダッシュボードチーム外との継続的な関係がなく、カスタマーサクセスチームもない

辞退ルール:読み込み対象の条件が一つも当てはまらない場合、つまり製品にアカウント、契約更新、QBR、カスタマーサクセスチームがない場合、このスキルは、欠けていた前提条件を記録した適用可否の評価を添えて適用を辞退し、呼び出し元を最も適切なスキル(product-analytics-and-measurement、product-adoption、またはproduct-lifecycle-learning)へ案内する必要があります。

製品/関係性モデル

このスキルでは、カスタマーサクセスの実践が適用される条件と、4つの異なるモデルに必要な調整を定義します。SaaSを前提とするモデルはありません。

1. B2Bサブスクリプション

全面的に適用されます。 アカウント、契約更新、QBR、拡大階層、専任のカスタマーサクセスチームがそろった形が標準的な対象です。すべての成果物が適用されます。サクセスプラン、ヘルス/リスク記録、エスカレーション経路、引き継ぎ手順、クローズドループのフィードバックが含まれます。

2. トランザクション型(非サブスクリプション)

部分的に適用 — 調整が必要です。 正式なサブスクリプションがなくても、リピーターやアカウントとの関係性がある場合があります。カスタマーサクセスに必要な調整は次のとおりです。

  • サクセスプランでは、サブスクリプションの更新日ではなく、リピート購入のパターンや再注文の結果に重点を置きます。
  • ヘルス状況の根拠として、MRRや解約指標ではなく、購入頻度、注文額の推移、アカウントのエンゲージメントの兆候を使用します。
  • QBRは暦上の日付ではなく、購入の節目やアカウント階層に応じて実施する定期的なビジネスレビューになります。
  • 購入頻度の低下やアカウントの休眠をエスカレーションのきっかけとします。
3. 公共サービス

最小限の適用範囲 — ルーティングを優先します。 公共サービスでは、「アカウント」ではなく、市民や受益者を対象とすることがよくあります。CSを適用するのは、明示的なアカウントベースのエンゲージメント(例:ケース管理ポータル)がある場合に限ります。

  • 成功計画は、商業的な計画ではなく、サービス成果の計画になります。
  • 健全性の根拠には、サービスへのアクセスの公平性、コホート間の完了率の差、アクセシビリティの障壁を用い、商業的な指標は決して用いません。
  • エスカレーション先は、商業部門のリーダーではなく、プログラムガバナンスとします。
  • プライバシーの境界はより厳格です。市民データを別の目的に転用してはなりません。 references/privacy-and-human-judgment.md を参照してください。

アカウントベースのエンゲージメントがない場合は、適用を辞退し、サービス導入の診断については product-adoption に、サービス成果の測定については product-analytics-and-measurement に案内してください。

4. 内部製品

条件付き — 別の手段への案内を強く推奨します。 内部製品には「内部顧客」(他のチームや事業部門)がいる場合がありますが、CSを適用するのは、定期的な人的関係があり、構造化されたエンゲージメントが行われている場合に限ります。

  • 成功計画は、商業的な計画ではなく、内部サービスレベル契約になります。
  • 健全性の根拠には、内部での導入状況、ワークフローの完了、削減できた時間の指標を用い、収益や MRR は決して用いません。
  • QBR は内部サービスレビューとなり、チームの成果を軸に構成されます。
  • エスカレーション先は、商業部門のリーダーではなく、内部ガバナンスとします。

内部製品に定期的な人的関係がない場合(例:単一チーム向けの分析ダッシュボード)は、適用を辞退し、product-adoption または product-lifecycle-learning に案内してください。

中核となる成果物

すべての成果物は意思決定を支援するためのツールであり、自動で意思決定を行うものではありません。

1. 適用可否の判断

カスタマーサクセスの手法を適用する前に、適用可否を評価してください。製品のコンテキストにアカウント、更新、QBR、またはCSチームがない場合は、適用を辞退し、依頼者を別の手段に案内してください。欠けていた前提条件を記録してください。

テンプレート:templates/applicability-decision.md

2. 成功計画

顧客が望む成果、それに対応する製品機能、測定可能なマイルストーン、担当する関係オーナーを記録した構造化データです。営業計画でも、サポートチケットでも、プロジェクト計画でもありません。成功計画は、顧客の意図と製品の根拠を結び付ける、更新され続ける成果物です。

テンプレート:templates/success-plan.md

3. 健全性/リスク記録

根拠に基づく記録であり、自動スコアではありません。健全性の各側面について、次の項目を記録します。

  • シグナル(代理指標ではなく、観察可能な根拠)。
  • 情報源(分析、導入状況、直接観察)。
  • 傾向(方向性と直近の状況)。
  • 確信度(根拠の信頼性)。
  • 相反するシグナル(無理に合意させず、意見の不一致を明らかにします)。

テンプレート:templates/health-risk-record.md

4. エスカレーション経路

シグナルから意思決定者へつなぐ経路を定義し、人による判断が必要な段階を明示します。すべてのエスカレーションでは、対応する前に人が判断する必要があります。この経路では、次の項目を定義します。

  • トリガーとなるシグナルとそのしきい値。
  • エスカレーションの担当者(システムではなく、役割を明記します)。
  • レビューの頻度。
  • 意思決定の選択肢(およびそれぞれの決定者)。
  • 意思決定に至らなかった場合の代替策。

テンプレート:templates/escalation-and-feedback-closure.md

5. 引き継ぎプロトコル

担当範囲を明確にしたうえで、プロダクト、サポート、エンジニアリングチームへの引き継ぎを定義します。

引き継ぎトリガー引き継ぎ先チーム成果物
顧客のエビデンスに基づく機能リクエスト3 アカウント以上で検証済みのパターンプロダクトサクセスプランの抜粋+健全性エビデンス
サポートへのエスカレーションアカウントに影響する重大な問題サポートアカウントの状況を含むエスカレーション記録
アカウントリスクを伴う技術的な不具合1 アカウント以上に影響する再現可能なバグエンジニアリング不具合記録+アカウントへの影響評価
ライフサイクル上の対応が必要な解約リスク健全性が継続的に低下し、2 回以上の改善の試みが失敗プロダクトライフサイクル学習健全性/リスク記録+改善履歴
6. フィードバックのクローズドループ化

顧客のインサイトからプロダクトの変更、顧客への連絡までの道筋です。

Customer Insight → Validate (pattern? isolated?) →
  Product Decision (build / defer / decline) →
    Implementation → Communication Back to Customer →
      Close Loop (record evidence)

すべてのステップを記録します。「顧客への結果の連絡」は必須です。クローズドループとは、フィードバックに対して何が行われたかを顧客が把握できるようにすることです。 templates/escalation-and-feedback-closure.mdを参照してください。

プライバシーと人間の判断の境界

これらの境界は交渉の余地がありません。

顧客フィードバックを監視に利用してはなりません
  • フィードバックは、同意を得たうえで、目的を明示して収集します。
  • 利用は明示した目的に限定します。
  • パターン検出のための集約は認められますが、明示した目的を超えて個人レベルの行動を追跡することは認められません。
  • チーム間で共有する顧客データは、必要最小限の範囲に限定します。
健全性スコアは意思決定の支援であり、自動的な決定ではありません
  • 健全性シグナルはエビデンスであり、自動的なアクションには決してつながりません(自動解約や、人によるレビューなしの自動エスカレーションは禁止です)。
  • 相反するシグナルは、単一のスコアに平均化せず、明示する必要があります。
  • 健全性/リスク記録には、すべてのシグナルについて確信度と出所を含めます。
エスカレーションの判断には人間の判断が必要です
  • すべてのエスカレーショントリガーについて、アクションを起こす前に人間が判断する必要があります。
  • エスカレーション経路には、誰が、どのエビデンスに基づき、どの選択肢から判断するのかを定めます。
  • 「判断なし」の状態には、明確なフォールバックを定めます。自動的にアクションを起こすのではなく、さらにエスカレーションします。
顧客データに関するプライバシーの境界
  • 顧客を特定できるデータを、CS チーム外で共有するテンプレートに含めてはなりません。
  • チーム間で共有する健全性エビデンスには、匿名化または集約したシグナルを使用します。
  • データの保持とアクセスは、CS の運用ではなく、プロダクトのプライバシーポリシーに従って管理します。

境界の全容については、references/privacy-and-human-judgment.mdを参照してください。

ルーティングと関連スキル

このスキルは、専門スキルの方法論を再構築するのではなく、それらのスキルにルーティングします。すべてのルーティング参照には、既存のディレクトリへの相対パス、またはまだ追加されていないスキルへの説明文での参照を使用します。

既存スキルへのルーティング
スキル管轄する内容このスキルでの活用方法
../product-analytics-and-measurement/SKILL.md指標ツリー、トラッキング計画、計測の品質保証、測定ガバナンス健全性/リスク記録に必要な健全性の根拠と指標の定義を提供します
../product-adoption/SKILL.mdオンボーディング、アクティベーション、行動変容、機能の発見、継続利用アダプションのシグナル(アクティベーション、機能の採用、継続利用)を健全性の要素として提供します
../product-experimentation/SKILL.md実験設計、結果の報告、リリース可否の判断CSの根拠から実験が示唆される場合に活用します(例:リスクのあるアカウントへの介入テスト)
../go-to-market/SKILL.md顧客獲得キャンペーン、マーケティングコンバージョン管轄しません。CSでは顧客獲得の状況のみを参照します。
../crm/SKILL.mdHubSpot CRMの運用 — 連絡先レコード、商談パイプラインの表示、確定済みの商談ステージ変更健全性/リスク記録やQBRの準備に必要なアカウントレコードと、パイプライン/健全性の状況を提供します
ルーティング先(説明文中の参照 — まだ追加されていないスキル)
スキル管轄する内容このスキルからのルーティング方法
product-lifecycle-learning廃止に関するコミュニケーション計画、提供終了時の顧客対応、移行支援の調整、ポートフォリオ全体での解約パターンの学習健全性の低下が続く場合(改善の試みが2回以上失敗)に、ライフサイクル上の対応へエスカレーションします。ポートフォリオ全体での学習に向け、解約と提供終了のシグナルをルーティングします。
管轄しない内容
  • 統計的推論や実験設計 — data-scientist と product-experimentation の管轄です。
  • プロダクト分析の計測 — product-analytics-and-measurement の管轄です。
  • 顧客獲得、マーケティングコンバージョン、キャンペーン設計 — go-to-market の管轄です。
  • プロダクトのロードマップ策定やポートフォリオの優先順位付け — product-roadmapping-and-portfolio の管轄です。
  • カスタマーサポート業務やチケット管理 — サポートツール関連のスキルの管轄です。
  • 契約交渉、価格設定、法的条件 — go-to-market と法務戦略関連のスキルの管轄です。

ファイル一覧

ファイル目的読み込むタイミング
references/discovery-brief.md既存の関連コンテンツ、管轄範囲の境界、ルーティングの判断を整理します最初に読み込みます — 必須のコンテキスト
references/privacy-and-human-judgment.mdプライバシーと人間の判断に関する境界、監視リスクの指針、同意の枠組みを網羅しますプライバシーや判断に関する疑問が生じたとき
templates/applicability-decision.md適用可能性を評価するための構造化テンプレート — 根拠に基づいて辞退または実施を判断しますいずれかのプロダクトにカスタマーサクセスの手法を適用するか検討するとき
templates/success-plan.md望ましい成果、マイルストーン、根拠の確認ポイントを含むカスタマーサクセス計画サクセスプランを作成またはレビューするとき
templates/health-risk-record.mdシグナル、情報源、傾向、確信度、相反するシグナルの追跡を含む、根拠に基づいた健全性/リスク記録健全性レビュー、QBRの準備、更新リスクの分析
templates/escalation-and-feedback-closure.mdエスカレーション経路の定義と、フィードバックをクローズドループで完了した記録エスカレーションの設計やフィードバックループの運用

QBRとエンゲージメントの実施頻度

四半期ビジネスレビュー(QBR)の構成

QBRはエビデンスを確認する場であり、営業プレゼンテーションではありません。構成は次のとおりです。

  1. 成功計画のレビュー — 目標とする成果に対する進捗、マイルストーンの達成状況。
  2. ヘルスのエビデンス — 各ディメンションのシグナル、傾向、信頼度。相反するシグナルは平均化せずに提示します。
  3. 導入状況のエビデンス — 機能の導入状況、アクティベーションの傾向、継続利用のパターン(プロダクト導入状況のエビデンスに基づく)。
  4. リスクレビュー — 未解決のリスク、緩和状況、エスカレーション履歴。
  5. 今後の計画 — 次期の成功計画の調整、拡大の機会(商業的な対応については市場開拓チームに引き継ぎます)、リスク緩和策。
  6. フィードバックループの状況 — 未対応のフィードバック項目、下されたプロダクト上の決定、顧客への回答状況。
B2Bサブスクリプション以外でQBRを実施するタイミング

サブスクリプション以外のモデルでは、QBRはカレンダー上の日付ではなく、イベントをきっかけに実施します。

モデルQBRの実施条件
トランザクション型購入マイルストーンのしきい値、アカウント階層の変更、または6か月間の休眠
公共サービスサービスレビューのサイクル、公平性の格差の検出、またはアクセシビリティ監査の結果
社内プロダクト社内サービスレビューのサイクル、チーム再編、または導入の減少

出力要件

  1. CSメソッドを適用する前に記録された適用可否の判断。
  2. 目標とする成果、マイルストーン、エビデンスのゲート、関係責任者の氏名を含む成功計画。
  3. スコアではなく、各ディメンションのエビデンスを記録したヘルス/リスク記録。
  4. 人間による判断が必要なゲートを明示したエスカレーション経路。
  5. 顧客のインサイト → プロダクト上の決定 → 顧客への連絡を追跡できるクローズドループ記録。
  6. アカウントの背景情報とエビデンスを添えた、プロダクト、サポート、またはエンジニアリングへの引き継ぎ記録。

コメント