SaaS功能下架：用着用着就没了

开篇：一句话结论

订阅制的软件，功能不是你买了就永久拥有的——它可能在三种情况下消失：版本合并、产品线调整、接口依赖方变更。前两种是厂商的决定，第三种连厂商都控制不了。

你没法阻止功能下架，但可以做两件事：签约前测出自己的功能依赖度，签约后常年留一份不依赖单一功能的出口。

本文给三类下架情形对照表、下架前的四个信号、依赖度自测三步法，以及被下架后的三个应对动作。

一、热点场景还原：那个用了两年的功能，某天变灰了

一家做连接器和存储的贸易商，十五个人，用某云端系统三年。其中有个功能是他们日常最依赖的：多供应商比价——同一个料号，把四五家供应商的历史报价并排显示，采购直接看哪家最合适。

第三年的某次版本更新后，这个功能变了。先是入口挪了位置，然后是显示字段少了两项，最后在又一次更新后，整个模块提示「已迁移至企业版」。

采购的第一反应是找客服。回复是：该功能已并入企业版套餐，需要升级。

老板算了算升级的费用，又想了想：这个功能是三年前选型时销售重点演示的那一项，当时说「包含在标准版里」。

最后他们做了两件事：一是把比价这件事退回 Excel 手工做，每周花两小时；二是开始每年导出一次全量数据。

这个场景里最值得记的不是「厂商不讲信用」——套餐调整是商业常态。值得记的是：这家公司把一项关键业务能力，完全托管在了一个由别人决定存亡的功能上，而且没有备份方案。

元器件ERP这一层的完整口径，放在元器件ERP的专题入口里。

二、核心方法：三类下架，四步自测

1. 三类下架情形对照表

三类里，第三类最麻烦，因为它不由软件厂商决定。你的系统依赖某个外部平台的数据接口，那个平台改了或者关了，软件厂商也只能跟着改——改不了就是功能消失。这类事情在元器件贸易里很常见：行情数据源、物流查询接口、电商平台的开放接口，都属于这一类。

2. 下架前的四个信号

信号一，功能入口被挪动。 先是入口变了，然后是字段少了，最后才是整体下架。入口挪动是最早的信号。

信号二，更新日志里出现「整合」「迁移」「升级至」这类词。 这些词通常意味着套餐结构调整。

信号三，客服对该功能的答复变模糊。 明确答复变成「建议您关注后续版本」，就是信号。

信号四，该功能不再出现在新版本的演示材料里。 营销材料是最诚实的产品路线图：不再被展示的功能，通常是要被处理的。

四个信号里，第四个最可靠。做法很简单：每年看一次厂商最新的功能介绍页，和你现在在用的功能清单对照，看少了什么。

3. 依赖度自测三步法

第一步，列出你真正依赖的功能，不超过五个。 不是「用了什么」，是「没了会停摆什么」。对多数贸易商，这五个通常是：查历史报价、库存锁库、出入库记录、应收应付、多供应商比价。

第二步，给每个功能问一句：没了它，我怎么干活。 能回答「退回 Excel，每周两小时」的，是可承受依赖；回答「没法干」的，是不可承受依赖。不可承受依赖超过两个，你的功能风险就偏高。

第三步，问厂商三个问题。 这个功能在你的套餐里是永久包含吗？有没有计划调整？如果调整，提前多久通知、有没有过渡方案？三个问题要书面答复。

4. 被下架后的三个应对动作

动作一，先算替代成本，不要急着升级。 升级费 vs 退回手工的年成本 vs 换系统的成本，三个数摆一起比。有时候退回手工反而更划算，尤其是对使用频率不高的功能。

动作二，要求过渡期。 功能上移通常有过渡安排。主动问，通常能拿到几个月的时间窗。

动作三，把这次事件记进选型档案。 记三件事：功能名、下架时间、你的应对成本。这份档案在下次选型时是最好的谈判依据。

三个动作的共同点是：不要被动接受。功能下架是厂商的决定，但怎么应对是你的决定。

本地部署能规避掉这类风险里的哪一部分，配套那篇讲部署门槛的文章给了对照，文末有继续读的入口。

三、落到经营：把功能依赖变成可管理的风险

三条做法。

第一条，做一个功能依赖清单，每年更新一次。五行为限，写清楚：功能名、没了怎么办、厂商答复、应对成本。这张表的价值在第二次用到的时候——它让你在谈判时有据可依。

第二条，关键业务能力永远留一条不依赖单一功能的路。多供应商比价可以在系统里做，也留一份导出的价格台账；库存锁库可以在系统里做，也留一份库位图。这不是不信任系统，是任何关键能力都该有冗余。

第三条，把「功能永久包含」写进合同。至少争取「本套餐包含的功能在合同期内不减少」。争取不到，就把它折算成风险成本，在比价时计入。

落到两类形态上，差别在功能归属：

订阅制下，功能的使用权随套餐状态变化。你付的是一段时间内的使用权，功能清单由厂商维护。

买断制下，你拿到的是这个版本的软件本身。太帅ERP 属于这一类：一次付费永久使用，15+ 功能模块，Windows 桌面应用、本地部署、内置数据库。你买的这一版不会因为下一年的套餐调整而减少功能——版本是你自己的，不存在「下架」这件事。

当然，要诚实说清边界：买断不等于永远有新版。升级政策要不要包含后续版本、大版本更新是否单独收费，这些要在购买时问清楚。买断制规避的是「已买到的功能被拿走」，不是「永远免费升级」——这两件事不能混为一谈。升级政策怎么问才不吃亏，这篇拆过：买断制软件升级政策：怎么问才不吃亏。

四、常见误区

• 功能演示过就等于永久有。错在把演示当承诺。正确的是：要求书面确认「本套餐永久包含」。
• 功能下架只能认。错在放弃谈判。正确的是：算替代成本、要求过渡期、记进选型档案。
• 只盯着厂商，不看接口依赖方。错在漏掉第三类下架。正确的是：把外部接口依赖也列进清单。
• 关键能力不留冗余。错在单点的依赖。正确的是：五个关键功能各留一条系统外的路。

FAQ

厂商说「功能会增加不会减少」，能信吗？

口头的不算。争取写进合同：「本套餐包含的功能在合同期内不减少」。写不进去，就把它当风险成本计入比价。

功能上移到企业版，升级划算还是退回手工划算？

算三个数：升级的年费、退回手工的年工时成本、换系统的成本。使用频率低的功能，退回手工往往更划算。

外部接口依赖怎么查？

问厂商：这个功能依赖哪些第三方接口？有没有接口变更的应对方案？答不上来的，说明风险没人管。

买断制是不是就永远不会少功能？

已买到的版本不会。但要注意升级政策：后续大版本是否包含、要不要单独付费，这些要在购买时问清楚。买断规避的是「拿走已有功能」，不是「永远免费升级」。

怎么提前知道功能要下架？

看四个信号，最可靠的是第四个：每年对照一次厂商最新的功能介绍页，看少了什么。另外争取在合同里写明变更通知期。

写在最后

订阅制下，功能是使用权不是所有权。三类下架情形里，最麻烦的是接口依赖方变更——连厂商都控制不了。

五功能依赖清单、三步自测、三个应对动作，加上「关键能力永远留一条系统外的路」。这四件事做完，功能下架就从一次事故降级成一次调整。

完整口径写在了配套的《本地部署ERP需要什么样的电脑》里——那一篇讲的是买断制这一侧的部署前提和它的实际门槛。

主 CTA：完整口径写在了配套的《本地部署ERP需要什么样的电脑》里 次 CTA：继续读：电子元器件贸易公司的7大管理痛点（你家中了几条） → 电子元器件贸易公司的7大管理痛点（你家中了几条）