AI时代SaaS定价模式变革：从按席位到按结果

AI和SaaS的关系最近几年几乎每隔一段时间就会被重新讨论一轮。有人觉得AI会颠覆SaaS也有人觉得SaaS才是AI落地最好的载体。这两种说法都有各自道理但站在做产品的角度我更关注另一个判断AI时代的SaaS正在经历一轮大洗牌真正危险的并不是模型能力而是定价模式。这个判断最早出现在一场科技大佬访谈里。访谈没有把重点放在“谁的模型更强”上反而反复提到一种现象很多SaaS公司接入大模型之后功能变多了用户活跃度也上去了但毛利反而在下降。问题不出在模型不够好而在于旧的收费逻辑和新的交付成本之间出现了错位。下面把这层错位拆开讲清楚。不管你是SaaS创业者、产品经理、技术负责人还是正在做AI工具落地的开发者只要产品依赖第三方模型或自建模型都应该先想明白一个问题客户付的钱能不能覆盖每次调用模型带来的成本1. 先理清为什么洗牌的关键不是模型1.1 “模型能力”正在变成同质化底座很多人一聊AI SaaS第一反应是“谁的模型强谁就能赢”。这个判断在三年前还有道理现在已经不太成立。基础模型迭代速度非常快开源社区和闭源API之间的差距也在不断缩小。今天你能接入的模型竞争对手明天也能接入。模型能力本身很难构成长期壁垒。这里不是说模型不重要。模型仍然决定产品效果的上限但效果下限和利润空间更多由模型之外的东西决定。同样调用一个模型提示词怎么写、上下文怎么管理、缓存怎么做、结果怎么校验不同团队做出来的成本差异可能差好几倍。真正拉开差距的是模型外围的工程化能力。现在各种集成框架也在降低接入门槛比如Spring AI这类项目把模型调用封装成标准接口团队接大模型越来越像调普通数据库。门槛越低模型能力就越难成为护城河。所以把“模型能力”当作SaaS竞争核心的团队会越来越被动。护城河可能来自积累的数据、稳定的流程、完整的集成能力而不是“我们用了最新模型”这句话。1.2 客户真正买单的是业务流程结果不是模型本身企业客户不会因为“产品用了大模型”就买单。他关心的是客服回复速度有没有变快工单解决率有没有提升合同审查时间有没有缩短销售线索有没有变多模型在中间只是一个部件产品价值来自工作流、权限、审批、数据导入导出、审计日志这些不性感但必须做的部分。这一点在AI编程工具上特别明显。比如团队采购AI编程助手看重的不是背后的模型有多大而是它能否接入现有代码仓库能否理解项目上下文能否在IDE里直接给建议。模型是大是小用户其实感知不强烈大家感知的是每一天能少写多少重复代码。这也是为什么AI没有让SaaS消失反而让SaaS产品更有机会。模型需要有人把它放进业务流程里还需要有人负责稳定性、数据权限和合规。SaaS正好承担了这个角色。1.3 访谈里反复出现的判断赢家输在定价结构那场访谈里有一个判断很值得记下来当模型能力不再是稀缺资源SaaS之间的竞争焦点就会转移到交付效率和定价结构上。如果一个SaaS还按用户数收费但每个用户每天都会触发大量模型调用那用户越多成本越高。这时候如果收费模式没有跟着改变规模增长就会变成利润失血。我认同这个判断。原因很简单模型能力可以通过采购获得但定价模式必须靠团队自己设计。采购行为不会自动产生利润设计一个能覆盖成本的定价机制才是长期经营能力。2. AI时代的旧定价模式问题出在成本从哪来2.1 按席位收费成立的前提是边际成本足够低传统SaaS按席位收费能成立是因为边际成本极低。多一个用户只是数据库里多一条记录服务器压力增加不大。带宽、存储、计算这些成本可以被大量用户平均摊掉。所以CRM、项目管理、文档协作这类工具可以一直使用“每个账号每月多少钱”的模式。但AI SaaS不太一样。同一个账号可能每天发起几十甚至上百次推理请求。大模型每次推理都有算力成本。长文本、多轮对话、文档解析、图片生成这几类场景的token消耗非常夸张。如果还是按席位收费相当于把不确定的推理成本全部打包进一个固定价格里。短期看没问题长期看风险很大。2.2 每一次点击都有成本token、算力、人工兜底举个例子。一个客服工具团队最早按坐席收费每人每月几十元。接入大模型之后客服人员会同时打开好几个会话窗口每个窗口都在调用模型生成回复建议。一个客服一天处理几百条消息每个消息都可能触发两三次模型调用。再加上系统自动润色回复、总结工单、提取客户标签token消耗很快翻了几十倍。月底一算账收入没涨模型账单涨了很多。这个场景不一定出现在每个行业但规律是一样的AI功能只要做得好用户就会高频使用高频使用就会推高成本。成本不只是模型账单还包括人工兜底。模型输出如果不可直接使用仍然需要人工修改修改时间也是成本。很多团队只盯着API账单反而忽略了人工兜底带来的隐性支出。2.3 成本错配出现时会有哪几个信号如果公司出现下面这些情况就需要警惕定价和成本可能已经脱节客户数量很大但毛利和净利都不理想。用户活跃度越高亏损越大。不敢放开免费试用因为试用也会消耗token。销售签单越多月底模型账单越难看。免费版用户反而成了资源消耗大户。新功能上线后效果不错但一上线就开始赔钱。这些信号出现两三个就要尽快处理不要等“模型成本下降”来等问题自己消失。成本下降会来但竞品也会越来越多靠外部成本下降换来的盈利空间非常脆弱。3. 从按席位到按结果几种定价模式怎么选3.1 按用量付费成本透明但账单压力大按用量付费是最直接的模式适合API工具、生成式AI平台、数据标注工具。好处是成本结构透明用户用多少付多少模型账单和收入直接挂钩。坏处是用户对账单的预期不稳定很容易出现“这个月费用暴涨”的投诉。如果要做按量付费必须提前设计配额和预警。比如设置月度费用上限、用量达到80%时自动提醒、超额后自动暂停或者按更高单价计费。计费系统和支付渠道也要提前对接好包括余额扣除、发票、超额账单处理。不要等到出账单才发现问题那会把客户体验做坏。3.2 按结果付费价值对齐但结果定义很难按结果付费听起来最理想客户只需要为“成功的结果”付钱。但落地难度很大因为“什么算成功结果”很难定义。比如“每成功解决一个工单收X元”表面清晰实际要回答很多问题客户关闭工单就算成功还是需要后续满意度确认模型给建议、人工最终确认这个结果算模型的还是算人工的定义结果、度量结果、归因结果是三件难度完全不同的事。如果产品从一开始没有埋点、没有记录调用链、没有人工介入标记那结果定价就只能停留在概念里。想做结果定价的团队至少要先有三个月以上的数据积累。3.3 混合模式基础订阅加用量包加效果溢价在实操中更稳妥的是混合模式。先看一个常见模式对比定价模式优点风险常见适用场景按席位收费客户熟悉收费简单成本与用量脱钩传统SaaS、管理工具按用量收费成本透明收入随用量增长账单不确定客户有价格焦虑API平台、生成式AI工具按结果收费价值感知强收入与客户成功对齐结果定义难归因复杂客服、质检、合同审查混合收费兼顾稳定和弹性产品设计和计费系统更复杂大多数AI SaaS混合模式常见做法是基础订阅保底包含固定额度的模型调用用量包控制超额成本高端场景用结果收费或效果溢价。比如一个AI客服SaaS基础版每月固定费用包含500次AI处理额度专业版每月固定费用包含3000次额度超出部分按次计费企业版则可以根据人工介入率和工单解决率定制效果合约。3.4 判断标准成本可控、客户理解、收入随成功增长选择哪种定价模式不能只看行业习惯要看三个指标交付成本是否可控。无论怎么收费至少不能出现“卖得越多亏得越多”。客户是否容易理解。如果客户听完解释后还需要再问很多问题这个模式可能过于复杂。收入是否随着客户成功自然增长。客户用得越好、结果越明显你的收入也应该越高。如果客户非常成功但你的收入一动不动说明定价没有跟上价值。4. 从客户价值反推定价设计先回答三个问题4.1 先回答客户愿意为哪个结果付费很多SaaS团队做定价喜欢从功能列表出发我们有AI总结、AI搜索、AI生成。但客户不愿意为“有AI功能”付费他愿意为“帮我节省时间、提升转化、降低风险”付费。所以设计定价前先列出你的客户最关心的三个结果指标。拿不同场景举例客服场景工单解决率、平均响应时长、人工介入次数。内容生产场景生成内容可编辑率、发布篇数、内容审核通过率。销售场景线索转化率、跟进次数、话术采纳率。找到一两个可度量、可感知、可付费的指标比堆功能要有效得多。4.2 再回答怎么度量这个结果如果打算做按结果付费或效果溢价前提是能度量。产品从第一天开始就应该记录每个客户调用多少次、成功多少、失败多少、人工兜底多少次。没有这些数据结果定价就只是嘴上说说。我一般会建议团队先在自己的后台里建一个“价值指标仪表盘”。不需要特别复杂先把三件事看明白总调用量、成功结果数、人工介入次数。等这三个数字可以稳定统计再谈定价模型。如果这三个数字不健康比如人工介入率太高那说明模型还没有真正交付结果这时候上线结果定价只会放大亏损。4.3 最后回答如何控制交付成本成本控制是定价设计里最容易被忽略的部分。我觉得有三件事优先级最高。第一模型路由分层。简单问题用便宜的小模型复杂问题才调用大模型。比如常见问题完全可以通过知识库加轻量模型命中只有复杂推理才需要大模型。这样既不影响体验又能明显控制成本。第二缓存与复用。相同或相似请求在短时间内命中缓存不要重复调用模型。这个在客服场景尤其好用。同一个用户反复问近似问题系统直接复用上一次的回答再由人工微调成本会大幅下降。第三任务限流与排队。批量任务不要同时发起按队列分批处理降低瞬时算力峰值。这个在生成式AI场景特别重要。比如一次要生成1000份文档不要开1000个并发而是设置成每批50个、逐批处理。速度慢一些但稳定性和账单价差很多。尤其是AI Agent类功能一次任务可能要调用多次模型成本是单次对话的好几倍更需要提前做路由和配额。4.4 用价值指标反推产品优先级有了价值指标产品排期也会更清晰。一个功能如果指向“减少人工介入次数”那就要重点优化模型输出质量一个功能如果指向“降低首批响应时间”那重点就是路由速度和模型延迟。研发团队不会因为“AI很酷”而开发功能而是因为某个指标需要改善而开发。这也解释了为什么很多团队接入大模型后没有效果。他们先选了一个模型再想能做什么功能而不是先判断客户痛点再选择合适的技术方案。顺序反了结果就会很随机。5. 不同阶段的SaaS团队定价调整路径不一样5.1 早期单点切入先验证毛利早期团队最容易犯的错是功能铺得太开。模型能力很强什么都能做于是做了一堆AI功能最后每个功能都用得少但每个功能都有成本。我更建议用一个高频、痛点强、结果容易度量的场景切入。比如只做“AI工单回复建议”不要一上来就做“AI客服全流程”。早期定价可以简单一点一个入门版一个专业版再配一个用量包。核心目标不是收入最大化而是跑通“客户价值”和“交付成本”之间的平衡。只要毛利是正的后面才有优化空间。如果毛利为负团队就会陷入“越做越多越做越亏”的死循环。5.2 成长期分层套餐和用量预警到了成长期客户类型变多定价也需要分层。免费版可以保留但必须要限制模型调用次数避免被大量低价值用户拿走资源。入门版面向小团队专业版面向业务团队企业版面向大客户可以支持更深的集成、定制或本地部署方案。这个阶段另一个重点是用量预警。当用户用量达到套餐额度的80%主动发邮件或者在后台提醒。一旦超量可以自动暂停AI功能或者按