惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

大猫的无限游戏
大猫的无限游戏
MyScale Blog
MyScale Blog
雷峰网
雷峰网
量子位
小众软件
小众软件
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
博客园 - 叶小钗
T
Tailwind CSS Blog
月光博客
月光博客
博客园 - 【当耐特】
博客园_首页
罗磊的独立博客
博客园 - 三生石上(FineUI控件)
IT之家
IT之家
爱范儿
爱范儿
阮一峰的网络日志
阮一峰的网络日志
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
WordPress大学
WordPress大学
The Cloudflare Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
S
SegmentFault 最新的问题
人人都是产品经理
人人都是产品经理
V
V2EX
酷 壳 – CoolShell
酷 壳 – CoolShell

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
产品定价复盘:SaaS插件/AI Agent如何定价?
产品方法论集散地 · 2025-05-29 · via 人人都是产品经理

在SaaS和AI领域,定价策略是企业实现商业化和盈利的关键环节。本文通过作者所在SaaS企业的实际案例,深入探讨了插件和AI Agent的定价策略,供大家参考。

作为一家成立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元)。

当然,无论采用哪种方式,我们还会参考市面上的竞品价格和目标群体的消费能力。

插件如何定价?

何为插件?

插件(Plugin)是一种可以扩展或增强现有软件功能的附加组件。它依赖于宿主软件(如Chrome浏览器),用户可以根据需求选择安装或卸载(如广告拦截器或自动翻译),避免主程序过于臃肿。

SaaS 产品通常承诺持续免费迭代功能以满足客户需求

但当我们考虑到插件(Plugin)时,问题出现了:这类依赖宿主软件、可灵活安装卸载的附加组件,其功能迭代是否也属于免费承诺的范畴呢?

让我们通过一个例子来理解这个问题:一款 SaaS 产品包含 10 个标准功能和 2 个可选插件(P1 和 P2)。客户购买后,标准功能的数量固定为 10,而插件功能则根据开通情况而定。

比如客户A未开通任何插件,则可用功能就是10个;客户B开通了插件P1,则可用功能是11个(10个标准功能+1个插件)。

站在客户立场,他们自然希望插件功能也能免费迭代。毕竟,他们订阅的目的是为了满足业务需求,无论这些需求是通过标准功能还是插件实现,都是他们应得的服务。

然而,从 SaaS 厂商的视角来看,情况则更为复杂。他们承诺的免费迭代通常针对的是标准功能。插件生态的构建是为了引入更多元化的功能和资源,如果插件也纳入免费迭代,可能会对市场机制造成冲击,不利于生态的健康发展。

最终方案或为:精选少数官方自研插件免费提供,大部分插件采用按需付费模式。

既然要收费,那如何定价?

作为插件研发人员,我们最近在探讨插件的定价策略,遇到了一些挑战。

最初,我们考虑了三种常见的定价模式:

  1. 按需定价:参考 SaaS 产品的定价逻辑,根据插件类型和企业员工规模收费。例如,插件 A 在 50 人企业售价 1000 元,在 200 人企业售价 2500 元。
  2. 按成本定价:基于插件的研发成本定价。例如,插件 A 的研发投入了 10 人日,按每人日 2000 元计算,则定价为 2 万元。
  3. 按价值定价:根据插件为客户带来的价值定价。例如,插件 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家客户的情况罕见,为确保成本回收,薄利多销并非适宜选择。

注意:此案例是以笔者所在的B端SaaS企业为例,并不一定适用于C端SaaS产品。

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协议