摘要

  • Atlassian 的官方示例把一项 Confluence 应用的计费人数从25人改为100人，触发点是迁入同站拥有100名 Jira 用户的 Teamwork Collection。
  • Collection 对内置产品按独立用户去重；Marketplace 应用仍按自身许可和关联范围收费。同一项打包采购可以同时减少一种重复、扩大另一项计费基数。
  • Enterprise 的单实例与多实例安排，以及 Forge 文档中的按授权用户计费设计，划的是不同边界。人数、许可方式和实际报价要放在一起比较。

25个人用的工具，搬一次家，账单上就能住进100个人。这个算例出自 Atlassian 自己的Marketplace 应用计费说明：原来有25名用户的 Confluence Cloud 安装了一款应用；把该订阅迁入同一站点拥有100名 Jira 用户的 Teamwork Collection 后，这款应用改按100人的价格收费。

变化发生在采购边界。文档没有要求先证明那75个人突然爱上了这款工具，也没有把一次新的功能培训列为收费条件。原来的小范围订阅进入更大的组合，计费人口随之扩大。

25到100，人数变成四倍。金额要看具体应用的价目、阶梯和折扣，官方算例没有给出四倍账单。这个区别反而让问题更值得问：在讨论套餐省了多少钱以前，采购有没有把随行应用的新报价放上桌？

一张账单里，可以同时发生两种相反的事

Collection 的卖点很容易理解。根据套餐计费文档，用户只要能访问一个内置应用，就计入独立付费用户；同一个人使用多个内置应用，只计一次。Jira、Confluence、Loom 等纳入 Teamwork Collection 的产品在发票上汇成一项套餐订阅。

对一个原本横跨多款产品的员工而言，这是一种有吸引力的整理方式。公司不必把每个产品中的同一个人当成全新的采购对象。采购表变短，产品组合也更容易解释。

Marketplace 应用有自己的许可关系。Atlassian 在同一份文档里提醒，已经安装的应用和附加组件移入 Collection，价格可能发生变化，具体取决于其许可及与宿主产品的关联。于是，“内置产品里同一个人只算一次”与“小工具跟着更大的人群计费”可以同时成立。

这两件事分别回答不同的问题。前者清理套餐内部的重复身份，后者决定外接应用向哪一组用户出售使用资格。把前者的节省直接延伸到后者，等于用一张更整齐的发票代替完整的成本比较。

对负责部门预算的人，最难解释的往往不是涨了某个单价，而是人数从哪里来。原来批准的是一个小团队的工具，后来接入了公司的大套餐。功能仍在原来的地方，商业范围已经扩到隔壁。软件的邻居，也能参与决定它的账单。

没打开工具的人，也可能在许可范围里

Atlassian 的Forge 计费模型说明把标准模式说得直接：按宿主实例的全部用户收费，无论其中多少人实际使用 Marketplace 应用。

文档用一个500人 Jira 实例举例，其中只有50人实际使用应用。若示例中的单价为每人每月2美元，标准模式收取的是500人的1000美元。这里的2美元和1000美元都是官方教学算例，并非某款应用今天的报价。算例要展示的是，收费人群可以大于活跃使用人群。

这让专用工具面临一道特殊的采购门槛。一个团队可能只想改善自己的文档、报告或工作流程，供应商出售的却是整个宿主实例的许可范围。团队越小，它越难只靠自己的受益解释全部支出。

组织把更多员工放进同一协作环境，通常是为了共享信息、统一管理、减少分散系统。按宿主人群收费的应用，则会把这个统一环境变成自己的商业边界。管理上的集中与工具采购的便宜，需要分别算账。

Jira 应用还有一个容易看错的口径。官方用同站100名 Jira 用户和80名 Jira Service Management 坐席举例，应用取较大的100人档，而非两者相加成180人。如果停用100人的 Jira 订阅，从下一计费周期起，应用按剩余80人的价格收费。站点里有哪些宿主产品、各自的人数和变化生效时间，都会进入答案。

这里值得追踪的是应用依附的产品范围。只问“这个月有多少人点过它”，会漏掉真正写在许可里的计费对象。

公司很大，应用未必必须跟着每个人走

Enterprise 把选择推进到实例层面。Atlassian 的Enterprise 账单说明给出另一组明确的示例：Acme 有8000名 Jira Enterprise 用户，分别在5000人和3000人的两个实例中。应用装在5000人的实例上，其单实例账单按5000人计，而非自动按全公司的8000人计。

这意味着安装位置具有商业含义。一款专供某个团队使用的应用，放在哪个实例里，可能决定它面对哪一档人数。实例既是管理安排，也可能成为采购单位。

但把所有工具都拆成独立实例，也有自己的工作量。谁维护配置，谁处理跨团队协作，谁让用户在不同环境里找到资料？这些任务需要进入比较。仅仅把应用账单缩小，就宣布整个系统更便宜，会把维护成本留在另一张表上。

Atlassian 另有多实例应用计费说明，针对 Cloud Enterprise 的 Jira 或 Confluence，把多个实例放进一项组织级 Marketplace 应用订阅，按跨实例的独立用户及订阅开始时选择的用户档位计费。同一个人访问多个实例时只计一次；购买订阅后，各实例仍需安装应用才能使用。

这里去掉的是跨实例重复。它与“只向一个实例里真正获授权的一小群人收费”是两种安排。一个处理人在多个环境里重复出现，另一个处理大环境里只有部分人需要某款工具。采购必须知道自己解决的是哪一种浪费。

支持文档还用未来时描述所有应用将提供多实例计费。具体购买仍要以目标应用可用的许可选项为准。组织级订阅、实例级安装和用户级权限，名字可以相近，能买到的东西却要逐项对应。

小团队单独付费的门，钥匙也在供应商手里

Forge 的按用户计费设计，正是针对宿主人群与应用人群之间的距离。Atlassian 的采用指南描述了由管理员选择哪些用户获得应用访问资格，再按这些获授权用户收费的模式。计费依据仍是被授予的资格，活跃点击次数是另一项指标。

截至本次查阅，开发者文档把这一功能标为 EAP，说明开发者可在非生产环境中构建、部署和测试，并把 Marketplace 上架、定价设置、版本修订和审批列为后续更新。指南同时写有发布应用和生产迁移的前提条款；当前买家需要核对具体应用已经启用的计费模式，不能只凭一个功能说明给预算减人数。

文档中的设计条件很有商业意味：由合作伙伴选择是否采用，切换时可以调整价格，既有客户随应用的模式迁移。支持对象是 Forge 应用，Connect 应用需要先迁入 Forge。买家想缩小付费人群，供应商仍要决定出售什么范围、用什么价格出售。

因此，较少的收费用户与较低的总支出之间，还隔着供应商报价。一个面向小团队的专用工具可以因此更容易被尝试；供应商也可以重新定价，以补偿人数缩小。许可变细，谈判不会自动消失。

要确定某个客户的金额或迁移节省，缺的是该应用当前的许可模式、所选人数档和正式报价。官方记录已经足够把采购问题问准：套餐买完之后，原来那些应用各自开始数谁？

一项组合可以让产品配合得更好，也可以让账单里的人群重新排列。对采购而言，真正的打包完成，是内置产品和随行工具都按新边界报过价。否则，25个人的小工具只是换了个更大的房东。