香港雲端 PBX：連鎖開店的電話難題

一句話結論： 一家有十三家門市的香港餐飲集團簽下第十四家的租約後發現，裝修排程上前置期最長的一項不是廚房、也不是 POS，而是電話系統。此前每一家門市都被當成一座孤島來開：自己的線路、自己的話機、自己的號碼，總部誰也轉不進去。受管雲端 PBX 做的事，是把這件事從一個採購問題變成一個設定作業。

為什麼是電話線決定了開幕日

香港的多門市餐飲與專門店零售，是按固定日期跑的生意。租約某一天起算。房東某一天交屋。牌照查驗在某一天。員工按某一天到職，開幕行銷也是對著某一天訂下去的。裝修排程裡幾乎一切都能商量，唯獨交屋日不能——其後果就是：前置期最長的那一項，會悄無聲息地變成控制行事曆的那一項。

經營者通常以為那一項是廚房設備、門面，或者牌照。多數時候都不是。廚房設備提前幾個月就下單了，這行裡人人都知道要這麼做。POS 是個已解決的問題——供應商做過一百次，帶著設定好的終端上門。真正會悄悄延誤的，是那個沒人認領的項目：電話。

原因是結構性的。在香港為一個新的商業地址申裝一條固定電話線，不是一筆即時交易。它牽涉服務地址、部分樓宇要現場勘查、要預約安裝、還要等一段以工作天而不是小時計的時間。然後話機要到貨、要設定、要測試。然後號碼要印上招牌、要掛到外送平台上、要更新到集團自己的網站上、還要給到供應商。這些步驟沒有一個是難的。它們全部是循序的，而這個序列，要等某個人想起來才會開始。

對一家每年開兩三家新店的集團來說，這件事會反覆發生。而且因為每一次開店都由當時負責那個專案的人處理，每一次也就被就地解決一遍——新合約、新號碼、新一批話機——這正是一家集團最終會擁有十三套互不相連的電話系統、且一套也看不見的原因。

情境：十三座孤島，第十四座在路上

以下是一個複合情境。不是具名客戶——而是這個市場裡反覆出現的一種形態。

一家香港餐飲集團，十三家門市，用大約六年時間開出來。業態混合：港島與九龍有幾家較大的內用餐廳，購物中心裡有幾家較小的櫃檯式門市，觀塘的工廈改造專案裡還有兩家。總人數約兩百，另有十一人的總部，設在其中一家餐廳樓上。

每家門市都有自己的電話線，都是開幕當時單獨簽的。有的在這家電信商，有的在那家，合約簽署時間不同、條款也不同。總部沒有人對集團的電話總支出有一個彙總視圖，因為帳單是按不同帳戶寄來的，由各門市發票的經手人分別核可。

沒有號碼規劃。每家門市有一個對外公開的號碼，出現在自己的招牌上和外送平台上。總部有自己的線路。沒有分機號段，所以總部經理要找店長，辦法是打門市的公開號碼，然後指望有個不忙的人接起來；更現實的做法，是直接傳訊息到店長的私人手機。實際上，一家兩百人企業的全部營運溝通跑在私人即時通訊上，而電話系統只服務顧客。

訂位電話會落到顧客碰巧撥到的那一家。如果那家店週五晚上客滿，接電話的人沒有辦法把兩個捷運站以外那張空桌讓出來，因為他既轉不了這通電話，也不知道另一家店的空位狀況。顧客得到的回答是「抱歉，客滿了」，而集團丟掉了一單它其實有能力接的生意。

沒有通話紀錄。當顧客抱怨打了三次沒人接，集團無從查證這是不是真的。當供應商說改送貨時間已經電話確認過，也沒有任何關於這通電話的紀錄。每一次爭議，最後都由聽起來更篤定的那一方贏。

而硬體是一筆反覆發生的報廢。當一份租約到期、一家店收掉——這行裡這是會發生的——話機被收回來，放進總部的一個紙箱裡，再也不會被用到，因為下一家店的線路會按自己的合約配來自己的設備。

然後，第十四家店的租約簽了，裝修排程拉出來了，營運總監問了一個此前沒人問過的問題：為什麼電話是那根最長的桿？

除了帳單以外，這真正的代價是什麼

四項代價，大致按「有多痛」從輕到重排列。

沒人能壓縮的排程相依性。 這是看得見的那一項。新店沒有可用的電話就開不了幕，電話取決於電信商的安裝，而電信商的安裝取決於他們的行事曆而不是你的。在一個緊湊的裝修排程裡，這可能就是「按計畫週五開幕」和「延到下一週」的差別——那意味著一週只付租金沒有營收，以及一個必須挪動的行銷日期。

因為電話轉不走而流失的營收。 更難看見，因為它從來不會以「損失」的形式出現在報表上。每一次一家客滿的門市婉拒了另一家門市本可以承接的訂位，集團就丟掉了一張它本來有的桌子。一年下來，十三家店、每一個繁忙的週五和週六累加起來，這不是一個可以四捨五入掉的數字。它之所以看不見，只是因為沒有任何機制會去數它。

總部搆不到現場。 這個規模的集團有真實的營運溝通需求——供應商問題、人手缺口、食安疑問、外送平台故障。把這一切都跑在店長的私人手機上，在店長休假前、離職前、或者僅僅是晚上八點不當班而不回訊息之前，都還能用。這裡沒有「打給門市，找當值負責人」這個等價動作，因為「門市」是櫃檯上的一部話機，而「當值負責人」並不站在它旁邊。

不存在的證據。 通話紀錄在你需要它之前，一點都不激動人心。一起關於「據說已電話確認」的訂位客訴、一場關於送貨時間窗的供應商爭議、一次時間軸很關鍵的員工事件——每一種情況下，集團的立場都完全建立在某個人的記憶上。而一套受管系統會把紀錄當作營運的副產品自動產出。

Brocent 的看法：這是號碼問題，不是硬體問題

當電話變成瓶頸時，本能反應是把它解決得更快一點——找一家能更早安裝的電信商、更早訂話機、在專案計畫裡把它往前挪。這是在治症狀，而且它恰好只對一家門市有效：你眼下正在開的這一家。

結構性的觀察不一樣：一條持續擴張的連鎖，其電話系統是一個號碼與路由問題，只是被誤當成了硬體問題。集團真正需要的不是十三條線加第十四條，而是一套帶號碼規劃的系統——在這套系統裡，一家門市是一筆記錄，而不是一次安裝。

一旦完成這個反轉，下游的一切都會改變形狀。加一家門市變成一個以小時計的設定作業，而不是一個以週計的採購作業——這意味著電話徹底退出了裝修的關鍵路徑。跨門市轉接電話變得可行，因為門市在同一套系統裡。總部搆得到門市，因為門市是一個分機，而不是一台設備。通話紀錄存在，因為承載通話的那套系統，同時也是記錄它的那套系統。

這和 Brocent 在多據點營運中處理網路的原則是一樣的——價值來自把「意外分散掉的東西」重新收攏，而不是買一個更好版本的分散品。這也就是 IT 供應商整合這個論點，被應用在一家餐飲集團每天都要打交道的那一套系統上。

落到實處是什麼樣子

Brocent 的受管雲端 PBX是一套託管在 Alicloud、AWS 與 Azure 上的電話系統，帶 99.99% 的可用性承諾。對一家多門市集團來說，其中六件事比其餘的更重要。

一套受管 PBX，一份涵蓋全集團的號碼規劃。 每一家門市，加上總部，都落在同一個分機號段裡。店長有分機。廚房有分機。總部財務有分機。任何人撥三到四位數就能找到任何人，任何一通電話都能轉到集團內的任何地方。對外的公開號碼依然存在，依然指向顧客期待的地方——但它們下面是一套系統，而不是十三套。

軟體話機，讓員工用他們已經帶在身上的裝置。 UC 軟體話機在 Android、iPhone 和桌面端提供一致的企業通話體驗，不需要專用的實體桌上話機。對餐飲集團來說，這一條徹底消除了硬體問題：當值經理把門市的分機裝在自己口袋裡那台裝置上，分機跟著人在店裡走。而在實體話機確實合理的位置——櫃檯、後場辦公桌——照樣可以用。關鍵在於，它現在是一個選擇，而不是一個相依性。

自動總機、IVR 與來電佇列，對付週五晚上的問題。 進階功能集——自動總機、來電佇列、會議、IVR、語音信箱轉郵件、400 免付費熱線、等待音樂與進階路由——是內含的，不是外掛。落到營運語言：訂位線可以放一段選單、把來電放進佇列而不是一直響到掛斷，並在第一家店在設定時間內沒接起時溢流到第二家店或總部。最後這個行為，正是能把集團當前正在流失的那些訂位撈回來的東西。

透過認證 SBC 與 Microsoft Teams 整合。 在總部已經用 Teams 工作的情況下，PBX 電話可以透過微軟認證的工作階段邊界控制器（SBC）整合進去，從而直接在 Teams 裡撥打分機、市話和手機。總部員工與門市處在同一個分機號段上，而不必再多帶一個應用程式。如果集團內部協作本來就跑在 Teams 上，那麼 Microsoft Teams 解決方案與 PBX 最終會是一次部署，而不是兩次。

跨境時可用的當地號碼。 託管服務包含香港、中國大陸、日本與新加坡的當地電話號碼。對於擴張計畫裡有第一家大陸門市或一家新加坡試點店的集團，這一點會在它剛好變得相關的那一刻起作用——新市場在現有系統上拿到一個當地號碼，而不是在一個陌生法域裡重新走一遍採購流程。

以及底下的那張網。 一套受管電話系統相依於每個據點的連線品質，所以電話與門市網路應該一起界定範圍，而不是分開處理。Brocent 的受管無線網路服務涵蓋這一層。做預算時值得知道它的商業形態：Brocent 受管 IT 方案裡的「網路與無線」加購項目是按平價級距計價的——一個月費涵蓋至多 10 台裝置，然後在 11–30、31–75 和 76+ 處換級距——而不是單純的按台數乘算。對於一家停留在第一級距內的小型櫃檯店，多開一家店確實是很小的增量；一家連網設備很多的大型餐廳則可能跨進下一級距，而這件事在規劃階段知道，好過在第一張帳單上才知道。

多門市做電話的三種方式

按門市各自申裝——「每家店自己買」

是什麼： 每個據點在開幕時單獨安排一份電信商合約、一個號碼和一批話機。
代價： 高於帳單之和，因為真正的成本是裝修排程相依性、轉不走的那通電話、完全沒有集團層級的視圖，以及每次租約到期都要報廢的硬體。
適合誰： 單一門市，或者兩三家、且確實永遠不需要在彼此之間轉接電話的小集團。

總部一套地端 PBX

是什麼： 集團購買 PBX 硬體，裝在總部，把各門市接回來。集中號碼、集中控制。
代價： 前期資本支出、一段維護關係，以及一個單一的實體相依性——這台設備住在某一棟樓裡，靠那棟樓的電和那棟樓的連線活著。加一家門市意味著現場開通加中心設定。而總部搬遷時，PBX 也要跟著搬，那本身就是一個專案。
適合誰： 總部穩定、現有 PBX 還有剩餘壽命、並且傾向於自有基礎設施的集團。這條路 Brocent 同樣支援——現有 PBX 可以延伸到遠端辦公室和居家工作者，而不必整套換掉。

受管雲端 PBX——適合一家還在開店的連鎖

是什麼： PBX 託管在 Alicloud、AWS 或 Azure 上，帶 99.99% 可用性承諾，按使用者按月計價。門市是分機，不是安裝工程。軟體話機裝在現有裝置上，需要實體話機的地方照樣可以有。
代價： 用一筆按使用者計的月費取代資本支出，外加號碼規劃與路由規則的設計工作——這項工作做一次，之後是延伸而不是每店重來。
為什麼合適： 因為一家擴張中的連鎖，其真正的限制條件是「多快能開幕」，而這是唯一一種「開店不必等任何人的安裝行事曆」的模型。它同時消除了租約到期的硬體報廢，並產出集團目前沒有的通話紀錄。

從哪裡開始

對處在這個位置的集團來說，有用的第一步不是一份報價，而是一頁紙的號碼規劃：分機號段怎麼劃、哪些公開號碼維持不變、一通二十秒內無人接聽的訂位電話該去哪裡、以及總部有哪些人必須能被門市找到。這份文件的作用，是讓移轉變得乏味——而乏味正是目標：門市最好壓根感覺不到它發生的那一天。

從那裡開始，移轉通常是分批的：先總部加一兩家門市，其餘按批推進，公開號碼按計畫好的順序攜碼，而不是一次全轉。商務結構與其餘的受管 IT 支援安排並行，而務實的下一步，是圍繞你實際的門市現況聊一次——聯絡我們。

常見問題

我們能保留現有的電話號碼嗎？

多數情況下可以——攜碼是移轉到受管系統的常規環節，也是範圍界定階段最先確認的事項之一，因為它會隨號碼類型和號碼目前所屬電信商而不同。對餐飲集團而言這在商業上很要緊：門市號碼印在招牌上、掛在外送平台上、存在顧客手機裡、也被搜尋引擎收錄著。請把「攜碼」當作預設方案，在範圍界定時逐個號碼確認，並把切換順序排好，確保移轉期間沒有任何一家門市聯絡不上。

某一家門市斷網時，雲端 PBX 會怎麼樣？

只有那家門市的裝置受影響——集團其餘部分照常運作，這本身相較「按據點各自為政、一處故障就讓這個據點從地圖上消失」的舊模式，已經是有意義的改善。對受影響的那家門市，顧客的體驗由路由規則決定：打到該店的來電可以故障移轉到另一家店、總部或一個手機號，來電者只是接通到集團裡別處的一個人。這個故障移轉行為是設計階段的一項設定決策，值得刻意做出來，而不是等停機時才發現。99.99% 的可用性承諾涵蓋的是託管平台；各據點的連線是另一層，這也正是網路應當與電話系統一起界定範圍的原因。

員工還需要桌上話機嗎？

不一定。UC 軟體話機可以跑在 Android、iPhone 和桌面端，當值經理可以把門市分機帶在本來就有的裝置上。不少集團會在櫃檯或後場位置保留一部實體話機——那裡確實更適合一台共用、常在的裝置——其餘人則用軟體話機。真正有用的轉變是：話機從「每個據點的固定成本」變成了「每個職位的營運選擇」。

新增一家門市有多快？

系統建好之後，加一家門市是設定作業——分機、路由、需要的話再加一個號碼——而不是採購作業。現實的相依項轉移到了該據點自身的連線和實體設備的安裝上，而不再是電話系統本身。這個變化正是把電話移出裝修關鍵路徑的原因；對一家每年開兩三家店的集團來說，這就是整件事的意義所在。

這套東西能配合 Microsoft Teams 嗎？

可以。PBX 電話透過微軟認證的工作階段邊界控制器（SBC）整合進 Teams，從而可以直接在 Teams 裡撥打分機、市話和手機。對於總部已經生活在 Teams 裡、而門市不在其中的集團，這個組合很合適：總部繼續按原有方式工作，門市則在同一個分機號段上可被找到。

99.99% 可用性承諾，對一家餐廳到底意味著什麼？

它是對受管 PBX 平台——也就是 Brocent 營運的那部分——所作的承諾。落到實際，它意味著電話系統本身不是你需要圍著它做預案的對象；你該做預案的變數是各據點的連線和你自己的路由規則。風險放在那個位置更好，因為單一門市的連線是一個有在地解法的在地問題，而中心系統當機則是所有人同時的問題。

我們只有十三家店，受管 PBX 是不是太超過？

門市數量的相關性，不如「你是否還在開店」來得高。一家已經三年沒開新店、也沒有計畫開的穩定十三店集團，讓一套還能用的安排繼續用下去是合理的。而一家每年開兩三家的集團，是在反覆支付每店的開通成本；每多開一家，這筆帳就更划算一分，因為移轉只做一次，之後每一家新店幾乎都不再承擔它。

成本方面呢——比我們現在花的多還是少？

老實說，這取決於你的門市現況；任何不看你帳單就回答這個問題的服務商，都是在猜。結構性的變化是：支出從「十三份獨立的電信商合約加上週期性硬體採購」變成「一套系統上的按使用者月費」，這讓它第一次變得可見、可比較。Brocent 的服務頁面上，在完整定價更新之前列出了分機類型與 SIP 中繼的指示性市場參考價，而受管 PBX 的基礎平台費按部署單獨報價——最終數字在範圍界定階段，對著你實際的門市數與使用者數確認。