按次上门 IT 计费对比月度服务费：怎么比才对

简短答案： 一份按次计费的报价和一份月度服务费报价，照原样是没法比的，因为它们根本不在同一条轴上定价。按次计费给一个*事件*定价，月度服务费给*可用性*定价。先按你真实的工单量把两者都换算成"每月多少钱"，再单独去看那三项从不出现在任何一个数字里的风险。

两份报价，两种计价单位，没法直接比

财务或采购负责人手上最后会拿着两张纸。一张写着类似"上门首小时 98 美元、之后每小时 78 美元"，另一张写着类似"每用户每月 1,247.40 港元"。两家服务商都靠谱，两份报价都诚实。而这两页纸上，没有任何一条算式能把其中一个换算成另一个。

这不是套路，两家也都没有藏东西。这两份文件卖的是不同的单位。第一份卖的是事件：东西坏了，有人来，你为他在场的时间付钱。第二份卖的是可用性：一项服务存在着、有人在岗、有人在盯，这个月你用得多还是完全没用，价钱一样。

照原样去比，会产生一个可预测的错误。小时报价在你读它的那天总是显得更便宜，因为那天这个数字是零。月度服务费总是显得贵，因为什么都还没发生，数字就已经不是零了。按这个印象采购的财务团队，往往在十八个月后才发现真实成本——出现在一条他们解释不了的同比差异里。

修正方法并不复杂：把两者放到同一条轴上——按你真实用量算出的每月成本——然后再单独去看那两个数字都不包含的三件事。

按次计费实际是怎么走的

按次计费有一个"形状"，而这个形状比标价更重要。

首小时比之后的小时贵。2026 年 9 月 22 日从 Brocent 的派遣与上门费率页读取：香港为首小时 98 美元、之后每小时 78 美元；新加坡 85 与 78 美元；中国内地 65 与 59 美元。口径行本身就是价格的一部分：L1 终端用户计算支持、次个工作日、标准 9×5，2026 年下半年指示性数字，美元，不含税，市中心，高用量下会下降，且为全包——这里的全包意味着费率已经吸收了生活成本、双语工程师、培训、汇率与税务处理、账期融资和 24×7 协调，而不是事后再加几行费用。

首小时定价更高的原因不是毛利，而是交通、排程、工程师在你这单前后损失的时段，以及"出一趟门"这件事本身的固定成本。由此引出本文最重要的一句话：二十分钟的活儿，从来不是按二十分钟收费的。 它是一个首小时。在预付 Token 模式下，Token 服务对工作时间内的上门按 2 个 Token 起扣，那它就是两小时。在任何地方的任何按事件计费模式下，它都是一个起步量。

这个事实悄悄地摧毁了大多数天真的比较。一个有大量零碎、频繁、必须到现场的问题的站点，是按次计费最糟糕的适配对象，因为几乎每一笔收费都是起步收费，每一分钟有效工作的平均成本高得惊人。而一个偶尔有整块工作的站点——半天布线、一个上午的新员工装机——是最好的适配对象，因为昂贵的首小时被摊进了一次长时间上门里。

所以：不要只数你有多少次上门，要看你的上门长什么样。

香港一次四小时上门：98 美元加三小时各 78 美元，合计 332 美元，平均每小时 83 美元。
同一个月里四次各一小时的独立上门：合计 392 美元，平均每小时 98 美元。

同样是四小时的工程师工时，差了百分之十八，完全取决于这些活儿是攒着来的还是散着来的。

任何按次计费的合同里还有两条机制值得读，因为没算进模型的成本就藏在那儿。交通对市区以外的站点往往单独加载——按公开的 Token 计费规则，远端站点 30 公里以内加 1 个 Token、30 到 50 公里加 2 个，每次上门最多加 2 个。非工作时间有倍率：同一套公开规则规定，工作时间内上门起扣 2 个 Token，晚间 3 个，深夜或周末 4 个，公众假期 6 个。如果你的现场工作里有相当一部分落在 9×5 之外——零售、制造和贸易运营通常都是如此——那么白天的标价并不是你实际会付的价。

月度服务费实际是怎么走的

月度服务费给可用性定价，通常按每用户或每设备每月计。

在 Brocent 公开的香港按用户计划上，各档为：最小档（1–5 人）每用户每月 855.14 港元，5–300 人档 1,247.40 港元，10–500 人档 1,561.21 港元，企业档面议。因此一个三十人的香港办公室按中间档，大约是每月 37,400 港元——这个数字不会因为忙月之后接了个淡月就变动。

它买到的是一项常设职能，而不是若干次上门：服务台及其覆盖时段、补丁、终端安全、身份管理、备份及其验证、监控、文档，以及一条明确的升级路径。区别在于"有人可以打电话找"和"已经有人在盯着"。

决定月度服务费值不值的有两件事，而且两件都是合同问题，不是数字问题。

什么在范围内、什么在范围外。 月度服务费不是无限量的。要读清"覆盖"和"项目性工作"之间的边界：迁移、办公室搬迁、新站点建设、硬件采购和非工作时间工作，通常不在按用户费用里，需要另行报价。这本身是合理的，但必须在签约前就看得见，而不是在第四个月才发现。

超量怎么办。 对月度服务费服务商该问的诚实问题是：当消耗远超定价时的假设，会发生什么？好的回答会描述一种机制——合理使用边界、复核触发条件、超额上门小时的费率。糟糕的回答是"我们其实不怎么统计"，那意味着要么价格里已经假设了低用量，要么以后会有一次不太愉快的谈话。

把两者放到同一条轴上

方法如下。它要花一个下午，但比任何供应商对比表都值钱。

第一步：数事件，不要数工单。 拉出十二个月的历史，把真正需要人到现场的条目挑出来。大多数组织会发现这只占工单总量的一小部分，而这个数字往往出乎他们意料。

第二步：算出形状。 对每一个现场事件，记下大致耗时，以及它能不能等一周。现在你知道了每月上门次数、平均上门时长，以及最关键的一点——你的工作里有多大比例是可以攒着处理的。

第三步：给"按次"这一列定价。 按你所在市场的公开费率算出来，用"首小时加后续小时"的算式，而不是用一个平均值。市区以外的站点加上交通加载。落在 9×5 之外的那部分加上非工作时间倍率。得到的是一个月度数字。

第四步：给"月度服务费"这一列定价。 每用户费率乘以人数，再加上你在读范围时发现被排除、但你确实需要的项目。

第五步——也是所有人都会跳过的一步：注意"按次"那一列里缺了什么。 月度服务费那个数字里包含补丁、监控、备份验证、身份管理和一个服务台。按次那个数字里一样都没有。如果你直接拿两者相比，你是在拿一项完整服务去比它的一个子集，而按次那一列会赢下一场它其实没有参加的比赛。

认真做完第五步，通常会把整个问题重新框定。真正的比较几乎从来不是"按次还是月度服务费"，而是"只要月度服务费"对比"月度服务费再加一层按次或预付安排来覆盖现场"——那是一个关于怎么覆盖"手"的问题，而不是要不要买服务的问题。

按次派遣 vs 预付小时包 vs 月度服务费

按次派遣——采购单位： 一次上门。它保证什么： 由你购买的 SLA 档位决定的响应——公开档位从 P1 首次响应 2 小时、次个工作日到场，到 1 小时、当天到场，再到 24×7 紧急档的 15 分钟、4 小时到场。它怎么失效： 频次。每一件小事都要付起步价，而且没有人在积累对你站点的了解。工作完成后开票，按工单逐条列明，标准 30 天账期。
预付小时包——采购单位： 一包 Token，1 个 Token 等于 1 小时上门或远程工作，包规格为 20、50、100 或 250。它保证什么： 事先锁定的费率，以及一个十二个月内不失效的余额，每个合同年还有一次友好延期。有效小时单价就是包价除以 Token 数，所以包越大每小时越便宜——香港的公开包算下来大约是 20 个 Token 每小时 391 港元、50 个约 348 港元、100 个约 304 港元。它怎么失效： 起扣量依然存在——工作时间内上门 2 个 Token，晚间、周末和公众假期更多——而且为忙碌的一年买下的余额，在清闲的一年就变成了沉没成本。
月度服务费——采购单位： 每用户（或每设备）每月。它保证什么： 一项常设服务——服务台、补丁、安全、身份、备份、监控、文档、升级——不论你有没有打电话，它都有人在岗。它怎么失效： 范围漂移和低使用率。一个确实几乎没有 IT 需求的组织买月度服务费，那是一份很贵的保险；而一个需求很多的组织买它，它是这份清单上按单位工作量算最便宜的东西。

两个数字里都没有的三项风险

价格是这个决策里容易的部分。有三项风险落在两份报价之外，而实践中它们决定的结果比算术还多。

响应时间风险。 按次模式按你买的档位响应；如果你买的是最便宜那档，承诺就是"次个工作日"，而在周五下午，那意味着周一。月度服务费通常带一套明确的优先级框架，按严重程度规定响应和解决目标。如果一次四小时的中断给你造成的损失确实超过一个月的服务费，那么便宜的那个模式才是贵的那个。我们关于 SLA 优先级的指南说明了 P1 到 P4 的目标通常是怎么定义和度量的。

可用性风险。 按次服务商是按队列分配工程师的，你没有被预留。在真正忙的一周——区域性故障那一周，或者春节前那一周——没有预留的买家要排在有预留的买家后面。月度服务费在其他意义之外，也是一份对产能的请求权。这是月费买到的真实一部分，而它在费率表上是看不见的。

知识风险。 这一项是静悄悄复利的，从三年的跨度看也是三者中最贵的。在按次计费下，来的是当时有空的那个人。他每次上门都要先花一段时间重新认识你的环境——弱电井在哪、Wi-Fi 叫什么、哪台交换机供会议室、那台服务器为什么没加域。这段"重新认识"你每次都要付钱，按首小时费率付，而且它不会积累成任何东西。有长期服务关系的服务商会建立配置记录和运维手册，于是第十二次上门不是第一次上门的重复。如果你的环境有任何非标准之处，这通常是决定性的论据。

按次什么时候确实是对的——又是什么时候悄悄不再对

按次是正确选择的情况，比卖月度服务费的服务商愿意承认的要多。它适合只有少数几个用户、没有机房的卫星站点；适合真实支持负载绝大部分是远程、现场只是涓涓细流的办公室；适合需求确实不可预测且量低的情况，因为你只在高峰真的发生时付钱。它还适合当作一件*测量仪器*：六个月按工单列明的按次账单，是任何人能交给你的最好的定尺寸数据，因为它记录的是真实发生了什么，而不是谁估算了什么。

它不再正确，是在三件事同时发生的时候——而它们往往一起到来。用量从忽高忽低变成稳定；活儿变小，于是几乎每一笔收费都是起步价；环境长大到"每次上门重新认识环境的时间"开始盖过实际工作。到那个时候，按次账单仍然是一小笔一小笔地来，所以没有人察觉，但年度总额已经悄悄超过了月度服务费本来会花的钱——而且组织手上什么都没留下：没有文档、没有监控、没有补丁基线、没有一个了解这个地方的人。

实用的检验方法是：把十二个月的按次账单加总，再除以十二。大多数组织从来没做过，因为这些账单是分开来的、也是分开批的。做一次，通常就有结论了。

几乎所有人最后落到的混合形态

这两个模式在实践中不是竞争关系，因为它们覆盖的是不同的层。

月度服务费覆盖远程层：服务台、补丁、安全态势、身份管理、备份及其验证、监控，以及那份让之后每一次上门都变短的文档。这一层本身也是让现场那堆工作变小的原因——一套补丁打得好、监控做得好的环境，产生的需要动手的事件本来就更少。

按次或预付安排覆盖"手"这一层：必须发生在房间里的那些事。按工单历史而不是拍脑袋来定尺寸，这一层通常比组织在数之前预期的小得多。

按这个顺序买。先买远程层，因为它决定现场层需要多大；再买现场层，按剩下的量定尺寸。只买了"手"这一层的组织，最后会顺手把远程层重新拼起来——这边一个备份工具、那边一个杀毒订阅、某处一张存密码的表格——并且为一个更差的版本付了更多的钱。

Brocent 把这笔账两边的输入值都公开了：按次与专属工程师费率在派遣与上门费率页，预付包及其计费规则在 Token 服务页，按用户计划在价格页。一起读的时候请注意一点：上门派遣是以美元报价的，而 Token 包和按用户计划是以本地货币报价的。在没有先固定上门形状、覆盖时段和 SLA 之前，两者不能直接换算成同口径的小时单价——所以请在同一个模式内部比价，并让上面那套方法、而不是一次汇率换算，来决定模式之间怎么选。

常见问题

为什么首小时更贵？

因为"出一趟门"有一笔跟活儿长短无关的固定成本：交通、排程，以及你这次上门前后损失掉的时段。首小时把它吸收掉了，后续小时没有，所以后续小时费率更低。实际后果是：把工作攒成更少、更长的几次上门，比散成很多次短上门明显更便宜。

交通费另算吗？

取决于站点在哪。市区范围内，交通通常已包含在首小时费率里；市区以外通常有加载——按公开的预付 Token 规则，30 公里以内的站点加 1 个 Token，30 到 50 公里加 2 个，每次上门最多 2 个。请针对你的具体地址问清边界在哪，不要默认。

合理的最低采购量是多少？

预付包方面，公开的首次最低采购量是每个服务区 20 个 Token，这也是最小的包。按次派遣完全没有月度最低消费，可以只买一次上门。真正要盯的是*每次上门*的起扣量：工作时间内上门至少 2 个 Token，晚间、周末或公众假期更多。

月度服务费里没用完的小时能结转吗？

按用户的月度服务费通常并不包含可以结转的"小时"——它买的是一项常设服务，不是一个数量。预付包才是带余额的模式，那里相关的条款是有效期：公开的 Token 自购买起有效 12 个月，每个合同年可通过客户经理申请一次友好延期。如果某家服务商在月度服务费里提供可结转小时，请仔细读续约时它们会怎么处理。

超出小时包之后怎么办？

续购，而要事先谈定的问题是续购时按什么费率。包越大有效小时单价越低——包价除以 Token 数——所以年中以小包形式续购，每小时比最初那次采购更贵。如果你的消耗趋势高于计划，通常升一档包规格比不断买小包更划算。

哪一种模式才有真正的 SLA？

两种都可以有，只是表达方式不同。按次的 SLA 是作为一个档位买下来的，管的是响应和到场——公开档位从 P1 首次响应 2 小时、次个工作日到场，到 24×7 紧急档的 15 分钟、4 小时到场。月度服务费的 SLA 通常表达为一套按严重程度规定响应和解决目标的优先级框架。对任何一家该问的问题都不是"你们有没有 SLA"，而是"没达到的时候，合同上会发生什么"。

两个站点的话哪种更便宜？

通常是月度服务费，而且距离越远差距越大。在按次计费下，两个站点会让交通暴露翻倍；如果其中任何一个在市区以外，那么每一次上门都会被加载。而按用户定价的月度服务费，并不在乎这个用户坐在哪栋楼里。例外是那种确实很小的第二站点——几个用户、没有基础设施——这种往往最适合在覆盖主办公室的月度服务费之上，叠加派遣或预付小时来覆盖。

明年的支出怎么预测？

在月度服务费下，预测人数即可，成本几乎线性跟随——这也是财务团队喜欢它的原因。在按次下，要预测事件数，而且要记住事件数并不跟随人数，它跟随的是*变化*。办公室搬迁、成批入职、硬件更新、新站点，都会在人数不变的情况下推高现场层。如果你的来年包含其中任何一项，请把它们显式地建进模型，而不是照去年的平均值外推。如果你希望我们帮你把自己的数字过一遍这套方法，请带上十二个月的工单历史联系我们，而不是带上人数。