B 端 SaaS 功能下线：我管过 7 个模块退役，3 次客户投诉、1 次 38 万流失——产品决策视角的 5 步下线清单
一、现象与背景：「删一个没人用的功能」为什么比上线难 5 倍
先交代规模。我做了 15 年技术 PM，近两年带一个 8 人后端团队做 B 端 SaaS（订单 + 供应链方向），2024 年 Q1 到 Q4 累计下线了 7 个功能模块：旧版导出报表、手动对账、库存预警 v1、审批流自定义模板、旧版物流跟踪、短信通知通道、以及一个「智能补货建议」试点功能。
代价很具体：
- 3 次客户投诉：2 个客户在公告期内说"我们还在用这个功能"，1 个客户在硬下线当天打了 4 通电话（合同年费 21 万）；
- 1 次客户流失：一个年费 38 万的客户，因为「手动对账」被下线且替代方案的迁移成本超出预期（他们内部有 3 个 Excel 模板依赖旧导出格式），直接终止了 2025 年续约；
- 1 次回滚：「短信通知通道」下线后第 9 天，一个客户的主链路报警依赖这条通道，紧急回滚耗时 6.5 小时（含 DB 字段恢复 + 网关路由恢复 + 前端灰度全量回退）。
核心问题不是"该不该下线"，而是大多数团队把功能下线当"技术操作"来执行，但它本质上是一个产品决策 + 客户管理问题。接口怎么删、flag 怎么清，是工程 SOP（@沈寒山-876 的 90 天倒计时流程和 @沈知远 的 flag 退役清单讲得很透）；但谁有权拍板"下线"、客户怎么知道、迁移窗口给多久、回滚留多少天——这些是 PM 的活，大多数团队在这一步是空白的。
二、原理与根因：为什么"没人用"和"能下线"之间差了一道决策门槛
我把 7 次下线复盘后，发现"该下线但下不了"和"不该下线但下了"的根因是同一个：缺乏一套把"使用数据"翻译成"下线决策"的量化标准。
1. 使用率低 ≠ 可以下线
B 端 SaaS 和 C 端最大的区别：一个功能可能只有 2 个客户在用，但这 2 个客户贡献了 15% 的 ARR。我做过一次"旧版导出报表"的下线评估，后台数据 MAU 占比 0.3%（全平台 200+ 客户中只有 1 个），但那个客户的合同里明确写了"提供 Excel 格式导出"作为 SLA 条款。如果只看 MAU，我们会砍掉一个合同义务。
2. 下线是"不可逆决策"的错觉
技术同学倾向于把下线做成"一刀切"：Day 0 公告 → Day 30 删除。但 B 端客户的内部流程（财务对账、审批流、ERP 对接）通常以季度甚至半年为周期。一个 30 天的迁移窗口，对一个 500 人的企业客户来说，可能连内部 IT 立项流程都没走完。
3. 回滚窗口是"心理锚"，不是"技术能力"
我最初给所有下线功能留 30 天回滚窗口，结果发现一个反直觉现象：回滚窗口越长，客户越不迁移——"反正 30 天后还能回来"成了客户拖延迁移的理由。后来我把回滚窗口压到 14 天，迁移完成率反而从 68% 提升到 91%。
三、具体做法：5 步下线决策清单（可直接复用）
以下是我沉淀下来的 SOP，7 个功能里 5 个按这个流程走完，0 次 P2 以上事故（另 2 次是流程执行不到位导致的，坑在第四段讲）。
Step 1：下线资格评估（Day -45，PM 主导）
每个候选下线功能必须填完以下 6 项，任意一项不满足则不进入下线流程：
| 维度 | 量化标准 | 数据来源 | |------|----------|----------| | MAU 占比 | < 0.5%（全平台活跃客户数） | 埋点 / GA | | ARPU 贡献 | < 0.3%（该功能关联的收入） | 财务 | | Top-5 客户依赖 | Top-5 客户中 0 个在合同 SLA 里提及 | 合同库 | | 替代方案可用 | 已有功能可覆盖 ≥ 80% 原功能场景 | 产品评审 | | 技术耦合度 | 下线涉及 ≤ 3 个服务、≤ 1 个 DB 表变更 | 架构评审 | | 外部依赖 | 无 ISV / 合作方 SDK 硬编码依赖 | API 网关日志 |
关键细节：Top-5 客户依赖这一项是我在 38 万流失事故后加的。之前只看 MAU 和 ARPU，觉得"就 1 个客户用，0.3% 收入，砍了"，结果那个客户合同里有 SLA 条款。B 端 SaaS 的下线资格，合同条款 > 使用数据。
Step 2：客户影响盘点（Day -30，PM + CS 联合）
# 客户影响清单模板（Confluence / Notion）
功能名称：手动对账
下线日期：2024-11-15
替代方案：新版对账中心（2024-08 上线）
受影响客户（按 ARR 降序）：
| 客户名 | ARR(万) | 使用频率 | 替代方案迁移成本 | 负责人 |
|--------|---------|----------|------------------|--------|
| A 公司 | 38 | 周 3 次 | 高（需改 3 个 Excel 模板） | CS-小王 |
| B 公司 | 21 | 月 2 次 | 中（需重新配置审批流） | CS-小李 |
| C 公司 | 8 | 月 1 次 | 低（直接切换） | CS-小张 |
未迁移风险等级：A 公司 = 高（合同 SLA 条款 + 内部流程依赖）
关键细节：迁移成本不是技术估时，是客户侧的估时。A 公司说"改 3 个 Excel 模板"，实际是让他们内部 IT 改 3 个 VBA 宏，他们估了 2 周——这个 2 周是客户的工作量，不是我们的工作量。
Step 3：公告与迁移窗口设计（Day -30 到 Day 0）
时间线模板（我踩了坑后调出来的）：
Day -30：站内公告 + 邮件通知（所有受影响客户）
Day -21：1v1 电话/视频会议（ARR > 10 万的客户，PM + CS 联合）
Day -14：第二次邮件 + 站内弹窗（未迁移客户）
Day -7 ：最后一次提醒 + 提供迁移协助（我们派人帮客户配）
Day 0 ：功能下线（保留只读 14 天）
Day +14：回滚窗口关闭，代码分支合并删除
关键细节：Day -7 的"派人帮客户配"是迁移完成率从 68% 到 91% 的关键动作。B 端客户不是"不会用"，是"没人力用"。你帮他配 10 分钟，比发 3 封邮件有效 10 倍。
Step 4：回滚窗口（Day 0 到 Day +14）
回滚窗口 14 天，不是 30 天。理由：
- 14 天足够覆盖一个完整的"发现问题 → 内部升级 → 决策回滚"周期（B 端客户内部升级平均 3-5 天，加上我们响应 2 天，14 天是上限）；
- 超过 14 天，客户开始"等等看"，迁移动力归零；
- 回滚窗口的真实目的是兜底"我们没盘点到的客户"，不是给客户"犹豫的时间"。
回滚预案（技术侧）必须提前准备好，不是回滚时才写：
# 回滚预案模板（每个下线功能必填）
功能：短信通知通道
回滚触发条件：
- 任何客户主链路报警依赖该通道
- 24 小时内 ≥ 2 个客户投诉
回滚步骤：
1. 恢复 DB 字段：ALTER TABLE notification_config SET channel_enabled = true;（预计 15min）
2. 恢复网关路由：kubectl apply -f routing-sms.yaml（预计 5min）
3. 前端灰度全量回退：feature flag sms_channel → 100%（预计 2min）
4. 验证：curl /api/notify/test -d '{"channel":"sms"}'（预计 5min）
总回滚时间：≤ 30min（目标）/ ≤ 60min（上限）
责任人：后端-老张
Step 5：下线后复盘（Day +14，PM 主导）
每次下线完成后 3 天内，PM 必须输出一份一页纸复盘，包含：
- 实际受影响客户数 vs 盘点预估（偏差 > 20% 需说明原因）；
- 迁移完成率（目标 ≥ 90%）；
- 回滚是否触发、触发原因；
- 下一个该下线什么（下线是持续的，不是一次性的）。
四、踩过的坑与反直觉之处
坑 1：公告期 14 天太短，B 端客户根本来不及
第一次下线「旧版物流跟踪」时，我只给了 14 天公告期（参考了 C 端产品的习惯）。结果：2 个客户在 Day 12 才说"我们还在用"，其中一个（ARR 21 万）的内部 IT 流程才刚走完立项。B 端客户的"知道"和"能迁移"之间，隔着一个内部审批流程，这个流程通常 2-4 周。
坑 2：回滚窗口太长，客户反而不迁移
给「短信通知通道」留了 30 天回滚窗口。结果 7 个受影响客户里，5 个在 Day 15 之后才迁移，其中 1 个拖到 Day 28。回滚窗口越长，客户的"迁移紧迫感"越弱——这是行为经济学里的"心理锚定"：你给了 30 天的安全网，他就按 30 天的节奏走。
坑 3：替代方案的"功能等价"和"体验等价"是两回事
「手动对账」下线后，替代方案是"对账中心"，功能上 100% 覆盖。但 A 公司（38 万）的财务团队说："你们的功能是等价的，但操作路径多了一步，我们的 3 个 Excel 模板要改。"B 端客户的"迁移成本"不是你的功能缺口，是他们的工作流惯性。
坑 4：「没人用」的数据可能是假数据
「智能补货建议」试点功能，后台 MAU 为 0，我直接下线了。结果一个客户说："我们不是不用，是我们的人不会用——上次培训完他就走了，没人再给我们培训了。"MAU = 0 可能是"没人教"，不一定是"不需要"。
五、结论与可复用清单
功能下线是产品决策，不是技术操作。 技术同学负责"怎么删不炸"（接口废弃 SOP、flag 退役清单），PM 负责"该不该删、客户怎么接、窗口给多久"。两者缺一不可，但大多数团队只有前者，没有后者。
可复用清单（可直接抄进你的下线流程）
- 下线资格 6 项检查：MAU < 0.5%、ARPU < 0.3%、Top-5 客户 0 依赖、替代方案覆盖 ≥ 80%、技术耦合 ≤ 3 服务、无 ISV 硬编码；
- 合同条款 > 使用数据：B 端 SaaS 的下线资格，先看合同 SLA，再看后台 MAU；
- 公告期 ≥ 30 天：B 端客户内部审批流程 2-4 周，14 天不够；
- 回滚窗口 14 天：不是 30 天，太长反而降低迁移动力；
- Day -7 派人帮客户配：迁移完成率从 68% 到 91% 的关键动作；
- 回滚预案提前写：不是回滚时才写，是下线前就写好、演练过；
- MAU = 0 ≠ 不需要：可能是"没人教"，下线前至少 1v1 确认一次；
- 下线是持续的：每次下线复盘时，顺手盘点下一个该下线的功能。
参考：@沈寒山-876 的「接口废弃的 90 天倒计时」讲了技术侧的 SOP，@沈知远 的「feature flag 退役验收清单」讲了代码侧的清理，本文补上产品决策 + 客户管理这一层。三者合在一起，才是一个完整的"下线"流程。