如何把共同的 SaaS 成本分摊到多个产品

只经营一个产品时，大多数开支都很好理解：托管账单属于这个产品，邮件服务、支付处理和客服软件也一样。

一旦经营两个或更多产品，情况就没那么清楚了。一个设计订阅可能同时服务所有产品。同一个监控账户、AI 助手、分析服务和域名注册商，可能出现在同一张信用卡账单上，而受益的却是好几个产品。

忽略这些共同成本，会让每个产品看起来都比实际更健康；随意分摊，同样会产生误导。用一条可重复的分摊规则，并记下你为什么选择它。

如果想边读边比较几种主要方法，可以打开免费的共同成本分摊计算器。它在你的浏览器中本地运行，可以在平均、按收入和自定义分摊之间切换。

先把成本分成三类

选择分摊方法之前，先给每项支出归类：

1. 产品直接成本完全属于某一个产品。例如专用服务器、这个产品的事务性邮件、它的域名续费，以及只为它投放的广告。
2. 共同经营成本支撑多个产品。典型例子有设计工具、记账软件、共用的可观测性账户，以及全公司共用的 AI 订阅。
3. 个人或无关成本根本不应计入产品盈利。一个个人云存储套餐，不会因为和业务开支用了同一张卡，就变成业务成本。

如果把明显属于直接成本的支出放进共同成本池，一个成功的产品就可能悄悄把自己的成本转嫁给更小的产品。

定一条简单的规则：只分摊共同成本这一类，直接成本始终挂在它实际所属的产品上。

选择最简单且说得通的方法

不存在放之四海而皆准的分摊方法。有用的方法，是能反映各产品如何消耗这项成本、而且维护起来切实可行的方法。

平均分摊

把共同成本平均分给所有在运营的产品。

适用于每个产品受益大致相同的情况。当所有产品都由同一个小团队维护时，代码托管套餐或记账订阅可能就适合这种方式。

平均分摊很容易解释，但可能让一个小实验承担过多，而让一个成熟产品承担过少。

按收入分摊

按每个产品占产品组合收入的比例分摊成本。

适用于共用工具主要支撑日常经营活动、又没有更好用量指标的情况。一个贡献了 60% 收入的产品，承担 60% 的共同成本。

这种方法方便，通常也比较稳定，但收入只是用量的近似值。一个还没有收入、正在高强度开发的产品，消耗的设计和工程资源可能比成熟产品更多。

按用量分摊

用一个可衡量的依据来分摊成本，例如请求数、活跃用户、存储量、工单数或工程工时。

适用于支出和用量有明确关系的情况。如果一个监控账户覆盖三个 App，事件量可能比收入更适合作为依据。如果一位外包同时为多个产品工作，记录的工时可能更合适。

这种方法可能更准确，但收集数据本身也有成本。不要为了拆分一笔很小的月费，去搭建一套复杂的跟踪系统。

自定义比例

根据产品阶段和当前投入，有意识地设定百分比。

当产品组合里同时有成熟产品、成长中的产品和尚未上线的实验时，这种方法很有用。这些比例是管理上的判断，所以要写下选择的理由，并按固定周期复审。

一个假设的例子

假设一个虚构的产品组合有三个产品：

这个组合每月有 $180 的共用订阅费用。平均分摊时，每个产品承担 $60。

按收入分摊时，收入占比分别为 60%、30% 和 10%：

两种结果都不一定正确。如果这 $180 主要是记账和公司行政开支，按收入分摊可能是合理的。如果它是一套设计软件，而目前几乎全部用于 Sandbox 的上线，那么自定义或按用量分摊会揭示更多信息。

关键问题是：这个分摊想要反映的是什么行为？把答案写在计算旁边。

不同的成本组用不同的依据

你不需要为每一项共同支出都用同一条规则。把相似的成本归为一组，每组用一个分摊依据：

分组数量要少。独立开发者维护十二条分摊规则通常收获不大，两三组往往就足以揭示各产品之间的主要差异。

建立每月的分摊流程

一个轻量的流程可以放进每月复盘里：

1. 导出或列出当月的软件支出。
2. 把每一项直接成本挂到对应产品上。
3. 把真正共用的项目放进共同成本池。
4. 对每组共同成本应用选定的分摊依据。
5. 检查分摊后的金额加总是否等于原始合计。
6. 记录特殊项目和假设的变化。
7. 做决定之前，先和上个月的结果比较。

把年付订阅保留在它记录的扣费月份，让时间点保持可见。如果折算后的比较有帮助，把每月 $10 的平均值作为另一个分析视图展示，不要用这个平均值替换计划中的那笔 $120。

产品发生变化时，不要不断改写历史分摊。更好的做法是定一个规则，比如每季度复审一次比例，或在产品上线、关停、发生重大变化时复审。

开发 MarginDeck 时做的一个设计决定

说明：MarginDeck 是我开发的。本文介绍的是我自己在这个产品上的工作。

在开发 MarginDeck 的共同成本分摊流程时，这个问题变得很具体。我选择让修改后的比例从选定的月份开始生效，而不是悄悄改写之前的每一个月。

这个决定保留了当初做产品复盘时的背景。如果产品 A 在 3 月承担某个共用工具的 70%，而产品组合在 6 月发生了变化，那么 3 月仍然应该显示 3 月当时有效的规则，新比例只从 6 月开始适用。

同时记录分摊方法和它的生效月份。没有日期，今天改变一个假设，就可能让历史对比看起来比实际更整齐。

避免虚假的精确

分摊是一个模型，不是可以观察到的事实。像 $53.27 这样的结果看起来很权威，即使它来自一个粗略的 30% 估计。

设定一个重要性门槛。你可以仔细拆分一笔金额较大的共用基础设施账单，而把一个很小的密码管理器订阅平均分摊。这个门槛应该反映你自己产品组合的规模，而不是别人的规则。

当决定取决于这个结果时，做一次敏感性检查。如果一个产品在平均、按收入和合理的自定义分摊下都不盈利，结果对分摊方法就不太敏感。如果每换一种方法它的状态就变一次，就把结果视为不确定，并去调查背后的成本驱动因素。

分摊应该帮你做出哪些决定

一个好的共同成本模型，应该回答这些实际问题：

• 这个产品的贡献是否足以支撑产品组合？
• 如果这个产品关停，哪些订阅会消失？
• 某个小产品是真的便宜，还是有别的产品在补贴它？
• 多一美元收入，放在哪里影响最大？
• 某个共用工具应该降级、替换还是取消？

它不应该被用来为一个你已经做好的决定找理由。内部分摊也不一定和税务或财务报告的处理一致。需要正式的会计意见时，请咨询合格的专业人士。

从一张电子表格开始就够了

用行表示支出，用列表示产品。加上金额、直接还是共同、分摊依据和备注这几列。然后核对各产品列的合计是否等于原始账单。

当这件事变得繁琐时，专门的工具可以减少重复计算。说明一下：我是 Junhua，我开发了 MarginDeck，一款用来看清多个产品成本和盈利情况的产品。无论你用 MarginDeck、电子表格还是自己的系统，本文的框架都适用。