mcpField
E
eol-communication

eol-communication

github.com/borgheiマーケティング・グロース1.0k45 回インストール5 日前に更新
リポジトリ

eol-communication について

製品、機能、サービス、API、価格体系の終了を顧客に伝えるためのコミュニケーションスキルです。プロダクトやマーケティング担当者向けに、移行案内、顧客別の伝え方、告知後の支援準備を支援します。

主な機能

  1. 01EOL対応の4段階フレームワーク
  2. 02作成前に重要事項を確認
  3. 03顧客層別のメッセージ設計
  4. 04サポートFAQと監視の準備
  5. 05プレイブックと注意点の参照

活用シーン

  1. 01製品や製品ラインの終了告知
  2. 02機能廃止やAPI終了の案内
  3. 03顧客向けサービス移行の説明
  4. 04価格変更に備えたサポート準備

インストール

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

$npx skills add https://github.com/borghei/claude-skills --skill eol-communication

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

同梱ファイル

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

examples/
sunsetting-classic-reports.md
references/
playbook.md
red-flags.md

詳細

EOL コミュニケーションのエキスパート

概要

顧客の信頼を維持し、スムーズな移行を促す、明確で共感の伝わるサービス終了（EOL）コミュニケーションを作成します。製品の提供終了は、重大な影響を伴うコミュニケーション上の課題です。対応を誤れば、ブランドへの信頼を損ない、ポートフォリオ全体で顧客離れを加速させます。適切に対応すれば、顧客との関係を強化し、代替ソリューションへの移行を促せます。

作業は4つのフェーズで進めます。（1）事前告知の計画（何を、なぜ、誰に、いつ、どのようなサポートを提供するか、どのようなリスクがあるか）、（2）メッセージの作成（移行のストーリー、顧客への影響、移行ソリューション、スケジュール、CTAを1つ）、（3）セグメント化と配信（セグメントごとに異なるメッセージとチャネルを使用）、（4）サポートとモニタリング（サポート FAQ、移行状況の追跡、解約の監視）。フレームワーク全体、テンプレート、スケジュールに関するガイダンスについては、プレイブックのリファレンスを参照してください。

まず確認すること

EOL コミュニケーションを作成する前に、次の情報を確認してください。不明または曖昧な点があれば、推測せずに質問してください。

  • 何を、なぜ終了するのか — 移行のストーリーとフェーズ1の計画を左右します。「なぜ」が曖昧だと、顧客を見捨てる印象を与えます
  • 代替手段／移行経路 — 移行ソリューションと唯一の CTA を左右します。移行経路に問題がある、または存在しない場合は、まだ告知しないでください
  • スケジュールと重要な日付 — スケジュールのセクションを左右し、製品の種類（API、有料製品、無料機能など）によって大きく異なります
  • 影響を受ける顧客セグメント — フェーズ3のセグメント／チャネルのマトリックスを左右します。重要度の高いアカウントには、セルフサービスの顧客とは異なるメッセージとアプローチが必要です

質問を絞るルール：成果物に最も大きな影響を与える2～3点だけを質問してください。ユーザーが「とにかくドラフトを作って」と言った場合は作成を進め、成果物の冒頭に前提条件を記載してください。

使用する場面

  • 製品の提供終了 -- 製品全体または製品ラインの提供を終了する場合。
  • 機能の廃止 -- 既存製品から重要な機能を削除する場合。
  • サービスの移行 -- 顧客を別のプラットフォームまたはインフラストラクチャに移行する場合。
  • API の廃止 -- API のバージョンまたはエンドポイントを廃止する場合。
  • 価格モデルの変更 -- 従来の料金プランを実質的に終了する、大幅な価格体系の変更を行う場合。
使用しない場面
  • 顧客への通知が不要な軽微な機能変更。
  • 顧客への影響がない社内ツールの変更。
  • バグ修正やパッチ（代わりにリリースノートを使用してください）。

リファレンス

  • references/playbook.md — 提供終了の告知を作成する際に参照してください。EOL の4フェーズフレームワーク、メッセージのテンプレートと作成ルール、セグメント／チャネルのマトリックス、社内サポート FAQ、モニタリングチェックリスト、製品の種類別のスケジュールに関するベストプラクティス、トラブルシューティング、成功基準が記載されています。
  • references/red-flags.md — メッセージを法務部門とサポート部門に確認してもらう前に参照してください。EOL メッセージ、スケジュール、移行計画でよくある問題について、4フェーズフレームワークに基づいた悪い例と良い例を示しています。

対象範囲と制限事項

対象範囲： EOL メッセージの作成、スケジュールの計画、セグメント別のメッセージ作成、社内 FAQ の準備、移行状況のモニタリングフレームワーク、顧客の反論への対応、サポートチームの準備。

対象外： 代替製品の開発、データ移行ツールの実装、法的契約のレビュー、返金処理、技術インフラストラクチャの廃止。

重要な注意事項： EOL コミュニケーションの質は、その背後にある移行経路の質に左右されます。代替製品の準備が整っていない、または移行経路に問題がある場合、どれほど優れたメッセージを作成しても、顧客の不満を防ぐことはできません。告知する前に、移行ツールがテスト済みであることを確認してください。

統合ポイント

統合方向流れる内容
create-prd/補完置き換え製品の PRD が EOL 移行の説明に役立ちます
release-notes/取り込み最終的な製品アップデートを EOL のタイムラインと併せて伝えます
summarize-meeting/受け取りEOL の決定会議の議事録がコミュニケーション内容に役立ちます
senior-pm/受け取りステークホルダーマップで、個別の連絡が必要な高リスクのアカウントを特定します
daci-framework/補完DACI チャートで、EOL の決定とコミュニケーションを主導する担当者を明確にします

コメント

Markdown 対応