eol-internal-enablement

EOL 内部イネーブルメント

目的

EOL の発表前に、顧客対応チームが必要とするものを整えます。サポート FAQ、正直な比較データを盛り込んだ営業向けの説明ポイント、反論への対応、エスカレーション手順、そしてサンセットの規模に応じて、チャネルパートナー向け概要資料とトレーニングの概要を用意します。

EOL のコミュニケーションにおける最大の過ちは、顧客への発表の5分前にサポートと営業へ発表内容を渡し、あとは幸運を祈ることです。このスキルは、そうした事態を防ぐためにあります。社内の準備は発表後のタスクではなく、発表の前提条件です。

入力

特に役立つ情報： サンセットする製品、それに代わるもの（あれば）、主要な日付です。

あるとさらに役立つ情報： 想定される反論、リスクのあるアカウント、継続するものと終了するもの、チャネルパートナーが関係するかどうかです。

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

何も用意できていなくても大丈夫です。 このスキルでは、最大3つの質問をします。サンセットするものとその代替、販売・サポート・サービスの終了日、想定される主な反論について確認し、その後、資料一式を作成します。反論がわからない場合は、想定される反論の案を作成するので、編集してください。

呼び出し例：

• 旧式モジュールのサンセットに向けたイネーブルメント資料を作成してください。新しいダッシュボードに置き換え、EOL は12月31日です。
• サポート FAQ のみ、機能の非推奨化、代替なし、告知期間は3週間です。

---

主なコンセプト

資料の規模を適切にする

EOL の進行はどれも同じではありません。 多くの場合、中間的な規模になります。

	レベル1 — 軽量	レベル2 — 標準	レベル3 — 大規模
典型的な範囲	機能、社内ツール、API	商用製品、アクティブな顧客	収益に不可欠な製品、ハードウェア、規制対象
作成するもの	サポート FAQ のみ（Q&A 10～15件）	＋営業向けの説明ポイント、反論対応、エスカレーション手順書	＋チャネルパートナー向け概要資料、アカウントのエスカレーション段階、トレーニングの概要
対象者	サポート	サポート、営業、CS	＋パートナー、経営幹部、フィールドサービス
準備期間	半日	1週間	ライブトレーニングを含めて数週間

標準はレベル2です。 レベルを推奨し、その理由を1行で伝え、ユーザーが変更できるようにします。 レベル3をデフォルトにしてはいけません。 機能の非推奨化に対して充実したトレーニングプログラムを用意すると、チームは EOL のイネーブルメントを煩雑な手続きだと捉え、本当に重要な案件への関心まで失います。

サポート FAQ のみに規模を縮小する場合は、何を省くのかを明示してください。通常は反論対応です。顧客から「前四半期に契約を更新した」と言われたとき、営業に必要となるものです。

常に発表より先にイネーブルメントを行う

発表日より前の日付を「イネーブルメント完了日」として明確に設定してください。計画上でこの2つの日付が分かれていないと、実際には同じ日になってしまい、サポートがサンセットを怒った顧客から知らされることになります。

顧客からの質問に沿って FAQ を構成する

社内のカテゴリ別にはしません。問い合わせ件数が最も多くなる質問から始めてください。必ず出てくる質問は、概ね次の順です。

1. 何が起きるのですか？
2. 私にはどのような影響がありますか？
3. どのような選択肢がありますか？
4. データはどうなりますか？
5. 契約はどうなりますか？
6. サポートはいつ終了しますか？

回答は1～2文で、正直かつ具体的な内容にしてください。「選択肢を検討中です」は回答ではなく、先送りです。顧客にはごまかしだと受け取られます。

受け止める — 捉え直す — 提案する

あらゆる異議への対応は、同じ3段階のパターンに従います。

1. 受け止める — 言いよどんだり、何度も謝ったりせず、相手の不満がもっともであると認めます
2. 捉え直す — 損失が現実ではないかのように装わず、正直な理由や本当のメリットを伝えます
3. 提案する — 担当者が実際に提供できる、具体的な配慮、選択肢、または次のステップを示します

順序が重要な理由： プレッシャーを受けているチームは、すぐに提案から始めて賄賂のような印象を与えたり、捉え直すことから始めて説教のような印象を与えたりしがちです。最初に受け止めることで、残る2つが相手に伝わりやすくなります。それに費用はかかりません。

提案は実現可能なものでなければなりません。 「何ができるか確認します」で終わる異議対応では、会社の承認を得ていない約束をするよう担当者に教えてしまいます。提案する配慮は、資料に入れる前に承認を得てください。

予想される異議

提供終了時には、ほぼ必ず次の5つが出てきます。他に何がありそうか尋ねる前に、これらへの回答を作成してください。

1. 「つい最近購入したばかりです／前四半期に更新したばかりです。」
2. 「代替製品には機能Xがありません。」
3. 「完全に離れるつもりです。」
4. 「次の製品をどうして信頼できるのですか？」
5. 「例外対応をしてもらえますか？」

4つ目は、チームが最も答えにくい質問です。正直に答えるには、今回の移行にどう対応しているかについて話す必要があります。今回の提供終了への対応が、次の約束に対する根拠になるからです。

エスカレーションは担当者が明確な段階構造です

担当者と発動条件を明確にした、4段階のエスカレーション経路を用意します。

• レベル1 — 通常の問い合わせ（サポート）
• レベル2 — 不満を抱えている顧客（サポートリードまたはCS）
• レベル3 — 解約リスクのあるアカウント（CSリードまたはアカウントエグゼクティブ）
• エグゼクティブ — 担当者が明確なアカウント、報道機関、法的措置を示唆する相手

担当者の名前がないエスカレーション経路は、ただの図です。担当者は、金曜日の午後4時に誰へ電話すればよいのかを知っている必要があります。

付箋ルール

箇条書きは4〜8語にします。FAQの回答は1〜2文にします。担当者は研修室ではなく、電話対応の合間にこれを読みます。

アンチパターン（これは何ではないか）

• 顧客向けのお知らせではありません。 顧客に伝える前に、チームが把握しておくべき内容です。
• 声に出して読む台本ではありません。 これは準備のためのものであり、プロンプターではありません。
• ごまかしではありません。 守りに入ったトークポイントは、1回の通話で見限られてしまいます。
• レベル1でも任意ではありません。 機能の非推奨であっても、サポート担当者はどう伝えるべきかを知っている必要があります。

---

適用

ステップ1：レベルと日付を決める

影響範囲に基づいてレベルを推奨し、3つの選択肢をすべて提示したうえで、ユーザーに選んでもらいます。次に、2つの日付を確定します。発表日と、それに先立つイネーブルメント完了日です。

ステップ2：サポートFAQを作成する（全レベル）

上記の顧客からの質問6項目を基に整理し、10〜15組のQ&Aを作成します。顧客が納得する回答を書いてから、実際の事実に照らして確認します。両者に食い違いがある場合、問題は表現ではなく計画にあります。その点を指摘してください。

FAQの最後に、担当者名を明記したエスカレーション経路を含めます。

ステップ3：営業向けトークポイントを作成する（レベル2以上）

• ポジショニング： どのように説明するか、避けるべき表現、最初に伝える内容
• 比較表： 提供終了する製品と代替製品を、機能ごとに比較します。機能の不足も含めてください。 不足点のない比較表はマーケティング資料にすぎず、顧客が不足点を見つけたとたん、担当者はその表を信用しなくなります。
• パイプラインに関するガイダンス： 進行中の商談、更新待ち、バンドル価格、新規見込み客からの質問
• 競合への対応： 競合他社が自社のEOLを持ち出したとき、また顧客から他にも終了する製品があるのか尋ねられたときの伝え方

ステップ4：異議対応を作成する（レベル2以上）

予想される5つの異議から始めます。この製品と顧客層に特有のものを2〜3つ追加します。それぞれについて、「受け止める — 捉え直す — 提案する」の手順で回答を作成し、提案は事前に承認を得てください。

ステップ 5：チャネル向けブリーフとトレーニング（レベル 3）

チャネル向けブリーフでは、パートナーが知っておくべきこと、顧客に伝えてもよいこと、そしてしてはならないことの 3 点を取り上げます。3 つ目は、パートナーが実現できない移行を約束してしまうのを防ぐものです。

トレーニングの概要は 60～90 分です。背景と理由、タイムラインの説明、FAQ の確認、異議への対応のロールプレイ、エスカレーションの経路、未解決の質問を扱います。効果があるのはロールプレイです。異議への対応方法を黙読するだけでは、とっさに対応する力は身につきません。

ステップ 6：前提

最後に、前提としていたことを示します。実際に聞いたのではなく予測した異議、承認済みだと考えている特別対応、確定したものとして扱った日付などです。

最後のステップ：次のアクションを提案する

「次は何をしますか？

1. 顧客向け告知を作成する — eol-message を参照（推奨）
2. リスクの高い上位顧客向けにアカウント固有の説明ポイントを作成する
3. トレーニングセッション用のロールプレイシナリオを作成する
4. 告知後 30 日間のモニタリングチェックリストを作成する

番号、組み合わせ（「1 と 2」など）、または独自の進め方で返信してください。」

---

例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS、レベル 2 パック）
• examples/sample-industrial.md — NFA-200 コントローラー製品ライン（産業向け、チャネル向けブリーフ付きレベル 3）

---

よくある落とし穴

落とし穴 1：告知後の準備

症状： メールを送信する週に FAQ を作成します。

結果： サポートが 3 日間、その場しのぎの対応をします。その対応が事実上のポリシーとなり、互いに矛盾するものも出てきます。

対策： 計画に「準備完了」の日付を設定し、その日付を告知の前提条件とします。

---

落とし穴 2：欠点のない比較表

症状： すべての項目で、後継製品が提供終了製品と同等か、それ以上であると示されています。

結果： 顧客が実際の不足点を 1 つでも挙げると、表全体の信頼性が損なわれ、営業担当者は次に何を伝えればよいかわからなくなります。

対策： 不足点を明示し、それぞれの横に回避策または同等機能の提供時期を記載します。譲歩できる営業担当者は、ほかの説明についても信頼を保てます。

---

落とし穴 3：防御的な異議対応

症状： 顧客がそう感じるべきではない理由を説明する返答です。

結果： 顧客がエスカレーションします。反応が間違っていると言われることは、最初の知らせよりもつらいからです。

対策： 必ず、まず相手の気持ちを受け止めます。決定が正当な場合でも、相手の不満には理由があります。

---

落とし穴 4：予算の裏付けがない提案

症状： 異議への対応の最後に、承認されていない特別対応（割引、期限延長、カスタム移行など）を提案します。

結果： 営業担当者が約束し、財務部門が拒否するため、顧客の不満が 2 つになります。

対策： パック内の提案はすべて、上限を含めて事前に承認します。承認されていないものは、パックに含めません。

---

落とし穴 5：担当者がわからないエスカレーション

症状： 「適切なチームにエスカレーションしてください。」

結果： 解約リスクのある顧客との電話対応が、キューに入ったまま 2 日間放置されます。

対策： 4 段階のエスカレーション経路を定め、それぞれに担当者名と条件を設定します。営業担当者に誰に電話するか尋ねて、実際に機能するか確認してください。

---

参考資料

関連スキル

これらのスキルはそれぞれ単独で利用できます。このスキルの前提となるものはなく、このスキルもそれらの前提ではありません。別の場所ですでにレベルを選んでいる場合は、「レベル 2」のように指定すると、このスキルでそのレベルに合わせて作成します。

• eol-message — チームが準備する顧客向け告知
• eol-stakeholder-sequence — このパックに含める内容を明らかにするための対話
• eol-checklist — 準備完了の日付を記載する場所
• eol-readiness-advisor — 意思決定の根拠がまだ必要な場合に使用します
• incoming-request-advisor — このパックによって発生するエスカレーションの内容を把握するために使用します

外部フレームワーク

• 受け止める・捉え直す・提案する — 異議対応のパターン
• カスタマーサクセスのプレイブック — 移行期間中の顧客維持施策

出典

• https://github.com/deanpeters/product-manager-prompts リポジトリの prompts/eol-internal-enablement.md をベースにしています。