太小簽不了IT合約？香港精品公司的Token故事

本文為複合情境，並非指真實客戶： 一家11人的香港設計工作室，三年來都是靠「誰家的表親懂電腦」來處理IT問題——這套方法一直勉強夠用，直到一台筆記型電腦在客戶提案前一週徹底當機開不了機，工作室才發現根本找不到真正了解自家系統的人可以求助。這正是按需付費、以工時點數（Token）計費的IT支援所要解決的問題：既要有延續性，又不必背上一份為規模大得多的公司量身打造的合約。

香港精品型公司確實有IT需求——只是不是「標準款」需求

如果你是一家8到15人的創意工作室、精品顧問公司或小型貿易辦公室，去和香港大多數委外IT服務商（MSP）談合作，得到的方案往往是為一家你並不是的公司設計的。標準委外IT方案按每位使用者每月計費，背後的假設很明確：員工人數、設備數量、以及日常工單量都要達到一定規模，7×24小時監控、修補程式管理、委外防火牆、以及專屬虛擬CIO這類固定月費服務，在經濟上才划算。

在11人這個規模，這個假設並不成立。精品型公司的IT需求是真實存在的——筆電會壞、和客戶通話時網路會斷線、有人會誤點釣魚郵件、新人到職需要盡快配好電腦——但這些需求並不規律。可能某個月只出現三、四次狀況，也可能什麼事都沒發生。如果每個月都要為按50人規模設計的7×24小時網路維運中心監控和持續端點管理，支付固定的每人月費，這筆錢其實是在為一個11人辦公室根本用不到的基礎架構買單。這個規模真正需要的是：一位有能力、隨叫隨到、已經熟悉你系統的人，而不是不管有沒有出事都在背後持續運轉的訂閱服務。

這不是一個假設性的空白地帶。這恰恰是許多香港中小型專業與創意公司所處的真實處境——「公司太小簽不了合約」和「公司太大不能再靠臨時幫忙撐下去」之間的這段真空地帶——而大多數IT支援的行銷內容根本沒有涵蓋到這一塊，因為標準委外服務的推銷邏輯只有一個刻度（人頭數 × 月費），沒有為「偶爾發生、但確實存在」的需求設計對應的檔位。

情境：沒有固定的IT合作關係，也沒有制度記憶

想像一家11人的香港設計工作室——五位設計師、兩位客戶經理、一位身兼記帳工作的辦公室經理、幾位資淺員工，加上兩位創辦人。三年來，IT問題一直是用小型公司常見的方式處理：先問辦公室裡（或誰家人）「懂電腦」的人。如果不管用，就上網找附近的維修店，或找一位朋友推薦的自由接案者。

大致上，這套辦法一直有效。筆電最後總能修好。網路斷線就重開一下路由器。軟體授權過期就重新裝一次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方案，還是介於兩者之間的某種安排，才是適合你的起點。