夜雨聆风在"企业软件最大的竞争对手，是买了不用"里，我提到了使用的三个层次：工具能力、策略框架、组织惯性。Layer 1 是 SaaS 卖的，Layer 2 是 SaaS 假设客户有的。这篇文章专门展开 Layer 3——组织惯性：建起来的东西，能不能活下来。
不是建不起来，是活不下去
Layer 2 的痛点是"策略框架建不起来"——不可见、不可量化、没人排期。这部分之前已经写过。
Layer 3 的痛点不同。很多团队，在实施期间，策略框架是有的。顾问在场的时候，ICP 清清楚楚，培育流程跑得规整，评分规则有理有据。
但顾问一走，这些东西就开始风化。
风化的速度比想象中快。
三个月后，负责 MA 运营的人转了岗。新接手的人打开后台，看到一条评分规则——"官网访问 > 3 次，加 15 分"。不知道为什么是 15 分而不是 10 分或 20 分。不知道这条规则是针对哪个买家旅程阶段设计的。最安全的做法是什么？不动。或者关掉。
半年后，销售团队换了 Lead。新 Lead 有自己的 pipeline 管理习惯，CRM 里的阶段定义被重新解释了一遍。"需求确认"这个阶段，上一任 Lead 定义的是"客户明确表达了采购意向"，新 Lead 觉得"客户愿意听你讲方案"就算。阶段定义漂移了，但没人注意到。
一年后，季度复盘发现 BI dashboard 没人看了。不是工具坏了——是业务变了。半年前重点看获客渠道的转化效率，现在公司战略转向存量运营，但 dashboard 还是按半年前的逻辑跑着。数据在更新，图表在渲染，但没有人在看。
这三个场景的共同特征：不是工具坏了，是人和工具之间的连接断了。
三条断裂路径
组织惯性的断裂，有三条典型路径。它们往往同时发生，互相加剧。
一、人员流动 → 知识断层
策略框架承载在人脑里，不在系统里。
MA 的评分规则文档可能存在某个共享文件夹里，但"为什么行为 A 权重高于行为 B"这个判断依据，只存在于当初设计规则的人脑子里。CRM 的阶段定义可能写在实施手册里，但"为什么这个阶段要求必须有下一次会议时间"这个业务逻辑，只有当初参与讨论的人知道。
负责搭建的人一旦离开，带走的不只是操作方法，是"为什么这样做"的判断依据。接手的人能学会怎么点按钮，按钮在哪、点什么、填什么字段，这些是可传递的。但按钮背后的逻辑，为什么设这个阈值、为什么这条规则优先级高于那条、为什么这个阶段必须有一个决策人，这些是不可传递的，因为它们从来就没有被显式记录过。
于是接手的人面临一个选择：沿用一套自己不理解其逻辑的规则，或者按自己的理解重新来。
大多数人选后者。因为沿用不理解的规则，意味着出了问题你不知道怎么调，也不知道调了之后会不会牵一发动全身。重新来至少自己心里有底。
但重新来的结果，是之前的积累清零。
二、没有反馈回路 → 规则空转
策略框架不是一劳永逸的。市场环境变了，客户画像偏了，竞争格局动了，规则需要跟着变。
但大多数团队没有建立"策略复盘"的节奏。MA 的评分权重是上季度根据历史数据设的，这个季度竞品发了新产品、行业政策有调整，但没人检查权重是否还合理。CRM 的阶段定义是半年前按行业最佳实践配的，销售代表为了完成阶段推进的 KPI，把还在早期的商机挪到后面阶段。阶段数据看起来在推进，但实际是噪音。
没有反馈回路，策略框架就像一张不更新的地图。地图上的路还在，但实际的地形已经变了。
规则空转比没有规则更危险。 因为没有规则，你知道自己没有方向，会谨慎。规则空转的时候，你以为自己在按数据决策，实际上在按过期数据决策，比拍脑袋还糟，因为你有虚假的安全感。
三、"上线"当终点 → 项目思维
企业软件实施有明确的项目周期：kickoff、需求确认、配置开发、UAT、上线。上线那天，项目验收报告签了字，实施顾问撤了，内部邮件发了一封"系统正式上线"的公告。事情做完了。
但上线不是终点，是起点。工具的生命力在上线之后，有人用、有人维护、有人根据业务变化调整。但这些事没有排期、没有预算、没有人负责。因为项目已经结束了。
企业软件实施是项目，持续使用是运营。用项目的资源和节奏去支撑运营的需求，注定断裂。
三条路径的核心是同一件事：组织有建系统的能力，没有养系统的习惯。
三个层次的衰减曲线
把三个层次放在一起看，能看到一条清晰的衰减曲线：
Layer 1（工具能力）：不衰减。SaaS 厂商持续维护，功能还在，性能还在。Layer 2（策略框架）：缓慢衰减。没有持续校准，半年到一年偏离实际。Layer 3（组织惯性）：快速衰减。人员流动、习惯松懈、三到六个月连接断裂。工具能力不衰减，因为 SaaS 的订阅模型保证了它。厂商持续收钱、持续迭代、持续修 bug。工具层面，你今天打开系统和一年前打开系统，能力只增不减。
策略框架缓慢衰减，因为市场和业务在变，但规则不会自动跟着变。半年之内可能还行，超过一年大概率已经偏了。偏了的规则还在执行，这就是 Layer 2 的隐性问题。
组织惯性快速衰减，因为它是三者中最脆弱的，完全依赖人的习惯和流程。人一换、节奏一断、注意力一转移，三到六个月就回到"有人用没人管"的状态。
衰减速度的差异造成了一个反直觉的现象：最先失效的不是工具，是组织习惯。然后策略框架因为没人维护而偏移。最后工具还在好好运转，但已经没有人在用它做真正的决策。
这就是"买了不用"的完整路径：不是突然断电，是缓慢腐化。
续费率在骗人
SaaS 厂商怎么看 Layer 3？
大多数厂商不看。他们看续费率。
但续费率不等于使用率。
一个每年续费但从不登录的 MA 客户，和一个每天在优化培育序列的活跃客户，在续费率统计里是等价的。一个 CRM 里只有通讯录的客户，和一个在做结构化 pipeline 管理的客户，在营收上看不出区别。
前者不是忠诚客户，是还没找到替代品的客户。等到竞品来敲门，或者等到内部终于有人问"我们这个系统到底在不在用"，流失就是一瞬间的事。
续费率是滞后的指标。它告诉你的是"客户上个月还没走"，不是"客户下个月不会走"。
真正该看的指标是活跃使用深度：不仅看登录频次，看的是客户在使用中做了多少策略层面的操作——调整规则、更新定义、修改流程。这些才是 Layer 3 健康的证据。
但很少有厂商追踪这个。因为追踪了也没人负责。CSM 团队扛的是续费率 KPI，不是使用深度 KPI。在续费率的考核体系下，一个沉默续费的客户和一个活跃使用的客户，CSM 投入的资源是一样的：零。
什么能对抗腐化
没有银弹。但有一些模式能延缓衰减：
把"为什么"写进系统。 不是写在文档里——文档会过时、会丢失、会没人看。写进系统里。MA 的评分规则旁边，标注这条规则的业务假设。CRM 的阶段定义里，嵌入"进入这个阶段的判断标准"。让接手的人不需要找前任问，就能理解规则背后的逻辑。这不能阻止衰减，但能降低人员流动带来的知识断层。
设固定的策略复盘节奏。 不是"有空的时候复盘"，是日历上锁定的周期——每季度检查一次评分规则的假设是否还成立，每半年校准一次阶段定义和实际销售进展的偏差。节奏本身就是惯性。不靠人的主动性，靠日历上的重复事件。
追踪衰减信号。 MA 的规则触发频率是不是在下降？CRM 的阶段停留时间是不是在变长？BI 的 dashboard 访问量是不是在衰减？这些是腐化的早期信号，比续费率早得多。但需要有人负责看，有人负责响应。
把运营思维植入实施。 上线不是项目的终点，是运营的起点。实施阶段就应该定义"上线后三个月、六个月、一年的健康检查点"，把资源预算延展到实施之后。不是加一个"一年后回访"的 CSM 电话——那是 Layer 1 的健康检查。是策略层面的体检：规则是否还反映业务现实，流程是否还在被遵守，决策是否还在通过系统做出。
这些模式的核心思路是同一件事：靠系统和日历，不靠人的记性。
不指望人的主动性。主动性是最不可靠的东西。把维护行为嵌入到系统的结构里、嵌入到日历的节奏里、嵌入到指标的追踪里，让它发生的时候不需要人"想起"。
回到三个层次
Layer 1: 工具能力 → 软件能做什么（SaaS 解决的，不衰减）Layer 2: 策略框架 → 应该怎么用（缓慢衰减，需要定期校准）Layer 3: 组织惯性 → 能不能持续用（快速衰减，需要结构性对抗）三个层次的衰减速度不同，对抗手段也不同：
Layer 1 不需要对抗——SaaS 厂商的商业模式保证了它的持续迭代。 Layer 2 需要节奏——固定的策略复盘周期，确保框架和市场同步。 Layer 3 需要结构——把策略知识写进系统、把衰减信号变成可追踪的指标、把运营思维植入实施流程。
企业软件"买了不用"的完整故事，不只是 Layer 2 缺失。Layer 2 缺失是初始条件，框架没建好，用不起来。但即便 Layer 2 建好了，Layer 3 的衰减也会在半年到一年内把一切拉回原点。
腐化是默认状态。持续使用才需要解释。
本文是"企业软件最大的竞争对手，是买了不用"的延伸讨论，聚焦 Layer 3：组织惯性
