SaaS 按用户收费和按功能收费有什么区别，哪种模式更适合企业软件

企业购买SaaS软件时，经常会遇到两种最常见的报价方式：按照用户数量收费，或者按照功能模块收费。前者看起来简单，例如每个用户每月支付一定费用；后者则把CRM、财务、项目管理、数据分析、AI等能力拆成不同套餐。很多企业因此会问，究竟哪一种模式更适合企业软件？

真正决定定价模式的，并不是软件采用什么编程语言，也不是系统有没有微服务，而是客户究竟为什么愿意付钱。一个好的SaaS定价模型，本质上是在寻找一个能够代表客户获得价值、同时又能够让软件公司覆盖成本并持续增长的计量单位。

按用户收费最容易理解。企业购买软件时，根据员工数量、活跃用户数量或者某种授权席位数量付费。例如一家拥有50名销售人员的公司购买CRM系统，可以按照50个席位订阅。企业规模扩大到100名销售人员，软件费用也随之增加。这种模式最大的优点是简单、透明，而且采购部门很容易预测预算。

对于协作办公、CRM、项目管理、客服、设计协作等软件，用户数量往往与产品价值存在比较直接的关系。一个公司拥有更多员工，就意味着更多人需要登录系统、创建任务、处理客户或者使用协作功能。因此“每用户每月多少钱”非常容易理解，也非常适合销售人员报价。

但是按用户收费存在一个天然问题：软件公司收的钱和客户实际获得的价值未必完全同步。假设一个企业购买了100个席位，其中只有60个人每天真正使用软件，那么客户可能会开始质疑另外40个席位为什么也要付钱。企业为了控制成本，还可能出现共享账号、限制账号数量或者故意不给部分员工开通权限的情况。

这也是SaaS行业逐渐出现“活跃用户”“编辑者”“只读用户”等不同席位类型的原因。并不是所有使用者对系统产生的价值相同。让一名每天大量操作CRM的销售人员和一名一年只查看两次报表的管理人员支付完全相同的价格，未必是最合理的设计。

按功能收费解决的是另一个问题。软件公司把产品拆成不同能力，例如基础客户管理属于标准套餐，高级报表属于专业套餐，自动化工作流属于高级套餐，AI分析或者高级安全功能则作为更高等级的产品。客户根据实际需求选择功能，而不是单纯根据员工数量购买。

这种模式特别适合功能之间具有明显价值差异的企业软件。例如一家制造企业可能非常需要生产排程，却完全不需要营销自动化；一家金融公司可能高度重视审计、安全和合规功能，却不需要某些普通CRM模块。如果所有客户都必须购买完整的软件套件，很多企业会认为自己在为从来不用的功能买单。

但按功能收费同样有问题。功能边界很容易变得复杂。一个高级功能到底应该单独出售，还是属于标准套餐？某个功能被两个部门共同使用时应该怎么计算？如果软件公司不断把原本属于基础版本的功能拆出来收费，客户很容易产生一种感觉：软件升级了，价格也在不断切片。

因此，真正成熟的SaaS定价通常不会简单地在“按用户”和“按功能”之间二选一，而是寻找一个能够长期成立的价值单位。

这里还要区分“功能收费”和“用量收费”。很多现代SaaS实际上采用的是第三种思路，例如按照API调用次数、存储容量、处理数据量、发送邮件数量、自动化任务数量或者AI token使用量收费。这种模式的共同特点是客户使用得越多，软件公司的基础设施成本往往也越高。

对于AI SaaS尤其如此。如果一个企业每天处理100万token，另一个企业每天处理10亿token，让两个客户支付完全相同的固定月费，软件公司可能很难长期维持利润。此时按照使用量收费，或者采用“基础订阅费+超额用量费”，往往比单纯按用户收费更加合理。

这背后有一个非常重要的SaaS定价原则：收费单位最好与客户获得的价值或者供应商承担的边际成本存在一定关系。

例如项目管理软件按照用户收费比较自然，因为更多员工参与项目意味着软件价值增加；云存储按照容量收费比较自然，因为存储空间本身就是产品资源；AI平台按照处理量收费也比较自然，因为模型推理会直接产生计算成本。

反过来，如果收费单位与客户价值完全脱节，定价就容易制造增长阻力。假设一家企业的软件使用人数增加一倍，但实际业务价值没有明显增加，而软件费用也跟着翻倍，客户可能会开始控制员工账号数量。软件公司本来希望客户“越成功，买得越多”，最后却变成“客户越成功，越想绕开收费”。

企业软件尤其需要考虑这一点，因为企业客户的采购方式与个人消费者不同。企业往往关心年度预算、部门扩张、合同期限、采购审批、安全合规以及未来几年成本。一个价格结构看起来便宜，但随着公司规模扩大突然变得非常昂贵，可能反而会降低客户续约意愿。

所以，企业软件定价的关键并不是“哪个模式最先进”，而是客户能不能提前理解账单，并且在业务增长时觉得价格上涨是合理的。

技术架构当然仍然重要，但它属于第二层问题。无论采用哪种定价模式，SaaS都需要可靠的租户隔离、身份认证、授权、订阅状态管理和计费系统。RBAC可以负责用户和角色权限，数据库可以保存tenant_id等租户标识，支付系统负责订阅和账单状态，但这些技术组件并不决定商业模式。一个按用户收费的软件完全可以使用单体架构，一个按功能收费的软件同样可以使用单体架构，是否采用微服务与定价方式没有直接的必然关系。

真正需要技术系统支持的是“谁可以使用什么，以及应该收多少钱”。例如客户购买专业版之后，系统需要知道哪些功能已经启用；客户取消订阅后，需要知道哪些权限应该关闭；客户增加20个席位后，需要更新授权数量；客户超过API调用额度后，则需要记录用量并进入相应计费周期。这些才是SaaS计费系统需要解决的问题。

因此，企业软件通常最适合采用分层加混合的定价结构。基础订阅提供核心功能，然后根据企业规模、用户数量或者使用量确定基本价格，再把真正具有明显增值效果的高级能力放入更高套餐或者附加模块。例如基础CRM可以包含客户和销售管理，高级套餐增加自动化、预测分析和更强的权限管理，AI功能则可以按照一定额度包含在套餐中，超过额度之后再按照使用量收费。

这种设计的好处是同时解决三个问题。客户一开始可以用相对简单的价格进入系统；企业扩大规模时，SaaS厂商能够随着价值增长获得更多收入；而计算成本特别高的功能又可以通过用量计费避免供应商承担无限增长的基础设施成本。

对于企业采购者来说，判断一个SaaS报价是否合理，也不应该只看“每用户多少钱”。更应该计算实际使用成本，包括需要购买多少席位、多少员工是真正的活跃用户、高级功能是不是强制购买、API和存储有没有额外费用、年度合同是否自动涨价、取消席位是否立即减少费用，以及数据导出和退出平台是否存在额外成本。

对于SaaS公司来说，最危险的定价方式之一就是完全从竞争对手那里复制价格表。别人按用户收费，并不意味着你的产品也应该按用户收费。你的客户可能真正购买的是自动处理的订单数量、节省的人工时间、分析的数据规模或者产生的交易价值。如果找错了计量单位，即使产品非常优秀，也可能出现客户增长越快、销售阻力越大的情况。

因此，按用户收费并没有天然优于按功能收费。对于用户参与程度高、价值与团队规模关系密切的协作型软件，按用户收费通常更加直观；对于模块差异明显、不同企业需求高度分化的企业软件，按功能或分层套餐更加合适；对于AI、API、云计算以及数据处理类产品，用量计费往往更加符合成本结构。

最终最成熟的SaaS模式，往往是把这几种方法组合起来，而不是执着于其中一种。基础订阅解决稳定收入，用户数量解决组织规模，功能套餐体现产品价值，用量收费覆盖高边际成本。价格表看起来可能比“一人每月多少钱”复杂一点，但只要客户能够清楚地理解自己为什么付钱，这种复杂其实是有价值的。

好的SaaS定价不是尽可能从客户身上收取更多费用，而是让客户的收入、效率或者业务能力增长之后，软件供应商也能够合理分享其中一部分价值。客户赚钱越多，软件公司收入增加；客户规模扩大，系统自然扩容；客户使用昂贵的计算资源越多，支付相应的成本。能够形成这种正向关系的定价模型，才真正适合长期发展的企业软件。