EOL Message - 产品退役公告与客户过渡沟通技能

技能概述

EOL Message 是一款帮你撰写产品退役公告的技能:它用清晰、有同理心的方式向客户说明产品或功能何时停止服务、为什么退役、对客户有什么影响、如何完成迁移,并按变更的影响范围自动把消息控制在合适的篇幅——从一段简短通知到跨数月的分阶段沟通。

适用场景

1. 宣布产品或功能退役而不引发支持工单:例如 12 月要下线遗留模块、需要通知 800 个账户,技能帮你把时间表和"客户该做什么"一次讲清楚,避免"我以为还能用"的涌入式咨询。
2. 硬件产品或带服务合同的产线停产:涉及渠道伙伴、合同义务和监管约束时,按 Full 规模生成含完整生命周期门控表(停售、停止维护、服务终止等)的分阶段沟通。
3. 没有替代方案的"优雅退出":产品直接退役、无处可迁移时,技能帮你坦诚说明原因、给出数据导出方式和期限,甚至大方提及竞品替代选项——这比把客户晾在原地代价更小。

核心功能

1. 按变更规模定制消息篇幅(Brief / Standard / Full):弃用一个开关只配一段话,旗舰产品退役才值得九段式公告。技能先根据受影响账户数、收入占比、是否涉及硬件和伙伴推荐一个规模,并说明缩小篇幅会牺牲哪一部分(通常是防止客户追问"到底什么时候停"的阶段时间表)。
2. 三种过渡路径叙事(替换 / 迁移 / 优雅退出):有替代品时侧重连续性定位——什么会保留、什么会变好;同产品线换档时侧重迁移机制——客户要做什么、何时完成、工作量多大;没有下家时侧重体面收尾——诚实理由、数据导出、充足通知期。
3. 生命周期门控时间表 + 便签法则自检:用客户能听懂的语言定义各阶段(如"你还能继续用,但我们不再发布修复"而非只有"EOM 3/2027"),并要求每份草稿通过"读完一遍就能在便签上写下自己该做什么、截止何时"的检验,否则视为不合格。

常见问题

产品退役公告应该提前多久通知客户?

取决于变更规模:普通商业产品(Standard)通常 6–12 个月;收入关键型、硬件或涉及合同的退役(Full)建议 12–24 个月,给客户留出续约、迁移和出口的时间。只用了几周就通知一个承载核心工作流的产品下线,几乎必然演变成信任危机。

没有替代方案时,公告应该怎么写?

用"优雅退出"路径:坦诚承认没有接替产品,说明真实的退役原因(不把低使用率归咎于客户),明确数据导出的格式、获取方式和最后期限,并提供延长访问、导出工具或退款等实际帮助。必要时可以点名竞品作为替代方向——损失一点面子,好过让客户觉得被抛弃。

使用率很低的功能下线,也需要正式公告吗?

视影响范围而定。技能的默认建议是"按变更定尺寸":几乎无人使用的内部工具或配置项,一段话的 Brief 通知发在更新日志即可;但只要它承载着哪怕一小批客户的真实工作流,一份简短却含具体日期和下一步的正式公告就不可省略。所有退役用同一套全文模板,或全用一行日志,是两种最常见的失败方式。