enterprise是什么版本的？我们可以看到这个网站的介绍是这样的：它是一个开源的软件平台，提供各种工具，包括java、c#、python、ruby、perl、php、rubystudio、pythonserverperl等。这些工具可以帮助开发人员快速构建应用程序，同时也可以帮助用户更好地理解应用程序。下面我们就来看看这些工具的使用 *** 。以下是一些常用的工具，如果你正在使用它们，请记住它们的名字。这些工具都有什么功能呢？让我们一起来看看吧。”。
在对定价原理及其策略 *** 进行了了解之后，具体该怎么做呢？本文分享了关于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创业公司也许要到了纷享销客这样的成熟阶段才会遇到这样的问题。但如果在设计产品架构和后台运营系统时先考虑到这一点，将会省下未来的一番折腾（也请同时考虑提前把架构弄复杂的代价）。
五、toB不需要“赠品”
正巧，笔者在SaaS创业过程中也有一段关于“赠品”的经历。
当时公司的主产品营收以一年10倍的速度增长，为了完成新一年的销售目标，我们规划了7个新模块，客户可以单独购买。
上线后，有3个新模块价值很抢眼，销售同学们也取得了突破。这时候出现了尴尬的问题，研发资源已经转回主产品，新模块的产品体验只有70分，要达到90分还遥遥无期。
这时我犯了一个错误——销售体系决定将新模块作为“赠品”附送给客户（功能更多，这也增加产品整体价值嘛）。
其实不然，客户在赠送的模块上如果遇到使用困难，仍然会找CSM（客户成功经理）或销售代表解决；为这批客户在一个70分的小模块耗费的服务精力比主产品还多。随后，销售代表也不愿意送了，因为客户反馈问题迟迟不能解决，反而影响了客户关系。
所以，toB产品的价值其实越简单越好。“赠品”多没有意义。产品包括的功能越少，产品价值反而越容易传递到位。
总结：
今天我们说到5个定价子话题：
到这里，我们把SaaS产品定价的框架说得差不多了。但还有一个最大的疑问没有谈及，就是 —— 我们的产品价格数目字到底应该定多少？
特邀作者
吴昊，微信公众号：SaaS白夜行，SaaS领域知识沉淀者，《SaaS创业路线图》作者。每年与100位SaaS创始人深度交流，结合实战不断在公众号及视频号做内容输出。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。