太小签不了IT合同？香港精品机构的Token故事

本文为复合情境，并非指真实客户： 一家11人的香港设计工作室，三年来一直靠"谁的表亲懂电脑"来解决IT问题——这套办法一直凑合能用，直到一台笔记本电脑在客户提案前一周彻底罢工，工作室才发现根本找不到真正了解自己系统的人可以求助。这正是按需付费、以工时点数（Token）计费的IT支持所要解决的问题：既要有延续性，又不必背上一份为更大公司量身定制的合同。

香港精品机构确实有IT需求——只是不是"标准款"需求

如果你是一家8到15人的创意机构、精品咨询公司或小型贸易办公室，去和香港的大多数托管IT服务商（MSP）谈业务，你听到的方案往往是为一家你并不是的公司准备的。标准托管IT方案按每用户每月计费，其背后的假设很明确：员工数量、设备数量、以及日常工单数量都要达到一定规模，7×24小时监控、补丁管理、托管防火墙、以及专属虚拟CIO这类固定月费服务，才能在经济上说得通。

在11人这个规模，这个假设并不成立。精品机构的IT需求是真实存在的——笔记本电脑会坏，客户通话时Wi-Fi会掉线，有人会中招钓鱼邮件，新员工入职需要尽快配好电脑——但这些需求是不规律的。可能某个月只出现三四次故障，也可能什么事都没有。如果每个月都要为按50人规模配置的7×24小时网络运维中心监控和持续端点管理支付固定的每用户费用，那这笔钱其实是在为一个11人办公室根本用不上的基础设施买单。这个规模真正需要的是：有能力、随叫随到、已经熟悉自己系统的人，而不是不管有没有出问题都在背后持续运转的订阅服务。

这不是一个假设性的空白地带。这恰恰是许多香港中小型专业与创意机构所处的真实处境——"公司太小签不了合同"和"公司太大不能再靠临时帮忙"之间的这段真空地带——而大多数IT支持营销根本没有覆盖这一块，因为标准托管服务的推销逻辑只有一个刻度（人头数 × 月费），没有为"偶尔发生、但真实存在"的需求设置对应的档位。

场景：没有固定IT合作关系，也没有制度记忆

想象一家11人的香港设计工作室——五名设计师、两名客户经理、一位身兼记账工作的办公室经理、几名初级员工，加上两位创始人。三年来，IT问题一直按小型机构常见的方式处理：先问办公室里（或者谁家里）"懂电脑"的人。如果不管用，就上网找附近的维修店，或者找一个熟人推荐的自由职业者。

大体上，这套办法一直管用。笔记本电脑最终总能修好。Wi-Fi掉线了重启一下路由器。软件许可证过期了重新装一下Office。没有一件事处理得优雅，但三年来也没有严重到逼着工作室做出改变。

直到一位资深设计师的笔记本电脑彻底罢工——不是变卡，不是偶尔死机，是真的开不了机——而距离向一位潜在客户提交提案的截止日期只剩三天。办公室经理联系了平时的那位联系人，对方正在出差；她又试了备用选项，一位一年半前帮过一次忙的自由职业者，可对方完全不记得那台电脑上装了什么，也没有工作室文件结构或软件许可证的任何记录，光是搞清楚状况就花掉了大半天，之后才能真正开始排查问题。提案文件靠着别人电脑上的部分备份重新拼凑出来，虽然完成得很晚，工作室总算勉强赶上了会议。经历过那一周之后，工作室里没有人再觉得临时拼凑的办法可以接受了。但也没有人觉得，签一份按50人规模定价的整月MSP合同就是正确的解法。

"临时拼凑IT帮忙"到底让小型机构付出了什么代价

笔记本电脑罢工只是让问题浮出水面，它本身并不是问题的核心。真正的问题在于，无论你找到的人手艺多好，临时拼凑式的IT支持在结构上永远无法提供以下几点：

每一次故障都是从零开始。 无论你联系到的是表亲、自由职业者，还是每次都不一样的维修店，对方都没有关于系统安装内容、网络配置、软件许可证、或已经尝试过哪些办法的任何记录。每一次他们都是在排查一个陌生人的系统，这意味着即使是简单的修复也会比应有的时间更长，真正复杂的问题甚至可能拖上好几天。

帮助恰恰在你最需要的时候不可用。 临时拼凑式支持意味着，谁刚好有空谁上。没有服务等级协议（SLA），没有保证的响应时间窗口，如果你平时的联系人正在出差、生病，或者干脆已经转去服务别的客户，也没有备用联系人。IT问题往往集中爆发的那些时刻——提案前一周、上线前一天——恰恰是靠人情维系的联系人最不容易联系上的时刻。

没有人为安全和备份把关。 由于没有持续的合作关系，也没有人在事故之间对工作室的IT状态负责，任何事情都不会被主动检查。备份要等到真正需要用的那一天才会被发现根本不管用。旧软件要等到它已经变成问题的突破口才会被打补丁。没有任何人的职责范围里包含"在这些问题变成紧急事件之前先注意到它们"，因为压根没有人的工作内容包括这一项。

整月MSP合同的按用户计费在这个人数规模上说不通。 临时拼凑问题的反面，未必就是标准托管IT合同——而更可能是一份为规模大出好几倍的公司设计的合同，其定价假设了这家办公室永远不会产生的工单量。为一个只有11人的工作室，按几十个端点的规模持续支付监控基础设施的月费，并不是在解决真正的问题——而是在为一个本可以用更小、体量更匹配的承诺方式独立解决的延续性问题，过度采购。

也值得说清楚，这里说的"不规律"具体指什么，因为很容易以为只要时间窗口拉得够长，小型办公室的IT问题最终会摊平成某种可预测的模式。实际上并不会，因为在这个规模上真正要命的从来不是日常琐事，而是那些罕见、破坏性强、又偏偏挑在最糟糕时机出现的事故。工作室可能真的连续六到八周什么都不出问题，然后偏偏就在客户续约到期的同一周，笔记本电脑罢工、钓鱼邮件同时来袭。把这一切摊平成"平均每月一次事故"，并不会让那些糟糕的周变得不那么棘手——而固定月费合同之所以能定出那个价格，恰恰是因为它面向一个庞大得多的客户群体来分摊这种波动性，而一个11人的工作室实际上是在为这种分摊机制买单，却远远达不到能让这笔账对自己划算的工单量。

Brocent的看法：整月合同并非永远是合适体量的承诺

对处于这个人数规模的公司来说，诚实的答案通常不是"你需要一份完整的托管IT合同，把提案做得更漂亮一点就好"。而是订阅制这种承诺形式，本身就和不规律但真实存在的IT需求不匹配——真正合适的答案是：预付、按需使用的支持工时，来自一个已经了解你环境的团队，一次性购买，只在真正出问题时才消耗。

这正是Brocent工时点数服务（Token Service）存在的意义：它解决的是这家工作室真正的问题——延续性，即有一个已经了解系统情况、能在明确响应时间窗口内联系到的团队——而不去解决一个它根本不存在的问题：11人规模根本用不上的全天候网络监控基础设施。它不是一份缩水版的托管IT方案，而是一种完全不同形态的承诺，按事情实际发生的频率来定量，而不是套用一个为大得多的办公室设计的按人头公式。

工时点数式IT支持具体是怎么运作的

它的机制刻意设计得很简单，以下每一个细节都严格对应Brocent工时点数服务的公开说明——没有任何一处是估算或猜测。

你购买的是一批预付工时，而不是订阅。 一个"Token"（工时点数）等于一小时的现场或远程IT支持。你需要为所需覆盖的区域（例如香港）预先购买一批工时点数，首次购买的最低数量为每个区域20个点数。没有月度账单，没有按用户计费，除了你已购买的这一批点数之外，没有任何持续性的承诺。

工时点数不会在月底那一刻就作废。 一批工时点数自购买之日起有效期为12个月，如果到期时还有余额，每个合同年度可以通过你的客户经理申请一次性的善意延期。你不需要每30天就赶着"用完，否则作废"，不会像订阅制那样让你感受到那种压力。

提交工单的流程和任何服务台一样。 你向Brocent的全球服务台发送请求，说明问题内容和紧急程度。在正常营业时间内，工单会按当日响应（4小时或6小时）或次日响应等级处理，具体取决于紧急程度；对于真正等不了的情况，7×24小时紧急服务等级可提供全天任意时间（包括夜间、周末和公众假期）4小时到场响应。现场服务按整小时的点数计费（营业时间内最低2个点数，非营业时间更高），远程支持按15分钟为一个计费单位，四个单位等于一个点数——这意味着一次20分钟的远程修复不会和一次两小时的现场服务花费相同的点数。

留下的是书面记录，而不只是记忆。 每一次完成的工作都会产生一份签署的服务报告，记录实际完成的内容，你还会收到每周的工时点数余额结算单，并在余额可能耗尽之前收到预警提示。这份书面记录正是临时拼凑式安排永远无法提供的东西——一段完整、有据可查的历史工单记录，让下一位处理请求的人能够真正参考，而不是从零开始摸索。

由一位客户经理，而不是一群走马灯般轮换的陌生人，来负责这段关系。 虽然Brocent不保证每一次派工都是同一位工程师本人（毕竟要在100多个国家和地区维持一个全球服务台，具体派哪位工程师取决于当时的可用性和所在地），但这段账户关系——以及背后有据可查的工单历史——正是用来取代"谁的表亲今天有空"这种模式的东西，让机构真正可以依赖。

它是诚实地按体量匹配设计的，而不是一种权宜之计。 按用户计费的整月MSP方案，其中打包了持续监控和主动管理，这在工单量足够高、足以支撑这项投入时是合理的。工时点数服务并不包含这一层——它专门面向那些IT需求真实存在、但发生频率不高的办公室，而这正是本文场景中这家工作室的写照。随着工作室规模扩大，工单量从每月几次变成每周多次，那正是固定月费方案开始比继续消耗工时点数更划算的时间点——而这是工作室可以在自己的节奏上主动做出的决定，而不是被一份不合身的合同提前逼着做出的选择。

如何开始使用

这一切都不需要一场为大得多的交易设计的冗长销售流程。处于这种情况的工作室，通常会先就工单量和紧急程度进行一次沟通——实际上多久出一次问题、其中有多少是真正的时间敏感型——从而大致确定第一批需要购买多少工时点数，然后购买香港区域最低20个点数的首批数量。这次沟通也是工作室诚实判断自己是否其实已经超出工时点数适用范围的机会——如果描述出的工单量听起来更像是每周多起，而不是每月几起，那更合适的答案可能是从一开始就考虑托管IT方案，而不是购买一批几周内就会用完的工时点数。此后，更广泛意义上的托管IT支持，以及其背后的托管服务，会一直留在那里，等到工作室的需求真正成长到那个阶段时再考虑——但从工时点数服务开始，并不意味着必须提前对那条路径做出承诺。

常见问题

这和找自由职业者帮忙有什么区别？

表面上机制看起来相似——出问题时你联系对方——但区别在于这段关系背后有什么支撑。临时找到的自由职业者对你没有持续的责任，没有工单历史记录，没有明确的响应时间承诺，如果对方联系不上也没有备用方案。工时点数服务附带明确的SLA（根据紧急程度分为当日响应或7×24小时紧急等级）、每次工作完成后的签署服务报告，以及负责这段关系的客户经理——这些都不是一次性的自由职业者合作天然能提供的。

未使用的工时点数会过期吗？

工时点数自购买之日起有效期为12个月。如果到期时你还有余额，每个合同年度可以通过客户经理申请一次性的善意延期——这不是那种时间一到就立刻"用完即作废"的硬性截止。

如果我们的需求超出了工时点数服务的适用范围会怎样？

确实存在一个真实的临界点，这是一个诚实的判断依据，而不是一个促销话术：一旦每月工单量超过大约四起，固定的按用户托管IT方案通常就会比继续消耗工时点数更划算，因为到了这个工单量，你也能从订阅方案所包含的7×24小时监控和主动管理中真正获益。低于这个工单量，工时点数通常仍是更合适、成本更低的选择。无论哪种情况，这都应该是一个数字真正支持时才做出的决定，而不是被一份合同提前锁定的选择。

工时点数能覆盖紧急的当日问题吗？

可以。在正常营业时间内，可提供当日响应（4小时或6小时，取决于工单类型）；对于任何等不到营业时间的情况，7×24小时紧急等级可提供全天任意时间的4小时到场响应，包括夜间、周末和公众假期。紧急和非营业时间的服务确实会比常规营业时间工单更快消耗工时点数（点数的每小时计费标准在夜间、周末和公众假期会更高），如果紧急问题对你的业务来说是真实存在的可能性，这一点值得在决定首次购买多少工时点数时纳入考虑。

有最低购买数量吗？

有——在任何区域的首次购买，最低数量为20个工时点数。这不是什么隐藏门槛，而是公开说明在先的规则，相比一整年的按用户MSP月费，这仍然是一笔相当小的承诺。首批购买之后没有持续性的最低要求——余额用得差不多时，再买一批就可以。

如果月中我们需要更多工时怎么办？

由于工时点数是预付余额，而不是绑定月度账单周期的订阅，你可以在余额不足时随时购买另一批——不需要等到续约日期或新合同期开始。每周的工时点数余额结算单和低余额预警的存在，正是为了让你提前看到这个信号，而不是在紧急情况进行到一半时才发现余额已经归零。

临时拼凑帮忙、整月MSP合同、还是工时点数服务：哪一种真正适合一家11人的机构？

临时拼凑的自由职业者帮忙

成本：通常是按次计费中最便宜的选项，没有前期承诺。
延续性：几乎没有。每一次故障都要靠联系到的人从零开始摸索。
可用性：谁刚好有空谁上——没有SLA，没有保证的响应时间窗口，也没有备用联系人。
安全与备份把关：没有人在事故之间负责，任何事情都不会被主动检查。
最适合：IT需求确实极为罕见、即便偶尔出现延续性断层也能接受的公司。

完整的托管IT合同

成本：按用户收取固定月费，定价依据是持续监控和管理基础设施——不管当月有没有出问题，价格都一样。
延续性：很强——7×24小时监控、专属虚拟CIO，以及一支已经了解你环境的团队进行主动管理。
可用性：明确的SLA响应时间窗口和持续覆盖，都写进了方案内。
安全与备份把关：持续有人负责——每一档方案都包含监控、打补丁和托管安全基线。
最适合：工单量足够大（按Brocent自身的工时点数与方案对比指引，大致是每月4起以上）的公司，此时持续监控和固定月费才是更经济的承诺形式。

工时点数式支持（Brocent Token Service）

成本：预付、按需付费——你提前购买工时（每个区域最低20个点数），只有真正出问题时才消耗，没有按用户计费的月费。
延续性：一段账户关系，加上一份有据可查的工单历史——每一项工作都会产生签署的服务报告，让下一位处理请求的人不必从零开始，即便不保证每次都是同一位工程师。
可用性：明确的SLA等级——营业时间内的当日响应（4小时或6小时），以及针对紧急情况的7×24小时等级、4小时到场响应。
安全与备份把关：不像托管方案那样包含持续监控——工时点数服务针对的是响应真实、偶发的问题，而不是全天候的主动基础设施管理。
最适合：IT需求真实存在但不规律的公司——按用户签合同在经济上说不通，但也大到不能再靠临时拼凑帮忙硬撑。

对一家11人的香港机构来说，诚实的答案很少是"你需要一份更大的合同"。通常问题在于，承诺的形态本身需要彻底不同——按事情实际发生的频率来定量，靠有据可查的记录，而不是靠"上一次帮忙的人一走，制度记忆也跟着一起消失"这种方式来维系。这正是工时点数服务要填补的空白——不是把托管IT方案缩小版重新打包，而是提供一种真正不同、从一开始就体量匹配的承诺。

Brocent自2007年起在亚洲各地提供IT支持与托管服务，2021年起将总部设在新加坡，香港办公室自2016年起服务本地市场——支撑工时点数服务的这套全球服务台、客户经理管理架构和SLA框架，同样也是Brocent为那些真正走到"整月合同更合适"这一步的公司提供完整托管IT方案的基础。

如果临时拼凑的IT帮忙已经不再可靠，但一整份月度合同又感觉体量不对，欢迎联系我们，一起聊聊你实际的工单量，看看工时点数服务、托管IT方案，还是介于两者之间的某种安排，才是适合你的起点。