|
|
作为一家成立10年+的SaaS企业，我们过去的一年多以来，一直在推进插件化和AI应用的“战略”。
同时，作为一家以追求利润为核心的商业机构，商业化是“必经之路”，而增值产品收费是其最基础的方式之一。
最近，我们被如何定价困住了：
- 插件是否属于标准化SaaS产品的一部分？是否要收费？
- 如果插件是某家客户付费定制研发，是否要收费？如收费，是按原价，还是边际成本价？
- 如果是AI Agent，应该按每个模块一个Agent进行收费，还是按每个独立的Agent收费？
- 等等。
所以，今天就聊聊产品的定价，尤其是SaaS产品。
三种常见定价方式：按需、按成本、按价值
第一种：按需定价：指根据客户实际使用量（如调用次数、存储容量、计算资源、人员规模等）动态收费，灵活适配用户需求。它的优势是价格透明、使用门槛低，而劣势就是使用越多，成本越高。
比如SaaS产品有A、B、C、D、E五大模块，则根据模块+人员规模进行定价(如下图）。
第二种：按成本定价：指根据产品或服务的生产成本（开发、运维、人力等）加固定利润率定价。
用公式表达为：单位价格=(固定成本/预期销量+单位变动成本)×(1+利润率)。
比如研发一套SaaS产品，预估每年研发/销售/营销成本是2000万，每年服务成本是800万，而每家客户的变动服务器等成本是1000元，预期利润率是30%，预期每年可有效触达的目标客户数是1000家，则每年的单位价格 = （ 28,000,000/1000+1,000）x（1+30%）= 37,700元。
第三种：按价值定价：指根据客户对产品或服务感知的价值为基础来定价。
比如星巴克通过“第三空间”理念和“星巴克体验”，塑造了独特的品牌价值感，则产品定价时，可按消费者所能承担的价格定价（38元），而不是咖啡的成本价（8元）。
当然，无论采用哪种方式，我们还会参考市面上的竞品价格和目标群体的消费能力。
插件如何定价？
何为插件？
SaaS 产品通常承诺持续免费迭代功能以满足客户需求。
但当我们考虑到插件（Plugin）时，问题出现了：这类依赖宿主软件、可灵活安装卸载的附加组件，其功能迭代是否也属于免费承诺的范畴呢？
让我们通过一个例子来理解这个问题：一款 SaaS 产品包含 10 个标准功能和 2 个可选插件（P1 和 P2）。客户购买后，标准功能的数量固定为 10，而插件功能则根据开通情况而定。
比如客户A未开通任何插件，则可用功能就是10个；客户B开通了插件P1，则可用功能是11个（10个标准功能+1个插件）。
站在客户立场，他们自然希望插件功能也能免费迭代。毕竟，他们订阅的目的是为了满足业务需求，无论这些需求是通过标准功能还是插件实现，都是他们应得的服务。
然而，从 SaaS 厂商的视角来看，情况则更为复杂。他们承诺的免费迭代通常针对的是标准功能。插件生态的构建是为了引入更多元化的功能和资源，如果插件也纳入免费迭代，可能会对市场机制造成冲击，不利于生态的健康发展。
最终方案或为：精选少数官方自研插件免费提供，大部分插件采用按需付费模式。
既然要收费，那如何定价？
作为插件研发人员，我们最近在探讨插件的定价策略，遇到了一些挑战。
最初，我们考虑了三种常见的定价模式：
- 按需定价：参考 SaaS 产品的定价逻辑，根据插件类型和企业员工规模收费。例如，插件 A 在 50 人企业售价 1000 元，在 200 人企业售价 2500 元。
- 按成本定价：基于插件的研发成本定价。例如，插件 A 的研发投入了 10 人日，按每人日 2000 元计算，则定价为 2 万元。
- 按价值定价：根据插件为客户带来的价值定价。例如，插件 A 帮助客户在合规的同时每月节省 2 人日，按此价值定价为 1.5 万元。
我们首先排除了按需定价（选项一），因为插件的启用与员工规模并非绝对正相关，且不利于价格的外部呈现。例如，一家 500 人的企业购买补贴计算插件，实际只有 50 人使用，按 500 人收费客户难以接受，按 50 人收费我们又难以有效进行管控。
基于惯性思维，我们最初选择了按成本定价（选项二），然而这种模式招致了客户和内部伙伴的强烈反对。
例如，我们自研了一个插件，它可以帮助用户解决加班遇到法定节假日时，以0点为界限，明确拆分不同的加班时长与补贴（即工作日加班是1.5倍工作，而节假日加班是3倍工资）。
由于系统复杂及场景多样性，研发成本高昂，耗时30+人日，以3000元/人日计算，成本达9万，约为购买价单个模块的2-3倍。如同购房时装修费超出房价2-3倍，难以接受。
客户反馈：“这个报价有点离谱，你们公司是不是很缺钱？” 这让我们意识到单纯基于成本定价无法体现插件的真正价值，也难以被市场接受。
因此，我们开始重新思考按价值定价（选项三）的可行性，并积极探索如何准确评估和传达插件为客户带来的价值。
最后，我们按照其所提供的价值定价。同时，单个插件不能超过其所属模块价格的30%，且如果插件成本高（即超30人日）时，则可再溢价5%-10%。
比如客户购买单模块价格是2万，插件投入30+人日研发，则其价格不超过6000元最佳（即2万x 30%），最高不超过8000元（即2万 x 40%）。
作为内行，您可能质疑：插件边际成本接近零，为何不采用薄利多销策略？
例如，若定价8千，仅2家客户购买，收入1.6万；而定价2千，10家客户购买，收入可达2万。然而，目前情况下，同一插件销售超过10家客户的情况罕见，为确保成本回收，薄利多销并非适宜选择。
AI Agent 又如何定价？
除了插件外，我们还面临另一个定价问题：AI Agent。
1.按需定价：根据客户需要的Agent数量、调用次数和功能模块来收费。
例如：基础版（1个Agent、5万次调用、1次调优）1万元；升级版（3个Agent、50万次调用、5次调优）5万元；尊享版（10个标准Agent、1个定制Agent、无限调用、无限调优）20万元。
2.按成本定价：例如，开发一个Agent需要15人天，按每人天3000元计算，定价就是4.5万元。
3.按价值定价：比如，一个数据分析Agent能帮助客户决策者有效调用、分析数据并洞察趋势，具有独立价值，可定价2万元。
最初我们选择了“按需定价”，但很快遇到了麻烦：如果按Agent数量收费，该如何界定一个Agent包含哪些功能？
举个例子，一家SaaS公司有5个模块（组织、绩效、审批、考勤、薪酬），则你可以选择：
- 每个模块对应一个Agent（1对1）
- 一个模块对应多个Agent（1对N）
- 多个模块对应一个Agent（多对1）
- 多个模块对应多个Agent（多对多）
如果按Agent数量收费，你自然倾向于选择“多对多”模式，因为这可能带来更多付费机会。但对于客户和产品定位来说，却未必是最优选择。
比如，我们把“数据Agent”拆分成五个（组织、绩效、审批、考勤、薪酬），商业上可以卖五个Agent的钱，但对用户来说操作会非常繁琐，体验很差。
因此，定价不能简单依赖Agent数量，也不能只用一种方式，而需要综合考量。
我们的新思路是：
首先，基础层是按需定价。主要针对用户调用次数和存储空间（比如大模型Token用量、文件存储），这部分相对标准化。
第二，Agent层是按价值定价。即每个Agent独立定价，既考虑产品定位和商业化，也照顾了用户体验。每个Agent根据其价值定价，客户可以按需选择开通。
根据各Agent的实际价值与产品定位差异化定价，例如：
- HR Agent（人事基础服务+政策查询）：1.2万元
- 数据Agent（全模块分析决策）：2.5万元
- 法律Agent（实时法规案例库）：0.8万元
- 假勤Agent（假期管理全功能）：1万元
- 排班Agent（智能排班系统）：1.5万元
- 等等。
写在最后
最后想说的是，产品定价既是一门技术，也是一门艺术。定价方法丰富，本文仅从实际问题出发，粗浅地探讨了按需、按成本和按价值这三种常见模式。
需要强调的是，定价绝非产品经理的“独角戏”。以上内容，更多是我作为一名产品经理的个人思考与梳理，更是一个定价领域“小白”的尝试性分享。若能为你带来一丝启发，便是我最大的荣幸。
专栏作家
邢小作，微信公众号：产品方法论集散地，人人都是产品经理专栏作家。一枚在线教育的产品，关注互联网教育，喜欢研究用户心理。
本文由作者原创投稿/授权发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议 |
|
发表于 
