第3章分层定价模型

3、分层定价模型：功能分层、用户量分层、使用量分层、混合分层模型的设计原则

好，咱们直接进入正题。分层定价，说白了就是给不同客户画不同的「价格跑道」。你想想看，一个SaaS产品要是只卖一个价，那基本等于把大部分客户往外推。小客户嫌贵，大客户觉得功能不够用。

我这些年做过的SaaS项目，几乎没有一个是不做分层定价的。但怎么分、分几层、每层放什么功能，这里面的门道可不少。今天我就把四种主流的分层模型掰开揉碎了讲清楚。

功能分层，就是按「你能用多少功能」来定价。基础版给核心功能，专业版加高级功能，企业版全开。

设计原则其实就一条：每一层都要有独立的「价值锚点」。什么意思？就是客户升级时，能明显感觉到「多花的钱值了」。

核心原则：功能分层不是简单地把功能切几块，而是要让每一层都能独立解决某一类用户的完整问题。

举个例子。我做过一个项目管理工具，基础版只给看板视图和任务分配。专业版加了甘特图和资源管理。企业版再加OKR和跨项目报表。你看，每一层都是一个完整的「管理闭环」。

这里有个坑，我踩过。千万别把「核心功能」拆到不同层里。比如，你不能让基础版能创建任务但不能分配任务——这会让用户觉得你在故意恶心人。

避坑指南：我曾经把一个产品的「导出Excel」功能放在专业版，结果基础版用户天天骂。后来我想通了——导出是基础操作，不是增值功能。增值功能应该是「导出带格式的定制报表」。

用户量分层，就是按「能用这个产品的人数」来定价。5人以下免费，10人以下99块，50人以下499块，以此类推。

这种模型的好处是——客户自己就能算清楚账。不需要纠结功能，只需要数人头。

设计原则也很直白：用户量阶梯的「斜率」要合理。什么意思？就是每增加一个用户，边际价格应该是递减的。

你看，人均成本随着规模增加而下降。这符合客户的预期——人多了，单价就该便宜点。

我个人习惯在用户量分层里加一个「弹性上限」。比如20人套餐，允许你偶尔超到25人，不额外收费。但连续超3个月，自动升级。这样既给了用户缓冲，又不会流失客户。

使用量分层，就是按「你用了多少资源」来定价。比如API调用次数、存储空间、短信发送条数。

这种模型的设计原则是：找到「用量拐点」。什么意思？就是找出大多数用户的使用量分布，然后在分布密集区设置价格阶梯。

我记得做过一个云存储产品。一开始我们按每GB 0.1元定价，结果发现大部分用户只用10-50GB。于是我们设了三档：10GB免费、50GB 9.9元、200GB 29.9元。转化率直接翻了一倍。

小技巧：使用量分层一定要给「预警机制」。我曾经有个客户，一个月用了超出套餐10倍的API调用量，月底收到账单直接炸了。后来我们加了用量提醒和自动限流选项，投诉率降了80%。

这里要注意一个心理效应——「沉没成本厌恶」。用户一旦买了某个用量套餐，就会尽量把用量用完。所以你的套餐设计要留有余量，让用户觉得「赚到了」，而不是「刚好够」。

混合分层，就是把上面几种模型组合起来。比如：功能分层 + 用户量分层，或者功能分层 + 使用量分层。

设计原则只有一条：不要让用户做选择题。你想想看，如果一张定价表上有功能、用户量、使用量三个维度，客户得算半天才能决定买哪个。这太反人类了。

我建议的做法是：以其中一个维度为主，其他维度为辅。

举个例子。我设计过一个CRM产品，主维度是功能分层（基础版、专业版、企业版），辅维度是用户量（每个功能层下再分5人、20人、100人三档）。这样客户先选功能，再选人数，决策路径清晰。

混合分层的黄金法则：主维度不超过3个选项，辅维度不超过3个选项。超过9种组合，客户就会陷入「选择瘫痪」。

还有一种混合方式我特别推荐——「功能分层 + 使用量封顶」。比如专业版每月可处理1000条数据，超出部分按条收费。这样既保证了基础收入，又不会限制重度用户的使用。

做分层定价这么多年，我总结了几条铁律，分享给你：

免费版要「够用但不够爽」。够用才能留住用户，不够爽才能推动升级。我见过太多产品免费版做得太好，结果没人付费了。
相邻层级的价差要在2-3倍之间。价差太小，用户没动力升级；价差太大，用户直接跳过低档。
最高层不要设价格上限。企业版可以写「联系我们」，给大客户定制空间。我有个产品，企业版标价9999元，结果一个大客户直接说「太便宜了，我们想要更贵的方案」。
每年至少调整一次定价。市场在变，客户在变，你的定价也得跟着变。我习惯每年Q1做一次定价复盘，看看各层的转化率和流失率。

最后提醒一句：定价模型不是一成不变的。我见过最成功的SaaS公司，每半年就会微调一次定价。别怕改，就怕不改。

好了，分层定价的核心内容就这些。下一章咱们聊聊「免费增值模式」——什么时候该免费，什么时候该收费，这里面的学问比你想的要多得多。