如何定价、如何定价最合理

编辑导语：SaaS版本如何做好定价？关于这个问题，本文作者可能有切身体会。首先，你需要明确版本定价的目标是什么；之后，你便可以继续厘清思路了。本文作者详细阐述了如何做好SaaS版本的定价的问题，感兴趣的小伙伴一起来看看吧。

在个人的职业生涯中，经历过一次轰轰烈烈产品版本升级，过程中感受到了这件事情有多痛苦。

它涉及时间长，工作细节多，参与部门广，客户满意难。

但与此同时，它也建立了对企业内部对客户，对产品的一致性认识，引导各个部门以产品版本为核心，重塑了自己的工作内容，并在后续产生了相当不错的营收效果。

所以，希望和你分享过去的经验和现在的思考，从一个模型入手，打开SaaS版本定价的方法论。

一、版本定价的目标

众所周知，SaaS收入=付费客户数*客户付费金额。

而这两个数据，在SaaS不同的阶段，得到的关注度也不同。

在产品的成长期，往往着力的是付费客户数的增长，但随着客户数量的增长，市占率慢慢向天花板逼近，不得不转而考虑增加客户的付费金额。

在产品的成熟期，往往着力的是客户付费金额的增长，需要客户成功团队去交叉销售，挖掘产品更大的潜力，但可能忽略了客户还有向下扩展的机会。

那有没有一套定价方案，可以同时考虑到两个因素，横跨SaaS的生命周期，建立起一套更标准化的一种定价方式呢？

有，按版本收费。

建立合理的版本定价机制，可以达成用户量和用户付费金额的双赢，并且，这一套机制可以从初创期用到成熟期，无需内部团队、合作伙伴、客户适应多变的收费模式。随着时间的扩展，也可以这一套模型做基础，去延伸其他的收费策略。

想想看，对于没有太多预算的客户，只要在现有的功能上推出一个降级的版本，几乎不用付出额外的技术成本，就可以快速的服务于他们，并为公司争取额外的收入。

而对于规模较大，管理体系规范的客户，往往在安全和管控上会提出更多的需求，也理应让这部分客户付出额外的溢价和成本。

不放过一个可能使用产品的小客户，也努力从大客户包里掏出更多的钱，是版本定价的目标。

二、版本定价的思路

在市场上，几乎随处可见按版本收费的形式。

从鼻祖Salesforce。

到低代码平台简道云。

再到教育垂直领域领导者小鹅通，都能看到它的身影。

再多搜集一点案例，大概可以就业务类型和工具类型的SaaS的区别，得出一些结论。

服务于企业业务的SaaS，有着以下特征：

关于免费：因深度绑定业务，很少提供免费版。

也确实看到很多SaaS专家旗帜鲜明的反对做免费版。看上去是自己和客户都不用付出成本的双赢，但同时也就意味着对双方都没有约束，那SaaS本质的服务属性又怎么体现呢？

关于限制：在人数，核心功能，管理诉求上设置卡点，引导客户更多的付费。

首先，限制使用人数是最常见的一种形式。

当客户的人数超过该版本预设的数量上限，此时可以引导客户升级或增购用户包来满足不同情况的需求。当客户既需要更多人来使用，又需要高版本的功能，就推荐客户升级版本。当客户仅仅只是想增加使用人数，对功能升级没有诉求，推荐更便宜的增购用户包方案即可。

其次，当一个功能可以直接为客户创造价值，无论是降本增收还是提效，都可以有限制的让客户使用，或者仅在高级版本开放。

举一个限制的例子：在客户关系管理软件CRM中，就可以考虑限制录入的订单数，这个需求是客户管理的延伸，且离钱更近，在客户心智中的价值更高。想想看，一个订单数都超出限额的客户，多半处于业务蒸蒸日上的阶段，向客户索要更多的投入也就顺理成章了。但也要注意，限制的数量要经过精心设计，不能阻碍普通客户正常使用，但又能刚好让高于普通水平的客户感觉到不够用。

再者，版本的升级诉求，背后隐藏着的是管理升级的期望。

当一个客户体量达到了不错的水平，才会在管理意识的提升上，延伸出大量的管理诉求：安全模块，风险管理，数据报表，流程控制等等，这些都是适合放到更高版本的功能。

关于优惠：对于客户的拉新，转介绍等贡献，仍然是认可和鼓励的，但不会换取免费使用的权益，最多发放折扣券。

相比于业务SaaS，工具类型的SaaS策略又不一样。

关于免费：由于最开始都瞄准个人用户，所以几乎都有免费版本。

关于限制：在客户使用深度和使用人数上设置卡点。

• 当一个客户想用略微高级一点的，区分于常规用户的功能，那要收费。
• 当一个客户已经产生了比较多的用量，例如创建了超多的文件，占用了超大的空间，那要收费。
• 当一个客户想和多人协作，那也要收费。

关于优惠：向客户索取其他报酬。

如果客户不愿意付出金钱，那么可以想办法推荐工具获取积分，再用积分去兑换使用权限，这是工具类可以运营的地方。

可以看到，这两种类型的产品，在免费策略，优惠策略上都不太相同，但在对于版本的限制上有很高的重合度。核心可以归纳为：限制使用人数，限制使用的广度，限制使用的深度。

通过定义版本的限制和区别，其实也就是在回答：每一个版本服务于谁，希望解决谁的什么问题。

换句话说，我们设计版本和定价的思路，和设计产品的思路是一样的，本质都是面向确定性的对象，去交付价值，以及收回报酬。

三、版本定价的设计

那么，怎么去做版本定价呢？

这里根据公开资料，整理了一份标准的版本定价单。

把报价单看成最后的产出和成果，再来倒推和拆分其中的模块，就可以知道需要哪些信息，而为了获得这些信息，我们如何规划工作也就跃然纸上了。

总的来说，一份报价清单可以由五个部分构成，分别是版本、客户、价格、服务以及功能。接下来看看每一个部分的设计要点。

1. 版本

版本是需要最先被确定的内容，设计几个版本，直接决定了公司的盈利构成、销售打法、产研策略，是值得慎重再慎重的话题。

而服务于业务的SaaS，多数提供2-3个版本。

对于每个版本而言，他们在企业中的作用和策略各不相同。

（1）基础版

首先避免“基础版”这类不够中性的描述，尽量把收费最低的版本称为标准版。

作用：投入较小的成本，给客户和企业自身一个机会，来互相了解和陪伴成长。除此以外，它也是专业版的锚定版本，会显得专业版更加划算。

策略：控制成本，尽量限制除MVP以外的其他功能，维持在刚刚够用的状态。

（2）专业版

作用：能让多数客户的需求在这个版本得到满足，是主推的版本，是最主要的获取收入的版本。

策略：引导用户多多使用该版本。日常产品工作中，大部分的需求都是会放在在这个版本中的，给予版本足够丰富的能力和诚意的价格，让版本显得很有吸引力。

（3）旗舰版

作用：是功能最全最完整的版本，同时也是很多标杆客户会选用的版本，是较为稳定的收入来源，同时优质客户的选用，也可以为公司增加信用背书。

策略：转化部分有实力的专业版客户至旗舰版，但该版本对于客户自身实力和管理要求较高，只适合去引导，在客户有意愿的时候多做介绍，很难直接强行转化。另外产品工作中，会抽出一定比例的时间去服务于这个版本，开发只有这个版本客户需要的能力。根据经验来说，当产品进入到成熟期，还会主动提出新的需求的客户，一般就来自于这个版本。

确定了有哪些版本，每个版本再按照企业的规模大小以及企业的核心诉求来进行规划内容。

以CRM 为例，说明产品拆分为4个版本的思路。

版本1：MVP版本，实现业务的简单记录，沉淀数据。供10人以下，权限简单，结构扁平的小团队使用。价格便宜，有些企业甚至免费提供。

版本 2：一般能实现一些一些自动化的功能，比如流程的自动审批，注重效率的提升。可以理解为一个性价最高的版本。一般的客户在这个版本就基本足够使用了。

版本 3：提供可以适配企业不同需求的功能，比如流程的自定义、报表的自定义等等。在版本 2的基础上，注重个性化，也增强了数据的智能化水平。

level 4 ：最强版本。更多的向扩展服务场景，提供更多的能力，以及提供更高的扩展性，以便打通客户内部其他系统。同时在前几个版本中有限制用量的服务，可能在这个版本放开。例如calls，api调用、储存。

2. 客户

客户部分的信息解决了每个版本为谁服务的问题，是定价的支撑。为了让你的定价有据可依，请回答下面4个问题：

1. 客户画像：每个版本服务的客户规模是怎样的，业务、流程、组织、管理、意识等方面，有着什么样的特点。
2. 客户关注：基于客户画像，聚焦说明每个版本的客户有哪些方面的痛点，关注哪些方面的问题。
3. 使用角色：说明每个版本的客户，哪些角色会使用系统。
4. 解决方案：每个版本的客户，你预计为他提供哪些模块，帮客户实现哪些目标。

问题问完了，如果你的回答清晰分明，说明你的版本划分已经成功了一半。

但如果你的回答模模糊糊，那可能就代表着产品的版本划分缺乏依据。

为了更好地理解如何描述这些信息，假想了一款CRM产品，做了下图的demo，可供参考。但要说明的是，本表仅用于说明设计方式，不代表任何真实情况和数据。

3. 价格

在价格部分，一般会说明版本需要收取的固定费用，以及当前的促销活动。

（1）版本费用

这里要明确的是两件事情，一是版本按照哪些维度计费，二是测量目标客户按照收费标准会付出的成本，以确定每个版本的收费额金额。

先说收费维度。

常见的有人数 、时间、用量三个维度，往往选择其中1-2个作为收费维度。

具体案例上，仅按时间收费，有hubspot的CMS产品。

按使用用户数*使用时间收费的，有Salesforce的绝大多数产品。

按使时间*功能用量收费的，有hubspot的Marketing产品。

建议设计的时候一定注意控制维度的个数。

选择单独的1个维度，或者选择2个维度来组合，问题都不大，也是很常见的收费模式。但如果涉及到两个以上的变量，模型会变得很复杂，把客户绕糊涂的同时，自己也会算不过来。

更要命的是，一旦设计了复杂的体系，再想重新走回简单的路子就很难了，想要把现有客户的收费逻辑全面转成新的，需要梳理、测算、开发、告知、安抚，需要动用公司各部门的力量，也会经历许多客户的不理解和不满意，所以在无法确定未来会怎么发展的时候，简单是更优的一种选择。

价格制定上，很常见的一种策略是跟进竞品，在成熟的市场，往往已有了先行军开路，以同一等级的价格进入，在用户心智层面能占据相似地位，同时避免打价格战破坏市场。如果没有成熟的定价可以参考，以客户会分配1%-2%作为IT预算的标准，作为定价的天花板。

例如客户年收入100万元，则假设用户会投入1-2万元到IT建设中，把这个数字范围作为产品的定价参考。

（2）促销活动

可以设置长期的促销活动，一次性付款更长的周期可以享受折扣。也可以在界面上标注短期的限时活动，影响用户决策。

4. 服务

描述了每个版本中提供的服务范围和限制，一般包括功能型的服务，人工型的服务，以及增值服务。

（1）功能服务

在上一步已经设置了版本收费的维度，确定了版本是按照人数、时间还是用量去进行收费的。那在这一步就需要进一步限制各个维度的数量，决定在每一个版本中，人数、时间、用量的具体数量。

举例：如果是按使用人数来进行收费，这里可以在三个版本中，依次限制使用人数为10，20，30。

除此以外，也可以把功能用量和增值服务用量放到基础服务中。

例如图中的例子，首先创建订单是产品的核心功能，是用户一旦购买就会使用的且认为有价值的能力。现在有一个客户，随着业务量慢扩大，订单的数量远超出平均水平，但实际客户管理体系简单，并不需要高版本的能力。那么此时还有什么方法促进用户增购呢？

答案：把订单的用量作为版本的限制条件，创造出新的不满足来诱导客户升级。一个客户的平均订单金额在100元，每个月有1000单成交，这个数据高出行业水平不少，至少说明客户的经营状况不错，是有实力购买专业版的，也就可以顺理成章的引导客户做迁移。

所以限制重点功能用量的意义在于：让客户在条件允许的情况下，尽量升级到大版本。

不过这个方案在实践中，需要慎用，太容易阻断客户使用流程，引起不良的观感。

除了限制功能的用量，把增值服务纳入版本也是常见的一种方式。

它可以让客户尽量无负担的体验部分增值服务，做到较低成本的冷启动，随后引导用户购买额外的增值服务，引导客户的付费习惯。

（2）人工服务

包含部署方式、系统运维、服务时间、培训支持等常规信息。

（3）增值服务

常见的增值服务分为三类，分为增购包、人力服务以及第三方服务。

从版本限制中延伸的增购包：

版本中限制了数量的，且用户有零散购买需要的功能，都可以拿来设置增值服务包。

例如原本就是按照用户计费，那么可以设置用户增购包。原本订单录入和语音通话都在版本中进行了限制了用量，为了满足用户有临时购买的意愿，以及满足用户不想付出升级版本的过高的成本，可以设置增购包满足用户使用。

一般而言，除了增购用户，其他的增购包价格不区分版本，统一定价。

另外为了减少服务成本，有些增购包会提出10个起买这样的限制。

也见过增购包不对低版本开放，从而鼓励升级到更高版本的情况，但是这种方案，要视增购包的具体场景和属性慎用，万万不要影响了大部分用户版本的正常工作。

人力服务：

一般包括咨询和技术服务。会按照人日进行收费。

不过国内的SaaS公司，很少看到咨询和培训服务的单独收费，不知道是否和客户需求较少，以及提供服务方的收费能力不足有关。从侧面也能看出，通过咨询上的服务去给客户提供价值，在国内SaaS上还任重道远。

三方增值服务：

例如短信、邮件、网络存储，都是常在SaaS中出现的内容。

是需要外采三方服务，由自己做分发的方式进行服务的，未来有机会也会讲讲这部分的产品设计。

4. 运维

最常见的是为客户提供私有化部署。这类形式往往是使用客户指定的服务器，由客户自己运维。实际操作中，难点在于版本有了新功能，如何和客户沟通和迁移，以及面临客户如果做了定制需求就永不能顺滑升级的困境。

专享服务器是较为少见的一种形式。是指把客户的数据单独放在服务器中，但运维方仍然是企业。

5. 功能

提供功能的形式基本会划分为三种：完全提供、不提供以及部分提供。

特别要说的是，限制提供的能力往往是促使客户升到最高级版本的动力。

例如客户需要自定义多层审批，但是中间等级的专业版只提供3层审批，这样的功能多了，就比较容易引导客户往高级版本升级。

另外还能看到了一些新奇的玩法：把功能变成增值服务。怎么做呢？把高级版本的功能开放给低版本的用户付费使用，最大地利用了功能的价值。

四、总结

由于篇幅所限，这次聊到的主要是版本定价的概念和成果，后面将会陆续去讲定价实施的流程以及大坑，还有配套的产品后台设计方式。

好了，我们再来回顾一下本次的内容。

1. 版本定价的目标：不放过一个可能使用产品的小客户，也努力从大客户包里掏出更多的钱。
2. 版本定价的思路：业务型SaaS和工具型SaaS的常见特征剖析；同时明确版本定价的思路，是面向确定性的对象，去交付价值，以及收回报酬。
3. 版本定价的设计：通过1个模版，手把手教你填写定价单的5个模块。

作者：假装是运营，微信公众号：SaaS学姐

本文由 @假装是运营 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自unsplash，基于CC0协议