eol-internal-enablement

EOL 内部赋能

目的

在 EOL 公告发布之前，为面向客户的团队准备好所需内容：支持常见问题解答、附有真实对比数据的销售沟通要点、异议处理方案、升级处理阶梯，以及在停用影响较大时准备的渠道合作伙伴简报和培训大纲。

EOL 沟通中最严重的失误，就是在客户收到公告前五分钟才把公告交给支持和销售团队，然后祝他们好运。这项技能旨在防止这种情况。内部准备是发布公告的前提，而不是后续任务。

输入

效果最佳的输入： 正在停用的产品、替代产品（如有）以及关键日期。

也很有用： 你预期会遇到的异议、面临风险的客户、哪些内容会继续、哪些会停止，以及是否涉及渠道合作伙伴。

随调用一同提供的任何内容——技能名称后的文本、粘贴的上下文内容，或附加的 ARGUMENTS: 行——都视为已提供的答案。请使用这些信息，并跳过其中已涵盖的问题；不要重复询问。

没有准备任何信息？也没问题。 该技能最多会提出三个问题——要停用什么、有什么替代产品，以及停止销售、支持和服务的日期；还会询问你预期会遇到的主要异议——然后生成资料包。如果你不清楚会遇到哪些异议，它会先拟出常见的异议供你编辑。

调用示例：

• 为我们的旧版模块停用制定赋能资料包——将由新仪表板替代，EOL 日期为 12 月 31 日。
• 仅需支持常见问题解答，弃用功能，没有替代方案，提前三周通知。

---

关键概念

让资料包与实际需求相匹配

并非所有 EOL 的情况都一样。 大多数情况介于两者之间：

	级别 1 — 轻量	级别 2 — 标准	级别 3 — 全面
典型范围	功能、内部工具、API	商业产品、有活跃客户	对收入至关重要的产品、硬件、受监管产品
产出内容	仅支持常见问题解答（10-15 组问答）	+ 销售沟通要点、异议处理方案、升级处理手册	+ 渠道合作伙伴简报、客户升级处理层级、培训大纲
受众	支持团队	支持、销售、CS	+ 合作伙伴、高管、现场服务团队
准备时间	一个下午	一周	数周，并包含现场培训

默认采用级别 2。 推荐一个级别，用一句话说明原因，并允许用户调整。 绝不要默认采用级别 3——为功能弃用安排完整的培训计划，会让团队觉得 EOL 赋能只是官僚流程；等真正重要的情况出现时，他们就会置之不理。

如果有人将范围缩小到仅提供支持常见问题解答，请明确指出哪些内容会被删掉：通常是异议处理方案，而当客户说“我们上个季度才续约”时，销售团队正需要这部分内容。

务必先完成赋能，再发布公告

明确设定“赋能完成日期”，并确保它早于公告日期。如果计划中没有明确区分这两个日期，实际执行时它们就会混为一谈，支持团队也就只能从愤怒的客户那里得知产品停用的消息。

按客户会问的问题组织常见问题解答

不要按内部类别组织。首先列出最可能引发大量来电的问题。以下六个问题总会出现，大致按顺序排列：

1. 发生了什么？
2. 这对我意味着什么？
3. 我有哪些选择？
4. 我的数据怎么办？
5. 我的合同怎么办？
6. 支持服务何时结束？

每个回答用一到两句话，做到诚实具体。“我们正在评估各种方案”并不是答案，而是推诿；客户会觉得你在回避问题。

承认 — 重塑认知 — 提供方案

回应每种异议都遵循相同的三步模式：

1. 承认 — 肯定对方的挫败感是合理的，不要含糊其辞或重复道歉
2. 重塑认知 — 诚实说明原因或真正的好处，不要假装损失并不存在
3. 提供方案 — 给出销售代表确实能够落实的具体补救措施、选项或后续步骤

顺序为何重要： 处于压力之下的团队会直接跳到提供方案，这听起来像是在贿赂客户；或者直接跳到重塑认知，这听起来像是在说教。先承认对方的感受，后两步才能奏效，而且不需要任何成本。

提供的方案必须切实可行。 以“我看看能做些什么”收尾的异议应对话术，会让销售代表养成公司尚未同意就做出承诺的习惯。将补救措施纳入资料包之前，先取得批准。

可预见的异议

几乎每次产品停用都会出现以下五种异议。先起草应对内容，再询问还有哪些可能出现：

1. “我们刚买了这个产品／上个季度刚续约。”
2. “替代产品没有 X 功能。”
3. “我们打算彻底离开。”
4. “我们凭什么相信你们的下一个产品？”
5. “能不能为我们破例？”

团队最不擅长回答第四个问题，因为诚实的答案关乎你们如何处理这次过渡——当前的停用安排，就是下一个承诺的佐证。

升级处理是有明确责任人的阶梯

四个级别，每一级都有明确的负责人和触发条件：

• Level 1 — 常规问题（支持团队）
• Level 2 — 不满的客户（支持团队负责人或 CS）
• Level 3 — 有流失风险的客户（CS 负责人或客户经理）
• 高管级 — 指定客户、媒体、法律威胁

没有明确负责人的升级路径只是一张图。销售代表需要知道周五下午 4 点该打给谁。

便笺规则

要点控制在 4 到 8 个词。FAQ 答案控制在一到两句话。销售代表会在两通电话之间阅读这些内容，而不是在培训室里阅读。

反模式（这份资料不是什么）

• 不是面向客户的公告。 这是团队在客户获知之前需要了解的内容。
• 不是照读的脚本。 这是事前准备，不是提词器。
• 不是粉饰。 防御性的谈话要点撑不过一通电话，之后就会被弃用。
• 不是 Level 1 可选的内容。 即使是功能弃用，支持团队也需要知道该怎么说。

---

应用

步骤 1：确定级别和日期

根据影响范围建议一个级别，列出全部三个级别，让用户选择。然后确定两个日期： 公告日期，以及在此之前的赋能完成日期。

步骤 2：编写支持团队 FAQ（适用于所有级别）

准备十到十五组问答，按照上文提到的六类客户问题组织。先写出客户能够接受的答案，再核对其是否符合实际情况。如果两者不符，问题出在计划，而不是措辞——请标明这一点。

在 FAQ 末尾附上升级处理阶梯，并写明负责人。

步骤 3：编写销售谈话要点（Level 2 及以上）

• 定位： 如何介绍、应避免使用哪些措辞、应先强调什么
• 对比表： 停用产品与替代产品逐项对比能力——包括差距。没有列出差距的对比表只是营销资料，客户第一次发现差距后，销售代表就会不再信任它。
• 销售管线指引： 正在推进的交易、待续约合同、捆绑定价、提出询问的新潜在客户
• 竞争应对： 竞争对手提起你们的 EOL 时该怎么说，以及客户询问是否还有其他产品即将停用时该怎么回答

步骤 4：制定异议应对方案（Level 2 及以上）

从五种可预见的异议开始。再补充两到三种针对该产品和客户群体的特定异议。每种异议都采用“承认—重塑认知—提供方案”模式，并确保方案已经预先获批。

步骤 5：渠道简报与培训（Level 3）

渠道简报涵盖三件事：合作伙伴需要了解什么、可以告诉客户什么，以及绝对不能做什么。第三点能避免合作伙伴擅自承诺你无法兑现的迁移方案。

培训大纲时长为 60-90 分钟：背景与理由、时间线介绍、常见问题回顾、异议角色扮演、升级路径、开放问题。真正有效的是角色扮演——默默阅读异议应对话术无法培养应对本能。

步骤 6：假设

最后说明你的假设：哪些异议是你预测的，而不是实际听到的；哪些便利措施你认为已获批准；哪些日期你视为确定日期。

最后一步：提供后续选项

“接下来做什么？

1. 起草客户公告 — 参见 eol-message（推荐）
2. 为最有流失风险的客户制定专属沟通要点
3. 为培训课程编写角色扮演场景
4. 创建公告发布后 30 天的监控清单

请回复一个数字、组合选项（‘1 和 2’），或提出你自己的方案。”

---

示例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS，Level 2 套件）
• examples/sample-industrial.md — NFA-200 控制器产品线（工业，含渠道简报的 Level 3 套件）

---

常见误区

误区 1：公告发布后才开展赋能

表现： 邮件发出的那一周才起草常见问题解答。

后果： 支持团队临场应对三天。他们临时想出的说法会成为你事实上的政策，其中有些还会互相矛盾。

解决方法： 将“赋能工作完成”设为计划中的一个日期，并以此作为公告发布的前置条件。

---

误区 2：毫无缺口的对比表

表现： 每一行都显示替代产品与即将停用的产品持平或更胜一筹。

后果： 第一个指出实际缺口的客户就会让整张表失去可信度，而销售代表也无话可说。

解决方法： 明确列出缺口，并在旁边注明变通方案或达到功能对等的日期。能够坦承不足的销售代表，才能在其他方面保持可信度。

---

误区 3：防御式异议处理

表现： 回应中解释客户为什么不应该有这种感受。

后果： 客户会升级处理，因为被告知自己的反应不对，比最初听到这个消息更糟。

解决方法： 始终先表示理解。即使决策正确，客户的失望也合情合理。

---

误区 4：未经批准的承诺

表现： 异议应对话术以无人批准的便利措施收尾——折扣、延期、定制迁移。

后果： 销售代表作出承诺，财务部门拒绝兑现，客户于是又多了一项不满。

解决方法： 套件中的每项优惠都必须预先获批并设定限额。未经批准的内容，不得纳入套件。

---

误区 5：升级对象不明确

表现： “升级给相关团队处理。”

后果： 有流失风险的客户来电在队列里等上两天。

解决方法： 设置四级升级路径，每一级都明确负责人和触发条件。可以问问销售代表会联系谁，以此检验路径是否清晰。

---

参考资料

相关技能

这些技能都可独立使用——它们都不是本技能的前置要求，本技能也不是它们的前置要求。如果你已在其他地方选择了级别，只要说“Level 2”，本技能就会据此构建内容。

• eol-message — 为团队准备客户公告
• eol-stakeholder-sequence — 通过沟通发掘应纳入此套件的内容
• eol-checklist — 记录赋能工作完成日期
• eol-readiness-advisor — 如果仍需为决策提供依据
• incoming-request-advisor — 解读此套件将引发的升级请求

外部框架

• 表示理解-重新构建-提出方案（Acknowledge-Reframe-Offer）——异议处理模式
• 客户成功手册——过渡期间的留存策略

来源

• 改编自 https://github.com/deanpeters/product-manager-prompts 仓库中的 prompts/eol-internal-enablement.md。