eol-communication

EOL 沟通专家

概述

撰写清晰、体贴的产品生命周期结束（EOL）沟通内容，维护客户信任并促进平稳过渡。让产品退场是一项高风险沟通挑战——处理不当会损害品牌信任，并加速整个产品组合的客户流失；处理得当则能加强客户关系，并推动客户迁移到替代方案。

这项工作分为四个阶段：（1）公告前规划（内容、原因、对象、时间、支持、风险），（2）撰写信息（过渡叙事、客户影响、过渡方案、时间线、一个 CTA），（3）细分并分发（针对不同细分群体采用不同信息和渠道），（4）提供支持并监控（支持 FAQ、迁移跟踪、流失监测）。完整框架、模板和时间线指南，请参阅操作指南。

先行确认

撰写 EOL 沟通内容前，请确认以下信息。如有任何信息未知或含糊不清，请询问——不要自行假设：

• 即将退场的产品及原因 ——这决定过渡叙事和第 1 阶段的规划；含糊的“原因”会让人觉得是在弃客户于不顾
• 替代方案／迁移路径 ——这决定过渡方案和唯一的 CTA；如果迁移路径有问题或不存在，请暂缓公告
• 时间线和关键日期 ——这决定时间线部分，并且会因产品类型（API、付费产品或免费功能）而有显著差异
• 受影响的客户细分群体 ——这决定第 3 阶段的细分群体／渠道矩阵；高价值客户需要与自助服务客户不同的信息和沟通方式

停止规则：只询问最能影响最终内容的 2–3 项信息。如果用户说“直接起草”，就继续撰写，并在文档开头列出你的假设。

适用场景

• 产品退场 ——停止提供整个产品或产品线。
• 功能弃用 ——移除现有产品中的重要功能。
• 服务迁移 ——将客户从一个平台或基础设施迁移到另一个平台或基础设施。
• API 停用 ——弃用 API 版本或端点。
• 定价模式变更 ——对定价进行重大调整，实质上结束旧版套餐。

不适用场景

• 无需通知客户的轻微功能变更。
• 不会影响客户的内部工具变更。
• 错误修复或补丁（请改用发布说明）。

参考资料

• references/playbook.md ——撰写产品退场公告时请阅读：其中包含 EOL 四阶段框架、信息模板和写作规则、细分群体／渠道矩阵、内部支持 FAQ、监控清单、针对不同产品类型的时间线最佳实践、故障排查和成功标准。
• references/red-flags.md ——将信息发送给法务和支持团队审核前请阅读：其中列出了 EOL 信息、时间线或迁移计划中常见的问题，并提供与四阶段框架对应的好坏示例。

范围与限制

**涵盖范围：**EOL 信息撰写、时间线规划、针对不同细分群体的信息撰写、内部 FAQ 准备、迁移监控框架、客户异议处理、支持团队准备。

**不涵盖范围：**替代产品开发、数据迁移工具实施、法律合同审核、退款处理、技术基础设施退役。

**重要注意事项：**EOL 沟通的成效取决于背后的过渡路径。如果替代产品尚未就绪或迁移路径存在问题，即使信息写得再好，也无法避免客户不满。请确保迁移工具经过测试后再发布公告。

集成点

集成	方向	流转内容
create-prd/	互补	替代产品的 PRD 为产品生命周期终止过渡叙事提供信息
release-notes/	提供内容	最终产品更新与产品生命周期终止时间线一同传达
summarize-meeting/	接收内容	产品生命周期终止决策会议记录为沟通内容提供信息
senior-pm/	接收内容	利益相关方地图识别出需要进行个别沟通的高风险客户
daci-framework/	互补	DACI 图表明确由谁推动产品生命周期终止决策和沟通