AI时代SaaS商业模式重构：从席位收费转向按结果付费

一套 CRM 无法理解每家公司的销售关系，只好把销售过程拆成线索、客户、商机与阶段。过去的算力不够，企业只能删掉需求里的差异、把共同部分做成标准产品，再让用户补上没覆盖的那一段。AI 让系统先拿到这一次任务的上下文，把抽象推迟到服务发生时。

你打开一款软件，通常要先学会它的名词：项目、工单、线索、阶段、权限。现实中的问题却不是这样出现的。客户会说“把这批投诉处理掉”，老板会说“让现金流稳一点”，家人会说“下周去杭州，别太累”。

这不是用户表达能力差，而是过去的“算力”不够：系统没有能力为每个具体需求单独组织人、数据和工具。

过去，企业只能把这些话翻译成固定流程，再把流程做成产品。用户买下产品，学习它的菜单、字段和限制，最后自己补上产品没有覆盖的那一段工作。

把这件事说得更直白一点：产品，是服务在算力不足时的压缩格式。

这里的“算力”不只指 GPU 和芯片，也包括理解需求、组织人和数据、交付结果，以及承担个性化成本的能力。过去，这些能力太贵，企业只能找出需求的共同部分，删掉差异，再把剩下的东西做成标准产品。

产品因此获得规模。代价是，用户得先把自己的问题翻译成产品听得懂的语言。

产品是怎么被压缩出来的

一套 CRM 无法真正理解每家公司的销售关系，只好把销售过程拆成线索、客户、商机、阶段和预计金额。电商平台也不了解每次购物背后的全部动机，于是用类目、搜索、筛选和推荐，把复杂意图压成几个可以点击的入口。

B 端软件看起来更专业，做的事情并没有本质区别。ERP、项目管理和财务软件把企业差异装进标准模块和配置项里。所谓个性化，很多时候只是允许客户在规定好的范围内改几个参数。

C 端也是如此。大众媒体、标准化教育、连锁餐饮和流媒体，都靠统一供给覆盖尽可能多的人。

营销、界面和交互，都是这套压缩机制的配套设施。营销告诉你，你的问题属于哪一类；界面把厂商的抽象翻译成按钮和页面；交互限制了你描述问题的方式。

用户并不是天生愿意按产品的方式思考。只是过去的供给能力不够，他没有太多选择。

AI 把抽象推迟到服务发生时

传统软件先猜大多数人会需要什么，再做统一产品，最后让用户适应它。AI 提供了另一条路径：系统先拿到这一次任务的上下文，理解用户要完成什么，然后在运行时组合代码、数据和工具。

变化不在于旧产品多了一个聊天框，而在于抽象发生的时点变了。过去，企业要在产品上线前决定每个功能怎么工作。以后，系统可以先理解“这一次要完成什么”，再生成流程、调用工具、留下记录。

代码生成越便宜，需求和实现之间的距离就越短。曾经必须封装成固定功能的东西，有些可以直接变成一次服务。

我理解的“代码平权”也在这里：更多具体需求有机会直接变成可运行的服务，而不必先等待某家公司把它做成标准产品。

标准化仍然有用。支付、身份、审计、安全和合规需要稳定的协议与记录。会被削弱的，是那些主要为了节省个性化成本而存在的产品抽象。

C 端：用户调用原子服务

今天，用户承担了很多本该由系统完成的拼接工作。

一次旅行，你要搜索机票、比较酒店、规划路线、挑餐厅、买保险，再把它们拼成能执行的行程。平台提供了大量选项，最后的取舍仍然由你完成。

如果个人 Agent 能替用户行动，输入可能只是一句话：

下周带父母去杭州三天，不要太累，预算一万元，避开人多的地方。

Agent 随后调用航司、酒店、交通、景区、餐厅和保险等能力，围绕这次出行临时组织一套服务。用户需要的不是一份预制套餐，而是一条能执行、出问题也能追责的行程。

这会改变服务商该提供什么。实时价格、库存、服务边界、履约记录、授权接口、取消规则和争议处理，可能比一个漂亮的前台页面更重要。电商、旅游、维修和保险，有一部分会从“平台里的商品”变成“Agent 可以调用的能力”。

平台不会因此消失。支付、信用、库存、物流、仲裁和版权仍然需要有人负责。更可能变化的是前台：平台从消费者每天打开的入口，退到交易和履约的后台。

这条路有两个成立条件。Agent 要由用户付费，并在利益冲突时优先站在用户这边。用户也要能带走自己的数据、记忆和长期关系。否则，平台只是把 App 换成更强的 Agent，广告、返佣和排序仍然照旧。

B 端：在稳定内核上长出服务

B 端不会照搬 C 端的全部原子化。企业仍然需要稳定的数据、身份、权限、账目、审计和合规记录，这些会继续构成业务内核。

更可能被改变的，是要求企业围绕一套标准软件重新安排工作的那部分 SaaS。传统 SaaS 能覆盖共性需求，却很难持续适应一家企业琐碎的真实流程。系统互相割裂，跨部门的事情没人接，配置、维护和培训则变成客户的长期成本。

下一代 B 端服务可以从一个边界清楚的业务缺口开始：先做成一个闭环，再连接相邻的数据和流程，逐步接管执行、分析和运维。它不是部署完就结束的产品，也不是按人头扩张的项目外包，而是在企业业务里逐步长出来的系统。

Palantir 的 AIP Bootcamp 是一个很好的例子。官方把项目目标写成“5 天内从零到用例”，重点是把数据、流程和业务问题做成可以运行的用例。[5]

这类服务如果做得好，单个业务闭环能更快见效，也不必一开始就改造整个组织。使用越久，系统越能积累这家企业自己的流程、异常和责任边界。

这种服务模式的风险也很清楚：它可能变成另外一种形式上的定制外包。如果每多一家客户，就需要多配一支同样规模的实施团队，那本质上仍然是一家项目公司，只是加上了 AI 的概念。能否把人工处理沉淀成规则、评测、策略和自动化组件，决定了服务能不能快速复制和扩张。

收费和竞争的单位会移动

产品退到后台，商业模式也会跟着变。

收费从席位靠近任务

席位收费的前提是默认软件价值和使用人数大致相关。当一个 Agent 如果能承担过去十个人的一部分工作，按账号收费的模式就会因为无法体验价值而显得过时。

更合适的方式是按调用、动作、流程或结果收费。比如：Intercom Fin 已经把部分 AI 客服收费定义为一次成功结果；Salesforce Agentforce 同时提供按用户、对话和动作计费的模式。

当然订阅制不会马上消失。未来更可能是：固定费用覆盖稳定能力，用量费用覆盖可变成本，结果奖励再把双方利益拉近一些。

竞争从功能列表移到工作流

现在流行的AI交互方式，如：生成、总结、识别和问答会越来越像公共能力。真正难的是理解业务上下文，调用正确的系统，完成动作，留下记录，出了异常还能找到负责的人。

因为客户愿意托付的，是一段能跑完的工作流。

护城河从代码转向上下文和责任

代码会变得越来越廉价。真正稀缺的是：对具体业务的连续理解、处理异常的经验、组织信任，以及为结果承担责任的资格。

未来的服务公司未必需要拥有最强的模型，但更有价值的是拥有很深的业务护城河：它们知道客户平时怎么运转，出了问题通常卡在哪里。

收入依赖长期运行

软件时代，厂商卖出产品后，客户自己完成大部分使用和运营。

而服务则需要持续运行、校准并承担责任。例如：Rolls-Royce 的 TotalCare 把民航发动机服务和持续可用性绑定在一起，客户买到的是运行结果，不只是设备本身。

客户最终愿意付费的，可能不是一个账号，而是“这件事一直有人替我做好”。这就是“服务永生”的具体含义：服务不再是产品交付后的附属环节，而是价值交付本身。

产品不会消失，只会变得不显眼

“产品已死”是一句故意夸张的话。没有稳定的模型、数据、工作流和工程系统，个性化服务只能靠人堆出来，也就谈不上规模。

最终的变化是产品的位置。

过去，用户先买软件，再自己完成任务。未来，产品更像藏在服务后面的引擎：理解需求、调用能力、执行流程，必要时把问题交给正确的人。

C 端更接近“个人 Agent 调用一组原子服务”；B 端更接近“稳定业务内核上长出伴生型服务”。两条路都在把一部分主动权移向需求侧，让系统尽量适应用户和业务。

产品也不会真的死。它慢慢会变成一个不再需要单独购买、学习和维护的东西，而是变成服务背后那套不容易被看见的能力。

需求方，不论是C端的人，还是B端的企业，始终需要有人对具体结果负责。这件事还在，服务就永生。

本文由人人都是产品经理作者【十八子杀】，微信公众号：【一只产品狗的思考】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议