eol-message

EOL 消息

目的

撰写一则清晰、有同理心的停用（EOL）消息，说明服务停止、解释原因、回应客户影响、提供过渡支持，并介绍后续安排。借此在艰难的过渡期间维护客户信任，减少客户因感到被抛弃而流失。

这不是一则泛泛的停用公告，而是一种以客户为中心的沟通方式：承认失去，同时将变化呈现为进步。而且，消息篇幅应与变化相称：弃用一个开关只需一段话，退役一款旗舰产品则需要数月内分阶段沟通。

输入

最适合提供： 即将退役的内容（产品、功能或方案）以及大致时间。

也很有帮助： 原因、受影响的客户群、迁移或替代方案、支持承诺，以及任何限制可用表述的合同或法规措辞。

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

没提供任何信息？也没关系。 该技能会先询问退役内容、时间、原因和后续去向，再起草消息，然后建议合适的篇幅；你可以更改建议。EOL 消息如果没有说明原因和下一步，就会让客户觉得被抛弃——因此，无论如何都会询问这两点。

调用示例：

• 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.

---

关键概念

让消息篇幅与变化相称

EOL 消息最常见的问题不在语气，而在分寸。为一个弃用的复选框发布包含六个部分的公告，会让客户习惯性忽略你的通知。对于承载重要工作流的产品，只发一行通知，则可能引发支持事故。

	简短版	标准版	完整版
适用情况	功能、内部工具、无人使用的选项	商业产品、活跃客户	对收入至关重要的产品、硬件、受监管产品
长度	1-3 段	1 页，含阶段表	多部分内容，数月内分阶段发布
使用的部分	公告、时间线、行动号召	全部 9 个部分，简要呈现	全部 9 个部分 + 合规与义务
提前通知时间	数周	6-12 个月	12-24 个月
渠道	应用内或更新日志	电子邮件 + 应用内 + 文档	电子邮件 + 客户团队 + 合作伙伴 + 新闻媒体

大多数公告都应采用标准版。 建议一个篇幅，用一句话说明原因，并允许用户调整。如果用户为你认为应采用标准版的内容选择了简短版，请指出因此会缺少的那一项内容——通常是阶段表，它能避免收到“等等，什么时候会停止工作？”这类支持工单。

三种过渡路径

你真正需要告诉客户的是他们接下来会去往何处。答案有三种，对应的消息也截然不同：

1. 替代 — 由你的另一款产品接手。消息侧重延续性：哪些内容会保留，哪些方面会改进。此时，如何定位最为重要。
2. 迁移 — 仍在同一产品系列中，但需切换到不同的层级、配置或平台。消息侧重具体操作：客户需要做什么、何时完成，以及需要投入多少工作。请如实说明工作量；低估工作量是最快失去信任的方式。
3. 妥善退出 — 没有替代方案。消息侧重体面处理：诚实说明原因、提供数据导出、给予充足通知时间，并提供真正可行的替代选择，包括竞争对手的产品。提及竞争对手所付出的代价，远低于让客户无处可去造成的声誉损失。

妥善退出是团队最容易写得不好的情形，因为它也最让团队感到难受。但客户对这种情况的评判也最为严苛。

生命周期阶段（通用术语）

EOL 并非一个日期。将这些阶段合并为一则公告，正是引发“可我以为还能用”的支持咨询潮的原因：

• GA（正式发布）： 正在积极销售并提供全面支持
• NSC（状态变更通知）： 通知已发布；开始规划
• EOS（停止销售）： 不再接受新客户购买
• EOE（停止扩展）： 现有客户无法增加容量或席位
• EOR（停止续约）： 现有合同将不再续约
• EOM（停止维护）： 停止提供错误修复和补丁
• EOL（生命周期结束）： 产品退役
• EOSRV（停止服务）： 所有支持和服务义务终止

简短消息会提及两到三个阶段。完整消息会在表格中列出全部八个阶段。无论使用哪些阶段，都要用客户能理解的说法来解释——“您可以继续使用，但我们不会再发布修复”比“EOM：2027 年 3 月”更清楚。

EOL 消息框架

有效的 EOL 消息应兼顾对变更的坦诚，以及对客户所受影响的体谅：

1. 公司背景： 您是谁，以及您对客户的承诺
2. 公告内容： 哪些内容将终止，以及将由什么取代
3. 原因： 这为何能让客户受益（而不只是让公司受益）
4. 当前产品背景： 产品是什么，以及服务于哪些用户
5. 对客户的影响： 这会如何影响用户（承认变更造成的干扰）
6. 过渡方案： 后续去向，以及与当前方案的比较
7. 支持措施： 您将如何帮助客户完成过渡
8. 时间线： 关键日期和阶段
9. 行动号召： 后续步骤和联系信息

为什么有效

• 先体谅客户： 在解释决策前先承认变更造成的干扰
• 清晰明确： 对变更内容和时间没有歧义
• 注重支持： 表明您不会在过渡期间丢下客户不管
• 面向未来： 将变更描述为进步，而非损失

便利贴原则

客户读完一遍后，应该能在便利贴上写下自己必须做什么，以及何时完成。如果做不到，这则消息就只是装饰。发送前，务必用这一标准检查每一版草稿。

反面模式（不该这样做）

• 不要写成简短的关停通知：“我们将停止 Product X。再见。”
• 不要以业务为中心： 不要以“这能降低我们的成本”开头
• 不要含糊其辞：“很快”不是时间线
• 不要推卸责任： 不要责怪客户（“使用率低迫使我们关停”）
• 不要一刀切： 每次产品退场都使用同一长度的同一模板，就是比例失当

适用场景

• 停止提供产品、功能或服务
• 将客户从旧平台迁移到新平台
• 逐步停止已收购的产品
• 弃用某个技术栈或 API

不适用场景

• 不会改变客户可执行操作的细微调整（不要过度沟通）
• 尚未制定过渡计划时（明确如何支持客户后再沟通）
• 暗自希望客户不会注意到时（应保持透明）

---

应用

完整的填写结构请使用 template.md。

第 1 步：确定规模和路径

起草前，先确定两件事：

规模： 简短版、标准版或完整版。根据影响范围——客户数量、收入、合同，以及是否涉及硬件或合作伙伴——推荐一种规模，然后允许用户调整。用一句话说明较小规模会省略哪些内容。

路径： 替换、迁移或平稳退出。这决定消息的侧重点，以及“过渡方案”部分应采用定位说明还是退出计划。

第 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]

示例：“我们将于 2026 年 12 月 31 日停用 Fieldlight Classic Dispatch，并将所有账户转至 Fieldlight Next Scheduling。”

妥善退出方案：“我们将于 2027 年 6 月 30 日停用 Fieldlight Route Optimizer。目前没有替代产品，我们希望坦诚说明这一点。”

原因（以客户利益为重点）

**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 步：提供当前产品背景

承认客户将失去什么。对于简版消息，请跳过本节。

**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] |

质量检查：

• 预留充足时间： 标准规模通常为 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. 调整篇幅——为同一条消息生成简版或完整版
3. 按客户细分——为企业账户、中小企业和合作伙伴分别提供版本，因为他们的需求各不相同
4. 检查准备情况——如果仍需论证决策本身，请参阅 eol-readiness-advisor

选择一个编号、组合多个选项，或告诉我你需要什么。”

---

示例

• examples/sample.md — Fieldlight Classic Dispatch（SaaS，标准规模，替代方案路径）
• examples/sample-industrial.md — NFA-200 控制器系列（工业，完整版，替代方案以及渠道和监管义务）

简短摘录：

**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：以业务为中心的原因

表现：“我们将停用 Product X，以削减成本并整合产品组合。”

后果： 客户会觉得自己成了业务决策的牺牲品。

改进方法： 从客户利益出发说明原因：“我们将整合至 Product Y，以便把全部工程资源投入到你们提出的功能需求上。”

---

问题 2：时间安排含糊

表现：“Product X 很快就会停用。”

后果： 客户无法制定计划，焦虑和流失率都会上升。

改进方法： 针对明确的节点给出具体日期：“3 月 1 日：停止接受新购买。12 月 31 日：完全关停，数据导出截止。”

---

问题 3：没有支持计划

表现：“你们需要迁移到 Product Y。祝好运！”

后果： 客户会觉得被抛弃，流失风险很高。

改进方法： 提供切实的帮助：一对一协助、自动迁移工具、过渡价格优惠、培训。

---

陷阱 4：忽视客户影响

症状： 信息从公告直接跳到“新产品来了！”

后果： 客户会觉得他们的担忧没有得到重视。

解决方法： 明确说明此次变更带来的影响，包括客户需要花多长时间处理。

---

陷阱 5：语气过于简短或带有防御性

症状：“由于使用率低，我们将停止提供 Product X。”

后果： 听起来像是在责怪那些确实使用过它的客户。

解决方法： 保持体谅，并着眼未来。使用率低是你的业务背景，不是客户的过错。

---

陷阱 6：所有产品停用都采用同一种方式

症状： 每次停用都套用同一份长篇模板，或者每次都只写一行变更日志。

后果： 微不足道的变更也发长篇通知，会让客户习惯忽略你的信息——这样一来，真正重要的通知也会被忽略。真正停用产品却只写一行变更日志，则会引发支持事件。

解决方法： 有意识地选择简短版、标准版或完整版，并说明原因。采用精简版本时，要清楚自己删掉了哪些部分。

---

参考资料

相关技能

这些技能均可独立使用——它们都不是本技能的前置条件，本技能也不是它们的前置条件。如果你进行了准备度评估并得出了强度等级，只需注明该等级（例如“Level 2”），本技能就会据此调整信息的详略程度。

• eol-readiness-advisor — 如果停用本身仍需论证，可用于判断是否继续以及调整强度
• positioning-statement — 为过渡方案提供依据
• problem-statement — 有助于梳理客户影响部分
• proto-persona — 为不同版本定义受影响的客户群体

外部框架

• 危机沟通最佳实践——透明、共情、行动
• 客户成功手册——产品过渡期间的客户留存

来源

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