SaaS产品定价(三):计费对象及价格版本

0 评论 13811 浏览 46 收藏 23 分钟

在对定价原理及其策略方法进行了了解之后,具体该怎么做呢?本文分享了关于SaaS产品的定价的一些原则和实操技巧,一起来看看定价的5个子话题,希望对你有所帮助。

咱们在前两篇聊了定价原理及五花八门的策略。那么SaaS产品的定价有哪些原则和实操技巧呢?咱们今天详细聊聊5个定价子话题:

  1. 计费对象的选择
  2. 明价与暗价
  3. 价格版本
  4. 同一客户的混合阶梯价格
  5. toB不需要“赠品”

一、计费对象的选择

有300多位同行参与了我在3月底发起的“定价方式”投票:

可以看到约有36%的朋友投了最经典的按人年收费的方式;31%是每个企业固定费用;按消耗计费的比例14%;在留言区讲到自己公司的产品是混合定价方式的朋友也不少 ……

这个结果还是挺意外的,看来已经有很多SaaS企业采用的定价方式不是经典的“人年”方式。

计费对象应该如何选择?

最近,我的朋友高宁在关于PLG的对聊节目中说到一句话:通过定价(pricing)传递价值。

我觉得切中了要害。

如何通过定价,能够把本产品与其它产品的价值差异凸显出来?如何让这个价值更容易传递给客户?

我们可以推演计费对象的选择有三个原则,顺序如下:

  1. 真实反映产品价值
  2. 反映出本产品与其他产品的差异
  3. 报价简单易懂

我们就在这三个维度上,分别为以上定价方式打个分。

我们按推荐顺序一个个分析:

1、分销售额的方式是价值感最高的。但前提是SaaS企业能向客户证明销售额的增长与产品直接相关。我见过有个别行业SaaS公司能做到这一点,是有点儿可遇而不可求。作为行业SaaS公司,在考虑商业模式(/收费模式)时应该经常做深度思考。

2、按订单数(客户业务场景)等业务消耗量计费,在价值传递上比经典的按人·年计费优秀,客户一年需要多少订单也容易算清楚。对客户的购买成本来说,订单少意味着营收少,所需支付的SaaS费用也少;而那些订单数量大的客户,由于营收高,对较高的SaaS费用也愿意接受。

这其实是比下文要讲的“多个价格版本”更贴近需求曲线的方式,有机会几乎占满需求曲线左下方的三角形。

(上图中,需求曲线已简化为直线,而价格线则确实是随着客户业务订单数增加而线性变化的)

我们举几个例子:

3月底帖子的留言中,微猪科技的合作人张佳就介绍说,他们的SaaS按母猪头数计费。这个就让客户很容易理解和接受。

另外,也有连锁行业SaaS是按门店收年费,不限用户数,门店年费阶梯递减(有年费上限)。这也是与客户业务关系紧密,属于不错的设计。但有个维度没考虑到,就是有的品类门店数量巨大,但每个店其实非常小、营收也不高(例如半平米的鸭脖店);有的品类则单门店营收很高(例如中式正餐)。按店收费对他们不公平,对SaaS公司来说,也损失了不少本应能收的费用。可以再考虑一下,有没有与营收更相关的收费方式(多想想上图)。

我们看看这个例子:“船舶管理SaaS系统,按船舶数量和吨位级别收费”,这就是与客户业务量更直接的收费方式。

会展星的杨同学谈到:有的会展2000个展商,有的1000个展商,展商数量的多少基本决定了客户的实力,我们按招商数量的多少来来阶梯收费。这个也很赞 :)

我们再看一个例子:供应链金融SaaS,平台注册使用都免费,产品费用其实算进利息里。这也是非常“顺滑”的计费方式,客户甚至无“痛感”。我们前面的文章说过 —— 看到价格,客户就会有真实的疼痛感。

3、最经典的SaaS计费对象是按人年计费。对客户来说,这种计费方式比较容易理解,但价值传递和差异性都较低。可以看到超过1/3的SaaS产品按人年计费,包括纷享销客、卫瓴、网易七鱼等。

4、每个企业固定年费:虽然很容易让客户理解,但产品价值传递很弱。这类计费方式一般存在于客单价较低(≤2万元)的市场中,各家竞品间的定价策略能展现出的差异也小。

5、按IT消耗量计费:由于网络流量、API调用等是纯IT的概念,与客户业务之间(例如直播销售额、招聘结果等)没有直接关系,客户既难以理解、又无法预估一年下来费用有多大。记得我们在上篇《定价2》中说到,“不确定性是成交杀手”吗?

同时,这个“计费对象”的选择对产品价值的传递也比较弱;所以是交易摩擦比较大的计费方式。

在3月底的那次征集定价方式投票的文章后面,也有读者提出这个问题:①客户不理解流量、存储是什么含义 ②客户没有办法在购买时做用量费用估算,又不希望购买之后因为使用的流量、存储空间等原因,再次走流程申请费用。

这是按咱们IT人理解方式计费带来的困难。

当然,如果已经用了流量等作为计费方式,可以考虑用“预存”和“后端收费”的方式,降低客户付费时的摩擦。

顺便说一句,部分成熟的SaaS企业,即便是按人·年计费,也会用“后端付费”。具体来说,客户企业在5月份突然要增加98个账号,没关系,立即就给客户增加User数量上限,然后次月起才计费。

6、按并发上限计费:该计费对象也是IT逻辑,但其好处是反映出本产品与其它产品的差异。举个例子,某SaaS产品A能完美支持1万并发,而其他类似产品都只能做到1000人同时在线;A产品就可以用并发上限计费,通过一个报价就能非常明确地凸显出公司技术实力,也指明友商的弱点。

如果有其它凸显产品技术实力的计费对象,也可以按此方式使用。

7、OP软件按模块计费:按软件按模块报价虽然组合灵活,但实质上是不理解客户的业务模式及场景。除了给客户带来选择困难、增加解释成本,也给后面的实施及服务工作带来预期管理和执行上的困难。我不推荐SaaS产品使用该方式计费。

8、混合方式:在价值传递、差异性上也许有一些优势,但客户理解的复杂度较高。

读者留言中,有提到“年费与消耗量组合方式”、“预算分析SaaS产品:按照客户使用人数(分为高级用户和初级用户,不同标准)和数据容量收费”,这些都是混合方式。

如果只有这样计费,才能与客户实际的业务贴合得紧密,这也许是个选择。否则,混合方式如无必要,尽量不用。

每个SaaS产品在定价时都有一些限制条件,所以做出的选择各不相同。在选择“计费对象”时,可以多想想上面这3个原则。

二、明价与暗价

看国内各家SaaS公司的官网就知道,客单价低的SaaS产品大多会在官网展示价格;客单价高的产品一半会展示价格、一半“价格面议”。

我查了一下硅谷SaaS公司的官网,Salesforce的销售云、Zendesk的官网是展示价格的,Workday的官网则没有。

(上图来自:Salesforce的官网)

(上图来自:zendesk的官网)

我们来思考一下——明价与暗价,应该如何选择?

首先,友商如果想要,一定有办法拿到我们产品报价;所以这不是考量因素。

因此,官网是否展示价格,主要考虑客户的感知;有正反两方面:

A. 暗价(官网不展示价格):

a1. 担心潜在客户看到价格后吓到了,根本不联系我们的销售;

a2. 希望客户无论如何都与在线客服联系一下,最好能留下联系方式

a3. 报价确实太复杂了,需要有销售代表解释说明

B. 明价:客户看不到价格,先去找看得到价格的网站了

—— 判断A、B的比例各有多少?决定了我们应该采取明价还是暗价。

关于a1,对于高客单价的SaaS产品,企业采购者肯定知道要谈折扣,所以这个担心并不存在。

对于a2,倒是一个考虑因素。我们如果看看Gainsight的网站(客户成功专用的工具SaaS),就会发现他们是非常希望与客户形成接触的;我简单展现一下过程:

①从Google搜索Gainsight,点击左侧第一个链接进入官网后首个页面就是留资、预约Demo:

我感觉还是挺惊讶的(有一定可能性是他们正在做A/B测试,不同User进来看到页面的不同)。

②在官网可以找到“Pricing”(报价)页面,但也不直接展示价格

点击“询价”后,出现的还是留资页面……(我感觉他们这个AB测试有点过火了啊

(顺便说一下,我向很多客户成功岗位的同学推荐过Gainsight.com的Resource,作为排名第一的客户成功工具,他们在市场教育方面还是挺给力的)。

那么留资后报价的方式是否正确呢?这个见仁见智。询价客户的感受是——你们有些爱绕弯子、你们的价格是否太贵了所以不愿意直接展示出来;但留资的价值确实会很大,这里需要取舍。

我们再从营销的角度看这一点——潜在客户已经来到网站,说明已经在被我们影响的道路上。“一次成交需要7次触达”,所以急于催熟未必有好结果。何况在微信时代,留下电话号码也未必有多大价值 —— 这两年大家已经发现,加上微信才是王道。

如果是a3情况(报价太复杂了,需要有人解释说明),确实没办法在官网直接展示,否则潜在客户看后会更糊涂。

所以,我的建议是:如果计价方式简单明确,尽量明示定价。

我还记得,5年前我在纷享销客的老战友王东说过:未来企业采购SaaS产品能否像在京东超市采购办公用品一样——价格透明、没有折扣和猫腻?(大意如此)

SaaS时代,我们并不是把OP软件的功能搬到云上,营销方式也需要有彻底改变。

从中国SaaS全局的视角看,“京东模式卖SaaS”—— 这确实会是我们更好的未来。

三、价格版本

上篇我们谈到“捆绑价格”的意义:客户购买一个商品的过剩意愿被转移至另一个商品上。

SaaS产品分“基础版”、“标准版”、“旗舰版”就是如此设计的。

OP软件时代按上几十、上百个功能模块分别报价的模式,在SaaS时代已经被摈弃。

上一篇《定价2》中提到:SaaS报价则希望给客户3~4个清晰的使用模式,避免客户选择障碍、减少销售摩擦。更重要的是,这令得产品的每个价格版本都有一个清晰的应用场景,更有利于产品经理及服务同事理解客户、帮助客户实现产品价值。

上面这是小鹅通官网上的价格页。可以看到红框中描述三个版本的是客户应用场景。

SaaS产品应该更关注“场景”而非“功能”。场景是相对稳定的本质;功能是浮在上面的表象。

不少SaaS公司没有理解到这层含义,在官网的报价是OP软件和SaaS的“合体”——在几个价格版本之下,又有很多需要单独购买的模块。那问题来了,如果客户需要“专业版”,又需要某个“旗舰版”才有的功能,这本身不是推动客户购买旗舰版的好机会吗?

对于中低客单价(≤8万/年)的产品尤其如此,没有必要在“价格版本”之外又增加单独购买项目。

对于高客单价产品(≥20万/年)的产品,也许值得用上述“合体”方式——毕竟购买更高版本可能会一年多付几十万,让客户和销售都费点力气还划算。但也没必要反映在官网上,可以在内部价格文件里体现。

我们来总结一下 —— 多价格版本的定价原则:

1、价格版本与客户应用场景(组合)相关,而与厂商从开发者视角的功能分组无关。

2、入门版本应该越轻越好:快速成交首单+服务过程中增购(Landing & Expand),这是SaaS业绩快速增长的最佳实践之一。所以我们可以设计一个容易上手的“基础版”,以此缩短销售周期、降低首次实施和上线的难度;再图服务过程中的Upsell(增用户数)和Cross-sell(增模块或升级版本)。

对于入门的价格版本及其产品功能设定,我有两句话分享给大家:在业务闭环的前提下,功能越简单越好;在不被击穿的前提下,产品越锋利越好。

3、价格版本不宜太多:一般3~4个为宜,过多的版本会增加客户选择困难和销售解释成本;

4、中间版本是大部分人的首选:如本系列《定价1》所说,人类做选择经常受“锚定效应”影响,最高价、最低价都是“锚”。初步接触,大部分客户会选择中间价格版本。

5、每个版本之间的价格不宜差距太大:一个版本的价格不宜超过低一级版本的120%,否则客户有向下选择的惯性。

这里举个例子,如果价格版本是这样分布:

大家作为客户感受一下——每个版本价值不同,但首选居中专业版的可能性最大。

但如果价格阶梯是这样设置的:

估计放弃专业版,选择标准版“先尝试一下”的人就会占更大比例。

当然,这一条与“价值场景”是否清晰有很大关系。如果“专业版”针对的客群特别清晰,这类客群一看就知道自己不能选“标准版”,那价格差就可以克服。

四、同一客户的混合价格版本

去年我与纷享销客的创始人罗旭聊天时,说到一个价格版本应用中的一个更复杂的情况:如果一个企业中有100人需要用旗舰版(例如销售部门的员工)、900人需要用基础版的功能(例如销售支持、市场、服务部门的员工),怎么办?

按照常规做法,一个企业只能购买一个价格版本。在实操中,如果要求1000人都用旗舰版,客户一定会讨价还价——“我们大部分人都用不到旗舰版的功能,请给我一个深折扣”。于是,超低折扣就出现了。

更尴尬的是,随着在该企业的产品应用场景逐步深入,越来越多的员工需要使用旗舰版的功能,而SaaS厂商却不能实现增购……过去的那个深折扣,会一直保持下去。

所以,更佳的方式是,一个企业购买我们的产品,可以有一部分员工使用旗舰版、一部分使用基础版。

一个SaaS创业公司也许要到了纷享销客这样的成熟阶段才会遇到这样的问题。但如果在设计产品架构和后台运营系统时先考虑到这一点,将会省下未来的一番折腾(也请同时考虑提前把架构弄复杂的代价)。

五、toB不需要“赠品”

正巧,笔者在SaaS创业过程中也有一段关于“赠品”的经历。

当时公司的主产品营收以一年10倍的速度增长,为了完成新一年的销售目标,我们规划了7个新模块,客户可以单独购买。

上线后,有3个新模块价值很抢眼,销售同学们也取得了突破。这时候出现了尴尬的问题,研发资源已经转回主产品,新模块的产品体验只有70分,要达到90分还遥遥无期。

这时我犯了一个错误——销售体系决定将新模块作为“赠品”附送给客户(功能更多,这也增加产品整体价值嘛)。

其实不然,客户在赠送的模块上如果遇到使用困难,仍然会找CSM(客户成功经理)或销售代表解决;为这批客户在一个70分的小模块耗费的服务精力比主产品还多。随后,销售代表也不愿意送了,因为客户反馈问题迟迟不能解决,反而影响了客户关系。

所以,toB产品的价值其实越简单越好。“赠品”多没有意义。产品包括的功能越少,产品价值反而越容易传递到位。

总结:

今天我们说到5个定价子话题:

  1. 计费对象的选择
  2. 明价与暗价
  3. 价格版本
  4. 同一客户的混合阶梯价格
  5. toB不需要“赠品”

到这里,我们把SaaS产品定价的框架说得差不多了。但还有一个最大的疑问没有谈及,就是 —— 我们的产品价格数目字到底应该定多少?

特邀作者

吴昊,微信公众号:SaaS白夜行,SaaS领域知识沉淀者,《SaaS创业路线图》作者。每年与100位SaaS创始人深度交流,结合实战不断在公众号及视频号做内容输出。

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

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

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