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

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

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

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

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

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

　　计费对象应该如何选择？

　　最近，我的朋友高宁在关于PLG的对聊节目中说到一句话：通过定价（pricing）传递价值。

　　我觉得切中了要害。

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

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

　　真实反映产品价值反映出本产品与其他产品的差异报价简单易懂我们就在这三个维度上，分别为以上定价方式打个分。

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

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

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

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

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

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

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

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

　　总结：

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

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

　　特邀作者

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

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

　　题图来自Unsplash，基于CC0协议

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