按人头还是按干活：企业软件计费模式对比

一、对比背景：为什么现在必须重新算这笔账

设想一个典型场景：某制造集团的年度软件续约账单上，多出了一行“AI能力包”的价目；但业务线负责人反馈，团队日常调用AI完成的工作，走的是另一个入口。钱花出去了，使用行为却不在采购的那个入口上。

这不是个例，而是一种结构性错位的缩影。一组公开数据可以说明这种张力：某头部企业软件厂商单季营收首次突破百亿级别，云业务积压订单同步走高；但同一时期来自用户组织的调查显示，其AI能力真正进入生产环境的客户比例仅为个位数百分比，而在已经用上AI的企业中，多数使用的是该厂商之外的方案。

一边是营收创新高，一边是采用率贴地。这组反差指向的并非某一家厂商的产品问题，而是企业软件正在经历的底层变化：计费地基正在从“按人头”转向“按干活”。

本文对比的两类对象是：

• 席位制计费（按人头）：以用户数量为计费单位，典型形态是“单价 × 席位数”。
• 用量制计费（按干活）：以实际消耗的计算量、调用次数、任务完成量或资源占用为计费单位。

需要说明的是，现实中大量产品采用混合模式，但为了看清差异，本文先按两种“纯形态”展开，再讨论混合与迁移。

二、对象定义：两种计费逻辑分别解决什么问题

席位制计费的核心假设是：软件的价值由“有多少人坐在屏幕前使用它”来衡量。它的收入模型与客户的组织规模正相关——员工越多、铺得越广，账单越高。因此厂商的产品打磨重点会放在界面、表单、仪表盘这些“人每天盯着的地方”。

用量制计费的核心假设是：软件的价值由“实际完成了多少工作”来衡量。它的收入模型与客户的业务流量、任务量、数据吞吐相关，而与坐席数量弱相关。厂商的产品打磨重点会转向接口稳定性、任务调度效率、资源弹性与可观测性。

两者的分野，本质上是“人”作为计量单位，还是“活”作为计量单位。

三、相同点：它们都在解决同一类问题

尽管计费逻辑不同，两类模式在以下几点上是一致的：

1. 目标一致：都是把软件能力的价值转化为可计量的费用，让买方能预算、卖方能回收投入。
2. 依赖同一套基础设施：身份认证、权限控制、审计日志、监控告警，这些能力在两类模式下都必不可少。
3. 都面临“价值归因”难题：席位制下，闲置席位算不算浪费，长期存在争议；用量制下，一次任务到底该记多少量，同样需要约定计量口径。
4. 都需要可预测性：买方希望账单可预期，卖方希望收入可预期。差别在于，席位制用“人数”提供确定性，用量制用“配额+阶梯”提供确定性。

四、核心差异分析

4.1 成本结构

维度	席位制	用量制
计费单位	用户数 × 单价	调用量/任务量/资源时长
成本随规模变化	跟员工数走	跟业务量走
闲置成本	高（买了不用也付费）	低（不用不产生费用）
峰值成本	平稳	可能出现尖峰账单
预算可预测性	高	中，需配合配额管理

一个零售企业的仓库系统是典型例子：按门店人数买席位，实际天天使用的只有仓库主管，其余席位常年闲置，费用照付。这就是席位制的结构性浪费——它把“组织规模”当成了“使用强度”的代理变量，两者经常不匹配。

用量制则相反：不调用不收费，但一旦业务量突增，账单可能非线性上升。因此用量制几乎必然需要配套配额、限流、预算告警等治理手段。

4.2 技术架构与接入方式

席位制产品的接入，通常是“开账号—配权限—登录界面”。集成成本集中在单点登录、组织架构同步、角色映射上。

用量制产品的接入，核心是接口与凭证管理：如何签发和轮换密钥、如何做调用鉴权、如何对任务做幂等与重试、如何采集用量并上报计量系统。这意味着：

• 开发改造量更大，需要把业务逻辑接到接口层；
• 可观测性要求更高，否则账单和实际行为对不上；
• 需要一套“用量归属”机制，把消耗归到正确的团队或项目上。

# 示意性伪代码：用量制下的调用与计量上报
def invoke_task(payload, tenant_id, project_id):
    check_quota(tenant_id, project_id)      # 配额校验
    result = call_service(payload)           # 调用能力
    report_usage(tenant_id, project_id,      # 计量上报
                 units=result.units,
                 task_type=payload.type)
    return result

4.3 适用场景

更适合席位制的场景：

• 使用人群固定、日常高频操作界面类工具；
• 协作类、流程审批类应用，价值与“多少人参与”强相关；
• 预算周期固定、需要强可预测性的组织。

更适合用量制的场景：

• 能力以接口形式被系统调用，人并不直接“坐”在里面；
• 任务量波动大、有明显的波峰波谷；
• AI推理、批处理、数据加工这类“干完就结束”的工作负载；
• 需要按项目、按租户做成本归集的场景。

4.4 使用边界与风险

席位制的边界在于：当实际使用者远少于购买席位数时，价值感知会迅速下降，续约谈判会变难。

用量制的边界在于：当计量口径不透明、或缺少配额治理时，容易出现“账单惊吓”和内部扯皮。此外，用量制对财务、采购、工程三方协同的要求更高——谁消耗、谁买单，必须在系统层面可追溯。

五、对比表格汇总

对比维度	席位制（按人头）	用量制（按干活）
计量单位	用户数	调用量/任务量/资源量
成本驱动因素	组织规模	业务流量
接入方式	账号+权限+界面	接口+鉴权+计量上报
开发改造量	低	中到高
预算可预测性	高	中（需配额治理）
闲置浪费	较常见	基本不存在
尖峰风险	低	需限流与告警
运维复杂度	中	中到高
成本归集粒度	按人	按项目/租户/任务
典型场景	协作、审批、操作台	AI推理、批处理、接口型能力

六、选型建议

不做绝对化推荐，给出条件化判断：

• 如果使用人群稳定、价值与参与人数强相关、且预算需要高确定性，优先沿用席位制，但要定期清理闲置席位。
• 如果能力以接口被系统调用、任务量波动明显、或需要按项目归集成本，可优先评估用量制。
• 如果两类特征并存，可采用混合模式：基础席位保底 + 超额用量计费。这也是当前较多产品的实际形态。
• 在AI类能力上，尤其需要先确认：员工的真实使用入口在哪里。如果采购的入口和实际调用入口不一致，再合理的计费模式也会失效。

七、迁移与使用注意事项

从席位制向用量制迁移，不是换一张价目表那么简单，需要评估：

1. 数据与口径：历史用量是否有记录？计量单位如何定义？跨团队如何归属？
2. 接口与权限：现有系统能否接入？密钥管理、租户隔离是否到位？
3. 稳定性与限流：是否有配额、熔断、重试机制，避免账单和故障同时发生。
4. 兼容性：新旧模式并行期间，账务、对账、报表能否对齐。
5. 组织协同：财务、采购、工程三方是否对“谁消耗谁负责”达成一致。
6. 退出成本：一旦切换，回退路径是否清晰，历史数据能否保留。

八、总结

回到最初的问题：当软件开始按“干活”收钱，原来签的合同还作数吗？

答案是：合同仍然作数，但计量的锚点在移动。席位制把价值锚定在“人”，用量制把价值锚定“活”。两者并非替代关系，而是适配不同工作负载的两种度量方式。真正的风险不在于选错模式，而在于采购的入口与实际使用行为脱节——那才是账单对不上号的根源。

对预算负责人和数字化决策者而言，可操作的结论是：先摸清真实使用行为，再决定用哪种计费模式；对已经采购的AI能力，优先核对“谁在用、从哪个入口用、用量归到哪里”。把这三件事对齐，比争论哪种模式更先进更有意义。