eol-message

提供終了メッセージ

目的

提供終了を伝え、その理由を説明し、顧客への影響に触れ、移行を支援し、今後の展開を示す、明確で共感のこもった提供終了メッセージを作成します。難しい移行のさなかに顧客の信頼を保ち、見捨てられたと感じた顧客の離脱を減らすために活用してください。

これは一般的な終了告知ではありません。喪失を認めながら、変更を前進として位置づける、顧客中心のコミュニケーションです。また、変更の規模に合わせた内容にします。廃止予定のトグルなら1段落、主力製品の提供終了なら数か月にわたる段階的なコミュニケーションが適切です。

入力

あると最適です： 提供を終了するもの（製品、機能、プラン）と、おおよその時期。

あると役立ちます： 理由、影響を受ける顧客層、移行先または代替手段、サポートの約束、伝えられる内容を制約する契約上または規制上の文言。

呼び出し時に指定された内容（スキル名の後に入力されたテキスト、貼り付けられたコンテキスト、追加されたARGUMENTS:行）は、すでに回答済みの情報として扱います。その情報を使い、該当する質問は繰り返しません。

何も決まっていなくても大丈夫です。 このスキルでは、草案の作成前に対象、時期、理由、移行先を尋ね、その後にメッセージの規模を提案します。提案は変更できます。理由と次のステップを明示しない提供終了メッセージは、顧客を見捨てた印象になります。そのため、この2点はどのような場合でも確認します。

呼び出し例：

• Draft an EOL message: retiring our legacy reporting module Dec 31, replaced by the new analytics dashboard; 400 accounts affected.
• We're killing a feature nobody uses. Give me the brief version — no replacement, 3 weeks notice.

---

主な概念

変更に合わせたメッセージの規模

提供終了メッセージで最もよくある失敗は、口調ではなく、変更との釣り合いです。廃止予定のチェックボックスについて6セクションの告知を出すと、顧客は通知を読まなくなります。一方、実際のワークフローを支える製品について1行だけで知らせると、サポート対応が発生します。

	簡潔	標準	詳細
使用する場面	機能、内部ツール、未使用のオプション	商用製品、利用中の顧客がいる	収益に不可欠な製品、ハードウェア、規制対象
長さ	1～3段落	フェーズ表付きで1ページ	数か月にわたる複数の段階
使用するセクション	告知、タイムライン、CTA	9つすべてを簡潔に	9つすべて＋コンプライアンスと義務
事前告知期間	数週間	6～12か月	12～24か月
チャネル	アプリ内または変更履歴	メール＋アプリ内＋ドキュメント	メール＋アカウントチーム＋パートナー＋報道機関

告知のほとんどは標準です。 規模を提案し、その理由を1行で説明したうえで、ユーザーが変更できるようにします。標準規模を提案する内容に対してユーザーが簡潔版を選んだ場合は、何が省かれるのかを1点だけ伝えます。多くの場合、省かれるのはフェーズ表です。これは「えっ、いつ使えなくなるの？」という問い合わせを防ぐために重要です。

3つの移行先

顧客に伝えるべきなのは、最終的にどこへ移行するのかです。答えは3種類あり、それぞれメッセージの内容が大きく異なります。

1. 代替 — 自社の別の製品が引き継ぎます。メッセージでは継続性を重視し、引き継がれるものや改善される点を伝えます。ここでは位置づけが最も重要です。
2. 移行 — 同じ製品ファミリー内で、別のティア、構成、プラットフォームに移行します。メッセージでは実務面を重視し、顧客が何を、いつまでに、どの程度の作業で行う必要があるかを伝えます。作業量については正直に伝えてください。少なく見積もることは、信頼を失う最も早い方法です。
3. 円満な終了 — 代替するものがありません。メッセージでは、誠実な理由説明、データのエクスポート、十分な事前告知、競合製品も含めた現実的な選択肢を示し、顧客の尊厳を重視します。競合他社の名前を挙げることによる損失は、顧客を行き場のない状態にすることで生じる評判へのダメージより小さいものです。

円満な終了は、チームが最も苦手とする書き方です。最もつらく感じる内容だからです。しかし同時に、顧客が最も厳しく評価する内容でもあります。

ライフサイクルの各段階（共通用語）

EOL は単一の日付ではありません。各段階をひとつの告知にまとめると、「まだ使えると思っていたのに」という問い合わせが殺到します。

• GA（一般提供）： 積極的に販売され、全面的なサポートを受けられます
• NSC（ステータス変更の通知）： 決定が伝えられ、計画の策定が始まります
• EOS（販売終了）： 新規顧客は購入できなくなります
• EOE（拡張終了）： 既存顧客は容量やシートを追加できなくなります
• EOR（更新終了）： 既存の契約は更新されなくなります
• EOM（メンテナンス終了）： バグ修正とパッチの提供が終了します
• EOL（ライフ終了）： 製品が廃止されます
• EOSRV（サービス終了）： すべてのサポートとサービスの提供義務が終了します

簡潔なメッセージでは、2～3段階を示します。詳細なメッセージでは、表を使って8段階すべてを示します。どの段階を取り上げる場合でも、顧客の立場で説明してください。「引き続きご利用いただけますが、修正は提供されません」のほうが、「EOM：2027年3月」より伝わります。

EOL メッセージのフレームワーク

効果的な EOL メッセージは、変更を率直に伝えることと、顧客への影響に配慮することのバランスを取ります。

1. 会社の背景： 自社について、また顧客への取り組みについて
2. 発表内容： 何が終了し、何に置き換わるのか
3. 理由： それが顧客にどのようなメリットをもたらすのか（ビジネス上のメリットだけでなく）
4. 現在の製品について： その製品がどのようなもので、誰に利用されていたのか
5. 顧客への影響： ユーザーにどのような影響があるのか（混乱が生じることを認める）
6. 移行先のソリューション： 移行先と、現在の製品との比較
7. サポート体制： 移行先へ進むためにどのような支援を提供するのか
8. スケジュール： 重要な日付と各段階
9. 次のアクション： 次の手順と連絡先

効果がある理由

• 共感を優先： 判断の正当性を説明する前に、混乱が生じることを認めます
• 明確さ： 何がいつ変わるのかを曖昧にしません
• サポート重視： 移行の途中で顧客を見捨てない姿勢を示します
• 未来志向： 変化を喪失ではなく前進として伝えます

付箋ルール

顧客が一度読んだだけで、何をいつまでにすべきかを付箋に書けるようにしてください。できないなら、そのメッセージは飾りにすぎません。送信前に、すべての草稿をこの基準で確認してください。

反パターン（これは避けてください）

• 簡素すぎるサービス終了の告知ではない： 「製品 X の提供を終了します。さようなら。」
• ビジネス中心ではない： 「コスト削減につながります」から始めないでください
• 曖昧ではない： 「まもなく」はスケジュールではありません
• 弁解がましくない： 顧客を責めないでください（「利用率が低かったため、終了を余儀なくされました」など）
• 一律ではない： すべての提供終了に同じ長さのテンプレートを使うのは、規模の不適合です

使用する場合

• 製品、機能、サービスの提供を終了するとき
• 顧客をレガシープラットフォームから新しいプラットフォームへ移行するとき
• 買収した製品の提供を終了するとき
• テクノロジースタックや API を非推奨にするとき

使用しない場合

• 顧客にできることが変わらない小さな調整の場合（過剰な告知は避けてください）
• 移行計画が整う前（顧客をどう支援するかが決まってから伝えてください）
• 顧客に気づかれないことをひそかに期待している場合（透明性を保ってください）

---

適用

全項目を記入するテンプレートの構成については、template.md を使用してください。

ステップ 1：規模と進め方を決める

草稿を作成する前に、次の 2 点を決めます。

規模： 簡潔、標準、詳細のいずれかです。顧客数、売上、契約、ハードウェアやパートナーの関与の有無など、影響範囲に基づいて推奨案を示し、そのうえでユーザーが変更できるようにします。簡潔な形式では省かれる内容を、一文で説明してください。

進め方： 置き換え、移行、または段階的な終了です。これによって、メッセージで何を強調するか、また「移行先のソリューション」セクションが位置づけの説明になるか、終了計画になるかが決まります。

ステップ2: コンテキストを収集する

• 廃止される製品: 具体的に何が終了するのか?
• 移行先: 何かが置き換わる場合、それは何か?
• タイムライン: どのゲートが適用され、それぞれがどの日に該当するのか?
• 顧客への影響: ユーザーは何人か? どのワークフローが中断されるのか?
• サポート計画: 移行支援、トレーニング、割引、データエクスポートツール
• 根拠: なぜこれが起きるのか?
• 制約事項: 契約文言、規制要件、行った「永久」の約束

コンテキストが不足している場合: 移行計画が整うまで送信しないでください。顧客は「今、自分は何をすればいいのか?」と尋ねます。あなたには答えがなければなりません。下書きは問題ありませんが、送信はまだです。

---

ステップ3: 移行のストーリーを起草する

会社のコンテキスト

**We are:** [Company and its relationship to the product being phased out]
- [Commitment to customers]
- [How the product line evolves]
- [Where you're headed]

例:

**We are:** Fieldlight, a field service management platform serving 4,000 service businesses
- We're committed to getting your technicians to the right job with the right information
- We continuously evolve the platform based on how crews actually work
- We're building toward scheduling that adapts in real time to what happens in the field

発表

**Announcing:**
- [Single sentence stating the EOL clearly and naming the landing place]

例: 「当社は Fieldlight Classic Dispatch を2026年12月31日をもって終了し、すべてのアカウントを Fieldlight Next Scheduling に移行します。」

円満な終了のバリエーション: 「当社は Fieldlight Route Optimizer を2027年6月30日をもって終了します。後継製品はなく、その点は率直にお伝えしたいと考えています。」

根拠(顧客のメリットに焦点を当てる)

**Because:**
- [Reason 1]
- [Reason 2]
- [Reason 3]

**Which means for you:**
- [Impact and benefits from the customer's perspective]

例:

**Because:**
- Classic Dispatch runs on infrastructure that can't support real-time schedule changes
- Next Scheduling reoptimizes routes as jobs run long or get cancelled
- Consolidating lets us put all engineering effort into one scheduler instead of two

**Which means for you:**
- Schedules that adjust when the day goes sideways, instead of at 6am only
- Technician arrival windows you can actually promise customers
- Every future scheduling improvement lands in the product you're on

---

ステップ4: 現行製品のコンテキストを示す

失われるものを認識します。Brief メッセージではこのセクションを省略します。

**Our product** [name]
- **is a** [description and primary function]
- **that has served** [customer type] for [duration]
- **by providing** [key benefits it delivered]

---

ステップ5: 顧客への影響を認識する

混乱について正直に伝えます。ここで労力を過小評価することは、メッセージ全体の中で最も有害な近道です。

**We understand that this may affect you by:**
- [Impact 1 on operations or process]
- [Impact 2]
- [Impact 3]

例:

**We understand that this may affect you by:**
- Requiring you to rebuild recurring dispatch rules (most accounts: 2-3 hours)
- Retraining dispatchers on a different scheduling board
- Updating any integrations that read the Classic dispatch API

---

ステップ6: 移行ソリューションを提示する

代替または移行パス — ポジショニングステートメントの形式を使用します(positioning-statement を参照):

**For** [affected customer]
- **that currently use** [old product]
- [replacement]
- **is a** [category]
- **that** [benefit, focused on continuity and improvement]

### Differentiation and Continuity
- **Like** [old product],
- [replacement]
- **provides** [what carries forward]
- **while also offering** [what's new]

円満な終了のパス — 上記を正直な終了計画に置き換えます:

### What Happens to Your Data
- [Export format, how to get it, how long it stays available]

### Alternatives We'd Point You To
- [Option 1, including competitors, with a note on fit]
- [Option 2]

### What We're Doing to Help
- [Extended access, export tooling, migration credits, refunds where owed]

---

ステップ7: サポート施策とタイムラインの概要を示す

**To ensure a smooth transition, we will:**
- [Support measure 1]
- [Support measure 2]
- [Support measure 3]

### Timeline
| Gate | Date | What it means for you |
|---|---|---|
| [Gate] | [Date] | [Plain-language consequence] |

品質チェック:

• 十分なリードタイム: Standard では6〜12か月が一般的です。契約やハードウェアの場合はより長くなります
• 顧客の言葉で示すゲート: 「EOM」ではなく「修正の提供が終了します」
• データエクスポートの期限を明示: 顧客が自分のデータにアクセスできなくなるのはいつですか?

---

ステップ8: 明確な次のステップを示す

### Call to Action
- [Specific first action, with the link or path]
- [How to get help, with real contact info]

---

最終ステップ: 次に何ができるかを提案する

下書きを届けた後、番号付きの選択肢を提案します:

「次に進める道はこちらです:

1. 厳しく検証する — 懐疑的な顧客として読み返し、不明確な点を指摘します
2. サイズを変更する — この同じメッセージの Brief 版または Full 版を作成します
3. セグメント化する — エンタープライズアカウント、SMB、パートナー向けに、それぞれに必要なものが異なるバリエーションを作成します
4. 準備状況のケースを確認する — 意思決定そのものをまだ擁護する必要がある場合は eol-readiness-advisor を参照してください

番号を選ぶか、組み合わせるか、必要なことを教えてください。」

---

例

• examples/sample.md — Fieldlight Classic Dispatch(SaaS、Standard サイズ、代替パス)
• examples/sample-industrial.md — NFA-200 コントローラーライン(産業用、Full サイズ、代替に加えてチャネルと規制上の義務)

ミニ抜粋:

**Announcing:** We are retiring Fieldlight Classic Dispatch on December 31, 2026
**Because:** Classic can't support real-time schedule changes
**Which means for you:** Schedules that adjust when the day goes sideways

---

よくある落とし穴

落とし穴1: ビジネス中心の根拠

症状: 「当社はコスト削減とポートフォリオ統合のために製品Xを廃止します。」

結果: 顧客は、ビジネス上の意思決定における巻き添えのように感じます。

解決策: 根拠を顧客のメリットに合わせて組み立てます: 「当社は製品Yに統合することで、お客様が求められてきた機能にすべてのエンジニアリングを投入できるようにします。」

---

落とし穴2: 曖昧なタイムライン

症状: 「製品Xはまもなく廃止されます。」

結果: 顧客は計画を立てられません。不安と離反が増加します。

解決策: 名前を付けたゲートに対して具体的な日付を示します: 「3月1日: 新規購入の受付を終了。12月31日: 完全停止、データエクスポートの期限。」

---

落とし穴3: サポート計画がない

症状: 「製品Yに移行していただく必要があります。幸運を祈ります!」

結果: 顧客は見捨てられたと感じます。高い離反リスクがあります。

解決策: 実質的な支援を提供します: マンツーマンでの支援、自動移行ツール、移行価格、トレーニング。

---

Pitfall 4: 顧客への影響を無視する

症状： 告知から「新製品をご紹介します！」へと話が飛びます。

結果： 顧客は、自分たちの懸念が受け止められていないと感じます。

対処法： 作業にかかる時間も含め、どのような混乱が生じるのかを明確に伝えます。

---

Pitfall 5: 素っ気ない、または防御的なトーン

症状： 「利用率が低いため、Product X を終了します。」

結果： 実際に利用していた顧客を責めているように聞こえます。

対処法： 共感を示し、前向きな姿勢で伝えます。利用率の低さは自社のビジネス上の事情であり、顧客の責任ではありません。

---

Pitfall 6: すべての終了告知を同じ形式にする

症状： 終了のたびに同じ長文テンプレートを使うか、毎回変更履歴に一行だけ記載します。

結果： 些細な変更にも長文で告知すると、顧客は告知を読み飛ばすようになり、本当に重要な告知も見過ごされます。実際のサービス終了を変更履歴の一行だけで伝えると、サポートへの問い合わせが発生します。

対処法： 簡潔版、標準版、詳細版を意識して選び、その理由を伝えます。簡潔な形式にする場合は、どのセクションを省いたのかを把握しておきます。

---

参考資料

関連スキル

これらのスキルは単独で利用でき、このスキルの前提条件となるものも、このスキルが前提条件となるものもありません。準備状況の評価を実施して強度レベルが決まっている場合は、「レベル 2」のように伝えるだけで、このスキルがそれに合わせてメッセージの規模を調整します。

• eol-readiness-advisor — サービス終了の可否判断と強度の調整。このサービス終了自体の妥当性をまだ検討する必要がある場合に役立ちます
• positioning-statement — 移行先のソリューションの検討に役立ちます
• problem-statement — 顧客への影響を伝えるセクションの構成に役立ちます
• proto-persona — 顧客層ごとのバリエーションで対象となる顧客を定義します

外部フレームワーク

• 危機コミュニケーションのベストプラクティス — 透明性、共感、行動
• カスタマーサクセスのプレイブック — 製品の移行期間中の顧客維持

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/eol-for-a-product-message.md を基にしています。