产品退出规划要把停售、停服、客户迁移和内部收尾组织成一条可执行流程。先界定退出对象与深度，再评估客户和合同影响，排出通知、停售、停续、停服的时间表，最后用证据确认闭环。下文给出范围表、六段流程、角色分工和一个填写示例，并说明如何衔接ONES做任务分派与文档归档。
要点总览（TL;DR）
- 先界定退出对象（整产品、版本、区域、渠道）与退出深度（仅停售、停售并停服、停售停服并迁移），范围表经审批后冻结，作为通知与时间表的统一口径。
- 退出流程按六段推进：决策与立项、影响评估、方案与时间表、客户沟通与迁移、执行与收尾、完成验收；每段写明输入、动作、输出与完成标志，避免只排时间不排交付物。
- 时间表的关键节点是停售通知、停止新购、停止续费、停止服务；通知期取决于合同约定、客户规模与迁移难度，需与法务确认后确定。
- 用RACI明确产品负责人、销售、客户成功、法务、财务、IT/运维的职责，立项时一并确定审批人与验收人，三个签字节点写进立项决议。
- 退出是否结束以证据为准：通知送达、迁移确认、合同处理、财务结清、系统与权限下线、文档归档逐项核对，遗留事项登记责任人和关闭时间。
退出规划先定范围：退什么、退到哪一步
退出规划的第一份产物是范围界定表。范围不清，后续的客户通知、合同处理和时间表都会失去依据：整产品退出与单个版本退出，涉及的客户数量、迁移工作量和审批层级差别很大。范围表要同时回答两个问题——退出的对象是什么，退到哪一步为止。
退出对象通常分四类。整产品退出指某款产品整体停止销售与服务；版本退出指停止某个版本的新购与支持，产品其他版本继续运营；区域退出指在特定国家或地区停止销售与服务；渠道退出指关闭某条销售或交付渠道，产品本身可能继续通过其他渠道提供。四类对象可以叠加，例如“某版本在某个区域通过某渠道停售”，范围表应分行记录，避免混在一行里说不清。
退出深度决定工作量的量级，一般分三档：仅停售，即停止新购但继续为存量客户提供服务；停售并停服，即在约定日期后不再提供任何服务；停售停服并迁移，即在停服前把存量客户迁移到替代产品或完成数据导出。深度越深，客户沟通、迁移支持和验收证据的要求越高。选择哪一档，取决于是否有可替代产品、合同是否允许、客户迁移难度以及数据留存义务。
范围表建议包含以下字段，每个退出对象一行：
| 字段 | 填写要求 |
|---|---|
| 退出对象名称 | 产品、版本、区域或渠道的准确名称与标识 |
| 对象层级 | 整产品 / 版本 / 区域 / 渠道，可叠加时分行记录 |
| 退出深度 | 仅停售 / 停售并停服 / 停售停服并迁移 |
| 生效日期 | 各节点的目标日期，至少含停售日与停服日 |
| 影响客户范围 | 存量客户数量、在用版本、是否有特殊合同 |
| 替代方案 | 迁移目标产品或数据导出方式，无替代时注明 |
| 责任人 | 对该对象退出结果负责的产品负责人 |
范围表经审批后冻结，后续方案与时间表都以它为准。范围发生变更时走变更记录，不在原表上直接改数，保证通知客户的口径与内部执行一致。
核心步骤：从决策到停服的六段流程
退出流程按六段推进：决策与立项、影响评估、退出方案与时间表、客户沟通与迁移、执行与收尾、完成验收。每段都要写明输入、动作、输出和完成标志，只排时间不排交付物，流程就会停在纸面。
第一段：决策与立项
输入是业务数据（销量、续费、维护成本、替代产品就绪度）和初步的范围设想。动作是形成退出建议，说明退出理由、拟采用的退出深度和大致时间窗口，提交给有权批准的人。输出是立项决议，明确批准人、项目负责人和范围表初稿。完成标志是决议签字并存档，负责人和审批人已书面确认。
第二段：影响评估
输入是范围表和客户、合同、财务、系统依赖数据。评估至少覆盖四类：客户与在用版本，合同与售后义务，收入与续费影响，上下游依赖系统与集成方。动作是逐项盘点并形成影响清单，标出高风险客户和需要法务介入的合同条款。输出是影响评估清单。完成标志是清单覆盖范围内全部客户与合同，高风险项已指定处理人。
第三段：退出方案与时间表
输入是影响评估清单。动作是确定关键节点：停售通知、停止新购、停止续费、停止服务，并为每个节点写明日期、责任人和前置条件。通知期长短取决于合同约定、客户规模和迁移难度，需与法务确认后确定，不宜套用统一天数。输出是退出方案和分阶段时间表。完成标志是方案经审批人批准，时间表各节点均有责任人和交付物。
第四段：客户沟通与迁移安排
输入是已批准的时间表和客户清单。动作是按客户分层发送通知，说明停售与停服日期、替代方案、迁移支持方式和数据导出安排；对重点客户安排一对一沟通。输出是通知记录、迁移计划与数据导出排期。完成标志是通知送达记录齐全，迁移客户已确认迁移方式与时间。
第五段：执行与收尾
输入是时间表与迁移排期。动作是按节点执行停售、停续、停服，同步处理合同终止或变更、退款与收入确认、库存与物料清理、内部系统下线。输出是各节点的执行记录和收尾凭证。完成标志是每个节点都有执行证据，合同与财务事项处理完毕。
第六段：完成验收
输入是前五段的全部交付物。动作是验收人对照完成检查清单逐项核对，登记遗留风险与例外。输出是验收结论和遗留事项台账。完成标志是验收人签字确认，遗留事项均有责任人和关闭时间。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 决策与立项 | 业务数据、范围设想 | 形成退出建议并报批 | 立项决议、范围表初稿 | 决议签字存档 |
| 影响评估 | 范围表、客户与合同数据 | 盘点客户、合同、收入、依赖 | 影响评估清单 | 清单覆盖全部对象，高风险项有处理人 |
| 方案与时间表 | 影响评估清单 | 确定节点、责任人与前置条件 | 退出方案、时间表 | 方案获批，节点均有责任人 |
| 客户沟通与迁移 | 时间表、客户清单 | 分层通知、安排迁移与导出 | 通知记录、迁移排期 | 送达记录齐全，迁移方式确认 |
| 执行与收尾 | 时间表、迁移排期 | 停售、停续、停服，处理合同财务库存 | 执行记录、收尾凭证 | 各节点有执行证据 |
| 完成验收 | 全部交付物 | 对照清单核对，登记遗留事项 | 验收结论、遗留台账 | 验收人签字 |
角色与交付物：谁签字、谁执行、谁验收
退出涉及多个部门，责任不清就会出现“通知发了但没人跟进迁移”“系统下线了但合同还没终止”这类断点。建议用RACI表达分工：R为执行人，A为最终负责并签字的人，C为需征询意见的人，I为需被告知的人。审批人与验收人应在立项时一并明确，避免到停服前才找人签字。
| 角色 | 主要职责 | 关键交付物 | RACI要点 |
|---|---|---|---|
| 产品负责人 | 对退出方案整体负责，协调各团队 | 范围表、退出方案、时间表 | 方案A，多数执行动作R |
| 销售 | 客户沟通、合同变更与续约处理 | 客户通知记录、合同变更文件 | 客户沟通R，合同条款C法务 |
| 客户成功/支持 | 迁移支持、数据导出、售后问题处理 | 迁移计划、导出交付记录 | 迁移执行R |
| 法务 | 审核合同义务、通知文本与法律风险 | 合同审核意见、通知文本定稿 | 合同与通知C，必要时A |
| 财务 | 退款、收入确认、应收结清 | 结清凭证、收入确认记录 | 财务事项R |
| IT/运维 | 系统下线、权限回收、数据留存 | 下线记录、权限回收清单 | 下线执行R |
| 支持团队 | 停服前后的工单处理与口径统一 | 工单处理记录、常见问题口径 | 执行R，口径I |
关键决策点通常有三个：立项批准、退出方案与时间表批准、完成验收。三个节点分别由谁签字，应在立项决议中写死。验收人建议由不直接执行退出的管理者担任，保证核对时能独立判断证据是否充分。各角色的交付物清单随方案一同发布，每项交付物标注提交时间和接收人。
退出计划跨部门、周期长，任务分派和状态跟踪容易散落在邮件和表格里。ONES可以把各阶段任务按角色分派、跟踪节点状态，并把通知记录、合同文件和验收记录归档到同一处，便于验收时按清单调取证据；具体功能范围以实际部署与配置为准。
示例：一个版本退出计划的完整填写
以下为演示情景，用于展示表格如何填写，不代表任何真实客户案例。
示例背景：某软件产品计划停止V2.3版本的新购与支持，引导存量客户迁移到V3.0。退出深度为“停售停服并迁移”，涉及存量客户约120家，其中8家合同含提前通知条款。批准人为产品线负责人，验收人为运营负责人。
范围表填写：
| 退出对象名称 | 层级 | 退出深度 | 生效日期 | 影响客户范围 | 替代方案 | 责任人 |
|---|---|---|---|---|---|---|
| 产品A V2.3 | 版本 | 停售停服并迁移 | 停售2025-06-30，停服2025-12-31 | 存量客户约120家，8家有提前通知条款 | 迁移至V3.0，提供数据导出 | 产品负责人张某 |
时间表填写：停售通知2025-03-31发出；停止新购2025-06-30；停止续费2025-09-30；停止服务2025-12-31。每个节点写明责任人和前置条件，例如停止续费的前置条件是存量合同已完成变更或到期确认。
客户通知与迁移安排：按客户规模分三层通知，8家特殊合同客户由销售与法务逐一确认通知期；迁移支持由客户成功团队排期，数据导出在停服前完成并取得客户确认。通知记录和导出交付记录统一归档。
收尾与验收记录：停服后核对合同终止或变更文件、退款与收入确认凭证、系统下线与权限回收记录、文档归档位置。验收人对照检查清单逐项签字，遗留的2家未完成迁移客户登记责任人和关闭时间，纳入遗留台账跟踪。
完成检查：退出是否真正结束
退出是否结束，以证据为准，不以“通知已发、系统已关”的口头判断为准。验收人对照下列清单逐项核对，每项都要能指向具体记录；缺证据的项不勾选，转为遗留事项。
| 检查项 | 通过标准 | 证据形式 |
|---|---|---|
| 客户通知 | 范围内客户均已收到通知，特殊合同客户通知期符合约定 | 送达记录、通知文本定稿 |
| 客户迁移 | 需迁移客户已完成迁移或已确认数据导出 | 迁移完成确认、导出交付记录 |
| 合同处理 | 合同已终止、变更或到期确认 | 合同文件、法务审核意见 |
| 财务结清 | 退款处理完毕，收入确认与应收结清 | 结清凭证、财务记录 |
| 库存与物料 | 相关库存、物料与许可已清理或核销 | 清理记录 |
| 系统与权限下线 | 系统已下线，账号与权限已回收，数据按约定留存 | 下线记录、权限回收清单 |
| 文档与知识归档 | 退出方案、通知、验收记录归档到指定位置 | 归档目录与索引 |
| 遗留风险与例外 | 每项遗留事项有责任人和关闭时间 | 遗留事项台账 |
全部检查项通过后，由验收人签署验收结论，退出项目正式关闭。存在遗留事项时，验收结论标注“有条件通过”，遗留台账转入日常跟踪，关闭时间到期前复核一次。退出结束后，把范围表、时间表、通知记录和验收结论一并归档，作为后续同类退出的参照。
常见问题
退出深度选“仅停售”还是“停售停服并迁移”，主要看哪些条件？
判断依据集中在四点：是否有可替代产品或数据导出方式、合同是否允许停止服务、存量客户的迁移难度、数据留存义务的要求。有成熟替代产品且客户迁移意愿较高时，可以选停售停服并迁移；合同对服务期有明确约定、或客户短期内无法迁移时，先做仅停售更稳妥。深度一旦确定，客户沟通口径、迁移资源投入和验收证据要求都会随之变化，因此应在范围表审批时一并定下，后续调整走变更记录。
通知期应该定多长，能否直接套用行业常见天数？
通知期需要结合合同约定、客户规模和迁移难度逐项确认，与法务核对后再写入时间表。合同含提前通知条款的客户，通知期以条款为准；客户数量多、迁移涉及数据导出的，需要预留更长的沟通与执行窗口。把统一天数直接套到所有客户，容易出现部分客户通知期不足、部分客户等待过久两种情况。建议在时间表中对特殊合同客户单独标注通知起始日，并在发出前由法务复核通知文本。
退出过程中客户提出继续续费或延后停服，应该怎么处理？
这类请求属于范围与时间表的变更，不宜由销售单独口头答应。处理路径是：记录客户诉求与合同依据，提交产品负责人评估对整体时间表和迁移资源的影响，涉及合同义务的由法务出具意见，再由原审批人决定是否调整。同意延后的，更新范围表与时间表并保留变更记录，同步通知客户成功、财务和IT/运维，避免系统已下线而合同仍在服务期的情况。不同意的，按原通知口径书面回复并留档。
验收人由谁担任更合适，验收时发现证据不全怎么办？
验收人建议由不直接执行本次退出的管理者担任，便于独立判断证据是否充分，具体人选在立项决议中确定。验收时对照完成检查清单逐项核对，每项都要能指向具体记录；证据不全的项不勾选，转为遗留事项登记责任人和关闭时间，验收结论标注“有条件通过”。遗留台账转入日常跟踪，关闭时间到期前复核一次，全部关闭后再更新验收结论。
退出结束后，哪些材料需要归档，后续同类退出怎么复用？
归档范围包括范围表、退出方案与时间表、客户通知文本与送达记录、迁移与数据导出确认、合同终止或变更文件、财务结清凭证、系统下线与权限回收记录、验收结论和遗留事项台账。归档到指定位置并建立索引，便于审计和后续查询。同类产品再次启动退出时，可直接参照上次的范围表字段、时间表节点设置和检查清单，减少重复设计；上次出现的遗留问题和客户异议也应作为本次影响评估的输入。
