产品退市计划是一份跨部门执行文件，用来说明退市对象与范围、时间表、客户与合同处置、库存与供应收尾、替代迁移路径、沟通口径和退出判定标准。制定时先划定退市范围与分类，再倒排关键节点，明确各角色交付物，最后用检查清单逐项确认关闭条件。本文按这一顺序展开，适用于软件、硬件及软硬件组合产品的商业退市管理。
要点总览（TL;DR）
- 退市计划先划定范围与分类：完全退市、停止新售、仅维护三类对应不同的时间表松紧和客户沟通口径。
- 时间表从系统下线日或停止服务日倒排，依次确定决策批准、客户公告、停止新售、停止服务、系统下线与数据归档节点。
- 角色分工落到“谁在什么时点交付什么”，客户商务沟通归销售、迁移执行归客户成功，以客户处置清单作为交接凭证。
- 关闭判定用检查清单逐项核验：客户迁移、合同义务、库存与供应、财务结算、系统下线、数据归档、沟通收尾，任一项未通过即暂缓关闭。
退市计划要写清哪些内容：核心框架与操作步骤
退市计划的核心是把“停止投入”转化为一组可执行、可验收的动作。计划文档至少应包含七块内容：退市对象与范围、退市分类、时间表、客户与合同处置、库存与供应收尾、替代迁移路径、沟通与关闭标准。缺少任何一块，执行中都容易出现客户不知情、合同义务未履行或库存积压的情况。
第一步：划定退市范围与产品分类
输入是产品清单、在售状态、客户合同分布和营收占比。动作是逐项确认退市对象，并按退出程度分为三类：完全退市（停止新售、停止服务、系统下线）、停止新售（存量客户继续服务至约定期限）、仅维护（不再增加新功能，保留缺陷修复与安全更新）。输出是一张带分类标记的产品退市清单，完成标志是每个产品都有明确分类、责任人和适用范围说明。分类决定了后续时间表的松紧，也决定了客户沟通的口径。
第二步：倒排关键节点时间表
退市时间表通常从“系统下线日”或“停止服务日”向前倒排，关键节点包括：内部决策批准、客户公告、停止新售、停止新功能交付、停止服务与支持、系统下线与数据归档。每个节点写明日期、触发条件和负责人。倒排的好处是让公告期、客户迁移期和合同履约期有足够缓冲。完成标志是所有节点日期确定，且相邻节点之间的间隔能覆盖客户迁移和合同通知义务。
第三步：客户与合同处置
输入是客户名单、合同条款、服务等级约定和续费周期。动作包括：识别受影响的客户分层，核对合同中关于终止、通知期和退款责任的条款，制定迁移方案或补偿方案，安排通知节奏。输出是客户处置清单和通知模板，完成标志是每个受影响客户都有处置方式、通知记录和确认回执。
第四步：库存与供应收尾
对硬件或含实体交付的产品，需要盘点成品、在途库存和备件，确定消化方式（继续销售、折价清理、拆解复用或报废），并同步通知供应与生产环节停止排产。软件产品则对应许可证、第三方组件和云资源的收尾。输出是库存处置表与供应停止排产确认，完成标志是库存数量、处置方式和责任人明确，供应侧已确认不再新增投入。
第五步：替代迁移路径
退市计划应说明客户迁移到哪里：替代产品、升级版本或第三方方案。内容包括迁移的技术路径、数据迁移方式、迁移支持资源和时间窗口。输出是迁移方案文档，完成标志是迁移步骤可被客户成功或技术支持直接执行，且关键客户已完成迁移演练或确认迁移计划。
第六步：沟通口径与关闭标准
统一对内对外口径，包括公告措辞、销售话术、客服应答和内部FAQ，避免不同渠道信息不一致。同时预先写明关闭标准：客户迁移完成率、合同义务履行情况、库存清零、系统下线与数据归档完成。输出是沟通包和关闭判定表，完成标志是口径经法务与市场确认，关闭标准可逐项核验。
| 步骤 | 主要输入 | 关键动作 | 输出与完成标志 |
|---|---|---|---|
| 范围与分类 | 产品清单、合同分布、营收占比 | 确认退市对象，划分完全退市/停止新售/仅维护 | 退市清单，每项有分类与责任人 |
| 倒排时间表 | 下线日、合同通知期 | 倒排决策、公告、停售、停服、下线节点 | 节点表，日期与负责人齐全 |
| 客户与合同 | 客户名单、合同条款 | 分层、核对义务、制定迁移或补偿方案 | 客户处置清单与通知记录 |
| 库存与供应 | 库存台账、排产计划 | 盘点、确定消化方式、停止排产 | 库存处置表与供应确认 |
| 替代迁移 | 替代产品能力、客户环境 | 设计迁移路径与支持资源 | 可执行的迁移方案 |
| 沟通与关闭 | 法务意见、关闭标准 | 统一口径、设定判定条件 | 沟通包与关闭判定表 |
这些步骤产生的任务、时间节点和交付物往往分散在多个部门。ONES 的产品全生命周期管理方案覆盖业务需求输入、产品规划需求管控到研发交付的协作闭环，退市阶段的任务分派、节点跟踪和文档沉淀可以借助其项目管理与知识库模块承载；退市专项流程是否需要单独配置，建议在选型时结合自身流程核验。
谁来做、交付什么：角色分工与责任边界
退市失败常见的原因不是计划缺失，而是责任悬空：客户以为销售会通知，销售以为客服会跟进，合同条款没人核对。角色分工要落到“谁在什么时点交付什么”，并明确交接关系。
| 角色 | 核心职责 | 关键交付物 | 交接时点 |
|---|---|---|---|
| 产品负责人 | 发起退市评估，统筹计划，主持关闭评审 | 退市立项说明、计划主文档、关闭评审结论 | 决策批准前提交评估；关闭前提交评审材料 |
| 市场 | 制定对外公告与传播口径 | 公告稿、渠道更新清单、内部FAQ | 公告日前完成法务确认 |
| 销售 | 停止新售执行，客户商务沟通 | 停售确认、客户商务处置记录 | 停售日向产品负责人确认 |
| 客户成功 | 客户分层、迁移跟进与回执收集 | 客户迁移台账、确认回执 | 迁移窗口结束前提交完成率 |
| 研发 | 停止新功能、缺陷修复范围界定、系统下线与数据归档 | 下线方案、归档记录、下线确认单 | 下线完成后提交技术确认 |
| 供应链 | 库存盘点、停止排产、备件处置 | 库存处置表、供应停止确认 | 停售节点同步提交 |
| 法务 | 合同义务审查、公告合规、争议处理 | 合同义务清单、合规意见 | 公告前与关闭前各一次 |
| 财务 | 收入确认影响、退款与结算、资产核销 | 财务结算表、核销记录 | 关闭评审前提交 |
决策与升级机制需要单独写明。通常由产品负责人发起退市提案，由产品委员会或管理层批准；涉及重大合同或合规风险时升级至法务与财务负责人。关闭判定建议由产品负责人组织，法务、财务、客户成功和研发共同确认，任何一方提出阻断项则暂缓关闭。责任边界上，客户商务沟通归销售，迁移执行归客户成功，两者之间以客户处置清单为交接凭证，避免通知与迁移脱节。
示例：一款在售产品退市的计划片段
以下为演示情景，用于说明计划如何落到具体条目，不代表真实企业案例。
假设某软件产品A计划完全退市，替代产品为A的升级版本B。退市范围包括A的全部付费版本与配套插件，存量客户约若干家，其中部分合同含提前终止通知条款。
- 时间节点：3月完成内部决策批准；4月1日发布客户公告；5月1日停止新售；9月30日停止服务与支持；12月31日完成系统下线与数据归档。
- 客户通知与迁移：公告后两周内由客户成功完成客户分层，重点客户一对一沟通；6月至9月为迁移窗口，提供数据迁移工具与迁移支持；迁移完成后收集客户确认回执。
- 库存与合同收尾：软件许可与云资源在停售节点停止新增；法务在公告前核对含特殊条款的合同，逐份确认通知期与退款责任；财务在关闭评审前完成未确认收入与退款的结算。
- 关闭条目：迁移完成率达到预设标准、合同义务全部履行、系统下线并完成数据归档、财务结算完毕，四项同时满足方可关闭。
这个片段可迁移的规律是：时间表从下线日倒排、客户处置与合同核对并行、关闭条件前置写明。适用边界在于，硬件产品还需增加库存消化与备件周期，受监管行业还需预留更长的公告期和合规审查时间，不能直接套用上述日期安排。
完成检查：退市关闭前要逐项确认什么
关闭检查的作用是把“感觉差不多了”变成可核验的结论。建议在计划启动时就确定清单，关闭评审时逐项打勾，任何一项未通过即视为阻断项。
| 检查项 | 通过标准 | 核验材料 |
|---|---|---|
| 客户迁移 | 受影响客户均已通知并完成迁移或确认不接受迁移的处置方案 | 客户迁移台账、确认回执 |
| 合同义务 | 通知期、退款、服务承诺等条款均已履行，无未决争议 | 合同义务清单、法务确认 |
| 库存与供应 | 库存清零或完成处置，供应侧确认停止排产 | 库存处置表、供应确认 |
| 财务结算 | 收入确认、退款、资产核销完成 | 财务结算表 |
| 系统下线 | 服务已停止，访问入口关闭，相关依赖已解除 | 下线确认单 |
| 数据归档 | 客户数据按约定保留或移交，归档记录可查 | 归档记录 |
| 沟通收尾 | 对外公告、渠道信息、内部文档已更新为退市状态 | 渠道更新清单 |
阻断项通常集中在三类：客户迁移未达标准、合同争议未解决、数据归档不合规。出现阻断项时，关闭评审应记录原因、责任人和新的完成时点，而不是直接关闭。关闭条件建议在计划批准时由产品负责人、法务和财务共同签字确认，关闭时按同一份条件复核，确保判定口径前后一致。
常见问题
退市计划应该在什么时候启动，才能避免客户和合同出问题？
启动时点取决于合同通知期和客户迁移所需时间，通常从计划的下线日向前倒推。先确认受影响合同中约定的提前通知期限，再为公告、客户分层沟通、迁移窗口和合同履约预留缓冲。含特殊条款或受监管的行业，公告期和合规审查时间需要单独评估。计划启动得越晚，可用的迁移窗口越短，客户处置容易变成被动通知。
“停止新售”和“完全退市”在执行上有什么差别？
停止新售指不再向新客户销售，存量客户继续按合同获得服务至约定期限；完全退市则在停售基础上进一步停止服务与支持，并完成系统下线与数据归档。两者的时间表长度、客户沟通口径和关闭检查项不同：停止新售的关闭重点在停售执行与存量服务安排，完全退市还需核验服务停止、系统下线和数据归档。分类在计划启动时就要写清，避免执行中口径反复。
客户不接受迁移方案时，退市计划怎么处理？
计划中应预先写明不接受迁移的处置路径，例如按合同约定继续服务至期限届满、协商补偿或提前终止。这类客户需要法务参与确认合同义务，客户成功记录沟通与确认结果，并在关闭检查中作为单独条目核验。若合同争议未解决，应作为阻断项暂缓关闭，记录原因、责任人和新的完成时点，而不是在争议未决时直接关闭产品。
退市期间的任务和交付物分散在多个部门，如何保持进度可见？
常见做法是把退市作为独立专项，将各节点拆成带负责人和截止日期的工作项，客户处置清单、库存处置表、合同义务清单等交付物集中存放并关联到对应工作项。ONES 的产品全生命周期管理方案覆盖业务需求输入、产品规划需求管控到研发交付的协作闭环，其项目管理与知识库模块可承载退市阶段的任务分派、节点跟踪和文档沉淀；退市专项流程是否需要单独配置，建议在选型时结合自身流程核验。
硬件产品退市和软件产品退市，检查清单要增加什么？
硬件产品需要在库存与供应环节增加成品、在途库存和备件的盘点与消化安排，并确认供应侧停止排产；部分产品还涉及售后备件保留周期和维修支持期限。软件产品对应的是许可证、第三方组件和云资源的收尾。两者在客户迁移、合同义务、财务结算和沟通收尾上的检查逻辑一致，差异主要在库存处置和供应收尾的具体条目。
