停用产品/功能/套餐时：按影响范围撰写得体的 EOL 公告…

当你要退役某个产品、功能或套餐，需要给受影响客户发出一份规模相称、兼顾共情与清晰行动指引的停用通知时使用。

适用场景

解决思路

1. 先定消息规模：按“爆炸半径”（受影响客户数、收入、合同、是否涉及硬件或渠道伙伴）在 Brief / Standard / Full 中推荐一档并一句话说明理由，允许用户覆盖；若用户选得更小，明确指出会丢掉哪一段（通常是阶段表，而它正是防止“到底什么时候不能用”工单的关键）。规模参照：Brief 用于功能、内部工具、无人使用的选项，1-3 段、提前数周、走站内信或 changelog，只用公告/时间线/CTA 三段；Standard 用于商用产品、活跃客户，1 页加阶段表、提前 6-12 个月、邮件+站内+文档，9 段轻量写全；Full 用于收入关键、硬件、受监管产品，分多期跨月发送、提前 12-24 个月、走邮件+客户团队+伙伴+媒体，9 段全写并加合规与义务。
2. 先定过渡路径：Replacement（自家另一产品接手，强调连续性：什么被保留、什么变更好，重点在定位）、Migration（同产品族换档位/配置/平台，强调机制：客户必须做什么、何时完成、工作量多大，诚实说明投入，低估工作量是最快失去信任的方式）、Graceful exit（没有替代品，强调体面：诚实理由、数据导出、充裕提前量、真实替代方案，包括竞争对手——点名竞争对手的代价小于让客户无路可走的声誉损失）。
3. 收集上下文：被停用的具体是什么；落地去处是什么（若有）；适用哪些生命周期 gate 及各自日期；客户影响（多少用户、哪些工作流被打断）；支持计划（迁移协助、培训、折扣、数据导出工具）；为什么要这么做；约束条件（合同措辞、监管要求、曾经做过的“终身”承诺）。若缺上下文：没有过渡计划就不要发——客户一定会问“我现在该怎么办”，起草可以，发送不行。
4. 写“公司背景”段：说明我们是谁、与被淘汰产品的关系、对客户的承诺、产品线如何演进、我们要走向哪里。
5. 写“公告”段：用一句话清楚说明 EOL，并点名落地去处（例：“我们将在 2026 年 12 月 31 日退役 Fieldlight Classic Dispatch，并把所有账户迁移到 Fieldlight Next Scheduling”）。
6. 写“理由”段，且必须以客户收益为中心：先列 2-3 条原因（Because），再写“Which means for you”，从客户视角说明影响与好处，而不是公司成本或组合整合。
7. 写“当前产品背景”段：承认正在失去的东西——它是什么、服务了哪类客户多久、通过什么关键收益；Brief 消息跳过此段。
8. 写“客户影响”段，诚实承认干扰：逐条列出对运营/流程的影响，并量化工作量（例如“重建周期派工规则，多数账户 2-3 小时”）、需要重新培训的角色、需要改动的集成。这是全篇最不能偷工减料的地方。
9. 写“过渡方案”段：Replacement / Migration 路径用定位声明格式——For [受影响客户] that currently use [旧产品]，[替代品] is a [品类] that [强调连续性与改进的收益]；再加“差异与延续”小节：Like [旧产品]，[替代品] provides [被保留的部分] while also offering [新增的部分]。
10. 写 graceful exit 变体替代上述内容：数据去向（导出格式、如何获取、保留多久）、我们建议的替代方案（含竞争对手，并说明适配度）、我们提供的帮助（延长访问、导出工具、迁移抵扣、应退的退款）。
11. 写“支持措施”与时间线表格：列出 3 条左右具体支持动作（一对一协助、自动迁移工具、过渡定价、培训），并用表格列出 Gate / Date / 对你意味着什么（通俗语言后果）。质量检查：提前量是否充足（Standard 通常 6-12 个月，合同与硬件更长）、gate 是否用客户语言（“停止收到修复”而非“EOM”）、数据导出截止日期是否明确写出。
12. 写清晰的 CTA：给出具体的第一步动作及链接或路径，以及获取帮助的真实联系方式。
13. 正确使用生命周期 gate 词汇：GA、NSC、EOS、EOE、EOR、EOM、EOL、EOSRV。Brief 消息点名 2-3 个，Full 消息用表格列全 8 个；无论用哪些，都要用客户能懂的话定义它们。
14. 用“便利贴规则”自检：客户读一遍后，应该能在便利贴上写下自己必须做什么、何时之前完成；写不出来，这封消息就只是装饰品。
15. 交付草稿后给出编号后续选项：1) 压力测试——以怀疑的客户视角读回并标出不清楚处；2) 改规模——产出同一消息的 Brief 或 Full 版本；3) 分群改写——为企业客户、SMB、伙伴分别出变体；4) 若停用决策本身还需辩护，去看 eol-readiness-advisor。
16. 避开反模式：不要写成冷冰冰的关停通知；不要以业务为中心开头（如“这能降低成本”）；不要含糊（“很快”不是时间线）；不要防御或归咎客户（“使用率低所以我们关了”）；不要对所有停用都用同一套模板同一长度。
17. 明确表态语气与内容边界：整篇是客户中心的沟通——先承认损失，再把变化框定为进步；有共情、清晰、支持导向、面向未来。
18. 修复常见坑（业务中心理由）：症状是用降本/整合组合当理由，后果是客户觉得自己是业务决策的附带损害；改法是把理由框成客户收益，例如“我们整合到 Product Y，好把全部工程投入你们要求的功能”。
19. 修复常见坑（时间线含糊）：症状是“产品 X 很快会停用”，后果是客户无法规划、焦虑与流失上升；改法是把具体日期对应到具名 gate，例如“3 月 1 日：不再接受新购买；12 月 31 日：完全关停，数据导出截止”。
20. 修复常见坑（没有支持计划）：症状是“你需要迁移到产品 Y，祝好运”；改法是真帮忙——一对一协助、自动迁移工具、过渡定价、培训。
21. 修复常见坑（忽略客户影响）：症状是消息从公告直接跳到“这是新产品！”；改法是把干扰明确点名，包括客户要花多长时间完成。
22. 修复常见坑（语气简短或防御）：症状是“由于使用率低，我们将关闭产品 X”，听起来像在怪罪仍在用的客户；改法是共情且前瞻，低使用率是你的业务背景，不是他们的错。
23. 修复常见坑（一刀切）：症状是每次退役都用同样全长的模板，或每次都只发一行 changelog；后果是琐碎变更的长通知训练客户忽略你，真正重要的那封也被忽略，而真实退役只发一行则变成支持事故；改法是有意识地选 Brief / Standard / Full 并说明原因，缩小规模时知道砍掉的是哪一段。

适用边界 · 注意事项

• 不适用于不改变客户能做什么的微小调整——不要过度沟通。
• 不要在没有过渡计划之前发送——要先把如何支持客户想清楚，再对外沟通。
• 如果你私下希望客户不会注意到，就不要用这个方法——要透明。