SaaS已死?AI产品经理必须懂的“服务即软件”新模型

0 评论 742 浏览 0 收藏 20 分钟

SaaS模式正在被AI颠覆,客户不再为工具买单,而是为结果付费。从按席位收费到按价值定价,从功能堆砌到业务结果导向,产品经理面临全新的商业模式抉择。本文深度剖析五种AI时代的产品策略,揭示定价权转移背后的商业逻辑,帮助你在服务即软件的新赛道找到破局点。

1. 卖软件的时代正在终结,但很多人没反应过来

去年下半年,我负责的一款SaaS工具续费率开始往下掉——不是功能不够、也不是价格太贵,客户给的理由出奇一致:’你们按年按席位收钱,可隔壁那家按我们省了多少人力抽成,我们不用操心怎么用,月底看账单就行了。当时心里挺不是滋味的,但没细想。直到前几天我翻到一条旧新闻,纳德拉去年11月说“SaaS概念将会瓦解,业务逻辑要迁移到AI层”,突然就对上号了——不是我的产品不行,是我还在卖工具,客户早就想要结果了。

纳德拉这句话我琢磨了很久。他说的“瓦解”不是软件消失,而是软件从’前台界面’退到’幕后基础设施’,用户看到的是AI直接吐出来的答案,背后跑的却是一整套软件能力网络。Foundation Capital给这个新模型起了个名字,叫SAS(Service-as-a-Software),核心就一句话:不卖刀,卖切好的菜。

传统SaaS卖的是工具使用权——你买会计软件,还得雇人学、找人用;SAS直接卖税务结果,客户不用关心用的是QuickBooks还是什么,只要税报对了、钱省下来了就行。这听起来不过是个定价逻辑的调整,但对产品经理来说,整个价值主张都得翻过来:你不再需要把精力花在功能列表上,而是花在理解客户到底想要什么样的业务结果上。

我身边大部分产品经理还在一味堆功能、比价格,觉得把对话界面做得更丝滑、多接几个API就是护城河。

可Klarna的例子已经把这张纸捅破了——他们CEO去年3月就说,公司停用了约1200个SaaS系统,包括Salesforce,全用内部统一AI平台搞定。1200个系统,功能列表得有多厚?但AI一旦能整合这些东西,功能本身就是废纸。

真正让Klarna做决策的,不是哪个软件功能多,而是AI能直接产出’这笔审批能不能过”这个客户风险多高’的结果。当结果成为交付物,客户连操作界面长什么样都不在乎了。这不是什么遥远的预言,这是我续费率下滑那天就已经开始的现实。

2. 五种新商业模式,产品经理得知道怎么选

功能堆到天花板又怎样?Klarna的例子告诉我们,客户要的不是软件,是结果。

卖刀和卖切好的菜,是两码事。

第一种路数其实已经有人跑通了:按结果收费。你做的AI客服,别再按席位收年费了,改成按“解决的笑脸数”抽成——客户省了多少人工,你从中分一杯羹。听起来简单,但背后要啃的硬骨头可不少:你得有一整套可信的计量体系,能证明那个笑脸真的是你的AI搞定的,不是客户自己误操作。而且客户业务波动大的时候,你很可能这个月赚爆、下个月喝西北风。所以产品经理必须算清楚一个账:客户愿意为每个成果付多少钱,你的推理成本能否覆盖住,利润空间在哪个量级才不会崩。

另一种模式看着稳当,但其实更考验精细运营:按算力收费,像水电表一样透明。你把模型调用量做成计价单位,客户用多少付多少。好处是客户觉得公平,不会被锁死在没用的席位上。坏处是——推理成本曲线如果不下压,客单价稍微冲高一点你就亏本。

我见过一个团队,做文档摘要,客户日均调用量暴涨三倍,结果他们的API成本翻了两番,月底一算倒贴钱。所以产品经理得提前想好:你有定价权吗?你的模型成本能通过优化降到什么位置?如果客户一天调用一万次,你赚的钱够不够付给算力平台?这些不是算法工程师该操的心,是产品经理必须在产品设计阶段就画好的算盘。

再说两种更“重”的模式,但利润空间也更大。垂直整合这条路,说白了就是不再卖软件,直接下场当服务商。比如AI律所,客户来不是买一个文档审查工具,而是直接拿到一份签好字的合规报告。溢价能力惊人,但风险也高——你变成了重资产运营,要雇专家兜底、要承担交付失败的责任,而且没法像卖软件那样轻松扩张到所有行业。

我认识一个做AI税务的朋友,他们团队不到三十人,一年做了两千多万营收,但绝大部分时间都在处理客户的复杂个案,每一个都是定制。对他来说,护城河根本不是代码,是那十几个资深会计师用行业经验和AI磨合出来的工作流。

平台模式刚好相反,它赌的是客户对“省心”的付费意愿。你不用自己做所有事,但你要设计一套集成生态,让客户觉得用你一个入口就能管完所有工具。

Funnel的Fredrik Skantze最近说过一句话我特别认同:基础设施总是赢家。平台模式就是做基础设施——客户不为你的某个功能付钱,而是为“不必切换五个软件”的便利买单。代价是你必须投入巨大精力去打通各种第三方API、处理兼容性问题,而且客户黏性一旦建立,替换成本很高,他才愿意长期续费。这两种模式没有绝对优劣,产品经理得掂量自己团队的基因:你们擅长深度服务,还是擅长做平台连接?想清楚再跳。

最后一种是前置工程师模式,Palantir的看家本领。说白了,就是派你的人到客户现场,带着软件、带着问题定义能力,跟客户一起把活儿干了。

表面上看这是最“重”的——售前团队要跟算法工程师一起出差,成本高,周期长,很难规模化。但在复杂的B2B场景里,这可能是唯一的解法。金融合规、医疗数据治理、制造业排产——这些行业的问题从根上就不一样,你不可能靠一个标准化的SaaS产品让客户自助搞定。

产品经理在这条模式里的角色变了:你不是在设计一个通用的交互界面,你是在设计一套可以被你的现场团队灵活调用的Agent工作流,让每个客户现场的工程师都能用半个小时的对话把客户的业务逻辑转化成AI能执行的步骤。

我见过一个做供应链优化的团队,他们的产品形态就是一个配置好的Agent,前置工程师花两周跟客户梳理完业务逻辑后,剩下的工作全是Agent自己调度数据、生成报告。客户到最后根本不在乎你用的是什么模型、什么界面,他只在乎结果准不准、出报告快不快。

所以,五种模式本质上是在问产品经理同一个问题:你愿意把赚钱的支点放在什么能力上?是放在计算成果的精确计量上,还是放在行业知识的深度沉淀上,还是放在现场服务的信任关系上?没有标准答案,但选错了,你的产品就永远只能是功能列表里的一个名字,而不是客户业务流程里离不开的一环。

3. 定价权转移:从“按席位”到“按价值”,我踩过的坑

上一节聊到前置工程师模式,那种“人到现场+软件包”的方式,听起来反规模,但客户愿意付高价。为什么?因为价值可感知。可我们团队刚做AI产品时,压根没想明白这道理。头两个月,直接把上一款SaaS工具的按席位定价搬了过来——一个坐席每月299,按年签。结果第一个大客户签完合同,电话就追过来了:“我买100个席位,但你的AI能帮我省掉50个人力。我一个客服月薪6000,你一年收我35万,我实际省了36万——可你按人头收,等于我每省一个人就得给你多交一份钱,这不合理吧?”我当场噎住。挂了电话一算,确实离谱。客户不是不愿意付钱,而是觉得定价跟价值反着走:你的AI越能干,我付得越多?逻辑上就站不住。

那之后我们花了三个月大改定价方案。最初的想法很粗暴:按API调用次数收,每万次5块。但方案一推,技术团队先炸了——调用量跟客户满意度根本不是线性关系。有些对话长、推理复杂,单次调用成本高;有些简单问答一次搞定。客户也不傻:你按调用量,那我是不是该让AI少干活?这又回到了激励错位的老问题。最后我们做了折中:基础费用按API调用量阶梯收,覆盖推理成本;浮动部分挂钩结果指标——我们做的是AI客服,关键指标是“客户满意度提升率”和“一次性解决率”。每月跟客户对账,按这两项的改善百分比抽成。老实说,前两个月收入波动很大,第一月因为客户还在磨合,满意度只涨了5%,抽成部分几乎为零,团队账面上亏了不少。但第三个月开始,客户主动跑来要求我们优化模型、加新意图——因为每提高一个点满意度,他们省的钱远多于抽成。到第六个月,该客户的续约率从原来按席位时的70%直接跳到92%。而且因为我们的收入跟客户结果绑定,他们几乎不再压价,反而希望我们多投入。

这段经历让我彻底相信了Eric Flaningam的那句话:定价模型本身就是产品设计的一部分。

以前我理解的定价,是商务谈判桌上的事——定个价、给个折扣、签合同走人。但后来发现,定价决定了你的产品怎么被使用、被优化,甚至决定了客户跟你是博弈关系还是伙伴关系。按席位,客户巴不得你功能少、没人用;按结果,客户恨不得你越强越好。

这中间的财务模型,产品经理必须懂。不光是算成本,还得想清楚:你的定价在传递什么信号?客户会不会因为定价而改变行为?一个错误的定价模型,可能让整个产品方向跑偏——本来应该做深度的上下文理解,结果为了降低调用成本,团队开始拼命压缩对话轮数,质量反而下去了。

那会儿我才理解,为什么顶级VC看AI项目时,花在分析定价模型上的时间比看产品demo还多。定价不是收尾环节,它直接定义了你的产品逻辑和客户关系。下一个问题接踵而来:当Agent成为主要采购者,你的产品该去服务谁?

4. 供应链重构:当Agent成为主要采购者,你的产品要服务谁?

上一节聊到定价模型本身就是产品设计的一部分,可定价不只是定价格。它背后藏着一个更难回答的问题:你的产品到底在服务谁?是坐在屏幕前的人类用户,还是那些看不见的自动化脚本和Agent?我以前觉得这问题有点形而上学——谁会笨到分不清用户是人是机器?但数据不会骗人。

今年早些时候,我翻后台调用日志,发现一个扎心的事实:我们API的调用量里,差不多三成来自客户的自动化脚本或AI Agent,而不是真人点鼠标。这些调用没有UI、没有页面加载时间、没有“用户体验”可言——它们只关心一件事:你给我什么数据,你回什么错误码,你的接口崩不崩。一旦token超时或者错误码含义模糊,脚本直接报错重试,流量瞬间打满,然后限流,然后再重试……一个死循环。

我那时才真正理解a16z说的那句话:当Agent成为企业软件主要用户时,整个软件行业得重新设计。

这意味着什么?意味着产品经理的战场从UI界面转移到了API文档、错误码可读性和限流策略上。我亲眼见过一个客户因为我们的错误码没写清楚“具体是哪个参数格式不对”,他们的Agent循环调了八个小时,烧了上千元token费,然后投诉说我们产品“不稳定”。其实原因就是接口返回的401信息写成了“Authorization failed”——Agent能理解吗?它只知道非200就重试。产品经理如果还在纠结按钮圆角还是直角,Agent已经在拿脚投票了。好的产品现在得把API文档写成给Agent看的文档:每个字段是否可空、限流策略的header格式、重试建议间隔、幂等性设计……这些以前是后端工程师的事,现在成了AI产品经理的核心决策点。我甚至让团队在API响应里加了一个X-Recommended-Retry-After字段——一个小小的改动,客户Agent调用失败率降了40%。

供应链的另一端是Token预算管理。客户开始像管财务预算一样管Agent的推理成本。我司今年上线了一个功能,叫“成本优化建议”——每次调用后,系统会自动分析是不是用了过大的模型、是不是返回了不必要的上下文、是不是可以缓存重复查询。客户一开始觉得这功能鸡肋:你们做API的,凭什么教我省钱?但试了三个月,续费转化率反而上来了。因为客户自己算过账:每个Agent调用省0.1美分,一天十万次就是一百美元。省下来的钱够再买两倍调用量。这不就是差异化吗?当你的竞品还在拼接口速度时,你帮客户控制预算,他们就会把你当成伙伴而不是供应商。Agent供应链的每个环节——从API契约到成本审计——都是产品经理要操盘的新基础设施。下一节我会聊聊,当这些基础设施变得人人可搭建时,你到底该造基础设施还是造产品。

5. 回到产品经理的决策:你在造基础设施还是在造产品?

上一节聊到成本优化建议,靠帮客户省钱反而把续费率做上去了。

这事儿让我想了很久。

不久前黄仁勋说,软件行业即将开启百倍于传统服务业的规模——听上去很燃,但我给自己泼了盆冷水:不是所有AI产品都要做成平台,也不是所有赛道都该横向铺开。我见过太多团队,融了钱就急着搭基础设施,结果客户一句“你这东西跟我现有的CRM有什么区别”就卡住了。反而那些垂直扎进去、只做一件事但做到极致的,活得最稳。

所以我给团队定了一个决策框架,不是什么高大上的模型,就三个问题,简单但刺人:

第一,我们的数据是否足够独特?是公开抓来的行业语料,还是我们自己沉淀的私有知识?

第二,我们能否深度嵌入客户的工作流,让他们替换掉我们的时候得伤筋动骨?

第三,收费模式是不是跟客户的成功直接挂钩——客户省钱我们抽成,客户赚钱我们也赚钱?这三个问题都答“是”,才开干。答不出来,哪怕代码写得再漂亮,我也宁可先憋着。

做产品5年,AI方向2年,我最大的认知升级就是这个:别再纠结代码和功能了,去纠结“客户到底要为哪个结果付钱”——这个问题的答案,才是真正的护城河。

当所有人都会用AI做软件时,软件本身不再是武器——但对问题的深刻理解、对上下文的精准把控、对结果的交付能力,以及用AI持续放大这些优势的速度,才是谁也抄不走的差异。卖软件的时代确实在退场,但服务即软件的时代,才刚刚开始。

本文由 @CyberMona 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!