酒店 Wi-Fi 體驗：影響住客評價的關鍵指標
| 酒店方案
房內訊號弱、認證頁彈唔出、行過走廊就斷線，酒店 Wi-Fi 點樣由勘測、佈置、分網、漫遊同驗收逐樣做好？前台收到投訴嗰陣又要點樣問先搵到根因呢？
Wi-Fi 體驗，係住客會記得嘅部分
住客對一間酒店嘅印象，好多時唔係嚟自大堂有幾靚，而係嚟自最基本嘅嘢用唔用得順：入房連唔連到網、視像通話會唔會中途斷線、認證頁彈唔彈得出。Wi-Fi 出問題，住客唔會諗「可能係頻道規劃問題」，佢哋只會記得「呢間酒店上網好差」。所以酒店 Wi-Fi 唔係「有訊號就得」，而係要由勘測、佈置、認證、分網、漫遊到驗收，逐樣做好。本文講嘅全部係原理、設計方向同檢查方法，唔包含任何酒店名、評價統計、價錢或者裝置數量公式；每個項目嘅具體安排，都要按現場勘測決定。
先講一個基本觀念：酒店 Wi-Fi 問題通常唔係單一原因。房內訊號弱，可能係 AP 位置問題；認證頁彈唔出，可能係認證前放行清單問題；行過走廊就斷線，可能係漫遊設定問題。將問題分開嚟諗，先至搵到真正根因，唔好一味加 AP 了事。
一、點解房內訊號成日唔掂
無線訊號穿過牆身、防火門、浴室瓷磚等障礙物會衰減，房內訊號往往明顯弱過走廊。如果 AP 只放走廊，訊號要穿兩道牆先到住客裝置，房內體驗容易不穩。呢個就係「走廊 AP 唔足夠」論點嘅來源。舊設計常見嘅問題係多間房共用走廊 AP，建築結構阻擋訊號；改善方向之一，係將 AP 放到房入面，減少穿牆。不過具體用邊種佈置，要按現場勘測決定，唔好寫成「每間房一定要一隻 AP」。
另一個常見現象係裝置「黏住」遠方 AP：裝置即使附近有訊號更強嘅 AP，仍然黏住原來較遠嘅 AP，導致速度慢、延遲高。呢個唔係 AP 壞，而係漫遊行為問題，後文會再講。仲有一個要點：AP 唔好藏喺密閉櫃或者大型金屬物後面，唔好裝喺要打擾住客先維修到嘅位置，例如浴室假天花上面；要考慮日後更換同重啟嘅便利。
二、三種 AP 佈置點揀
| 方案 | 適合場景 | 優點 | 風險同代價 |
|---|---|---|---|
| 走廊吸頂 AP | 走廊、大堂等開放或者通道空間 | 覆蓋範圍較易預測；安裝位置集中 | 房內要穿牆，體驗不均；走廊同房間之間容易出現裝置黏住遠方 AP 唔轉移 |
| 面板 AP（Wall Plate AP，86 盒式） | 酒店客房、宿舍等一房一單位場景 | AP 喺房內，減少穿牆；每房體驗較一致；房與房之間天然射頻隔離較好；部分型號自帶有線端口，可接房內有線裝置，視型號而定 | AP 數量多，佈線同維護點多；走廊覆蓋要另外規劃，唔可以假設面板 AP 會順便覆蓋走廊 |
| 房內吸頂 AP | 房內或者開放空間，視天花條件而定 | 覆蓋規劃較易做；適合開放空間 | 房間密集場景下，吸頂 AP 訊號容易漏去隔籬房，造成跨房干擾同裝置黏連，若漫遊門檻無調校 |
實務上常見混合設計：開放空間用吸頂 AP，客房用面板 AP。每房 AP 係常見設計方向之一，需按現場勘測決定，正文唔會寫任何每房 AP 數量公式。每個 AP 應該有有線連接、PoE 供電，而唔係依賴無線 Mesh 做主回程；Mesh 只係覆蓋延伸手段，唔係酒店主架構。結構化佈線一般可以用 15–20 年，呢個係正確技術描述；佈線做得好，日後換 AP、加點位都唔使重新大執。
三、認證登入：Captive Portal 點解成日彈唔出
Captive Portal 係咩
住客連上訪客 SSID 之後，首次上網會被導向認證頁，完成驗證先放行上網。常見認證方式包括房號加姓氏、會員或者忠誠計劃帳戶、前台派發嘅一次性券碼、電郵或者短訊驗證、一鍵連接（接受條款即放行）。邊種適合，要按酒店營運方式決定，唔係越複雜越好。認證頁應手機優先、單屏完成、欄位越少越好，要支援多語言；登入後頁面可展示酒店設施資訊。
認證頁打唔開嘅常見根因
認證頁彈唔出，唔一定係網絡斷咗，常見根因包括：裝置先開加密網站，網絡無法重定向，認證頁無觸發；認證前放行清單未包括作業系統連通性檢測域名，裝置誤判為無互聯網而放棄；認證頁憑證無效或者自簽憑證被瀏覽器阻擋；裝置開咗 VPN、私人 DNS、Apple Private Relay 等，流量加密直出，本地閘道無法攔截做重定向；MAC 地址隨機化，現代手機會輪換私有 MAC 地址，若認證頁用 MAC 追蹤連線，輪換後會被視為未認證裝置，要重新認證。至於「已連接但無互聯網」，裝置已取得 IP，但作業系統探測失敗，常見原因包括 DNS 查詢超時、DHCP 地址池耗盡、認證前 DNS 流量被防火牆阻擋。排障嗰陣，要逐項對照，唔好一味叫住客重新開機。
房號加姓氏同 PMS 整合
PMS（Property Management System，物業管理系統）係酒店記錄住客入住、房號、退房等資料嘅系統。Captive Portal 同 PMS 對接之後，住客用房號加姓氏登入，Portal 向 PMS 查詢該預訂係咪有效，驗證通過先放行；退房後存取自動失效，唔使人手管理帳戶。任何 PMS 品牌名單、API 協議名、整合費用、實施時間，正文一律唔寫。用房卡直接驗證 Wi-Fi 並非已確認嘅通用做法，選用之前要向酒店或者系統供應商確認，唔好寫成標準功能。酒店 Wi-Fi 係咪要做 PMS 整合，屬於服務範圍問題，要喺報價之前同酒店確認，唔好喺文章入面寫到好似一定包埋。
四、分網同加密：訪客、員工、會議、IoT 要分開
VLAN 將同一實體網絡邏輯分隔成多個獨立網段，配合防火牆規則限制跨網段存取。常見分網方向包括：訪客 Wi-Fi，只上網，訪客裝置之間互相隔離，唔可以存取酒店內部系統；員工或者管理，前台、後台系統、PMS 終端；會議或者活動，活動專用 SSID 同網段，同客房網絡分開，避免活動流量影響住客；IoT 或者智能客房，智能電視、房控、感應器等裝置獨立網段；支付或者 POS，收銀系統獨立網段。原則係訪客網絡預設唔應該可以存取員工、管理、支付網段，跨網段只放行確實需要嘅指定目的地。任何具體 VLAN 編號、IP 範圍、防火牆規則清單，正文唔會寫。
WPA3 同 OWE
WPA3 係 Wi-Fi 安全協議嘅較新一代，相比 WPA2 改進咗認證握手方式同前向保密概念。OWE（Opportunistic Wireless Encryption）係 WPA3 入面針對開放網絡嘅加密方式，又稱 Enhanced Open。原理係裝置同 AP 之間做 Diffie-Hellman 密鑰交換，為每個客戶端建立獨立加密會話，唔使輸入密碼。效果係防範被動竊聽，同一網絡其他人唔可以直接偷睇流量。限制係 OWE 提供加密，但唔提供身份驗證，唔驗證 AP 係咪真身，仍然有假 AP 中間人攻擊風險，唔可以寫成 OWE 等於安全。開放訪客網絡可考慮 OWE 做免密碼但有加密；員工網絡則應考慮以帳戶為本嘅認證，例如 WPA3-Enterprise 或者 802.1X，唔用共用密碼。WPA3 亦要求保護管理幀（PMF），防止偽造解除連接指令踢裝置落線，有助連接穩定。舊裝置未必支援 WPA3 或者 OWE，部署之前要確認住客裝置兼容情況。相關嘅企業網絡規劃，可以參考 Wi-Fi 解決方案。
五、漫遊：點解行過走廊就斷線
漫遊係裝置由一個 AP 切換到另一個 AP 嘅過程。決定權主要喺裝置手上，網絡只能協助或者引導，唔可以強制裝置切換。漫遊質素受覆蓋重疊係咪足夠、AP 發射功率係咪過高、頻道規劃、裝置本身漫遊行為、認證方式等因素影響。住客移動路徑包括房間、走廊、電梯、走廊轉角、大堂、會議室，每個轉換點都係漫遊斷線高風險位。電梯井係金屬結構，會阻擋訊號；電梯內覆蓋往往要獨立考慮，唔可以假設走廊 AP 會覆蓋到電梯內。大堂同會議室係開放空間，人流多、裝置多，漫遊同容量要一齊規劃，唔可以只睇覆蓋。
| 標準 | 作用 | 注意 |
|---|---|---|
| 802.11k（Radio Resource Measurement） | AP 提供鄰近 AP 清單，等裝置唔使逐個頻道慢慢掃描，更快搵到候選 AP | 只在裝置都支援先有效 |
| 802.11v（Wireless Network Management） | 網絡可建議裝置轉去更合適嘅 AP，有助平衡負載、改善黏住問題 | 只在裝置都支援先有效；網絡建議唔等於裝置一定跟從 |
| 802.11r（Fast BSS Transition，快速漫遊） | 預先處理部分認證資料，縮短切換 AP 時嘅重新認證時間 | 只在裝置都支援先有效；企業級認證環境下作用較明顯 |
關鍵一句：802.11k、v、r 係協助漫遊嘅標準，唔等於無縫漫遊；裝置支援、覆蓋、設定全部要配合。正文唔會寫任何漫遊切換只需幾多毫秒嘅通用承諾。
六、頻段同頻道規劃
| 頻段 | 角色 | 限制 |
|---|---|---|
| 2.4 GHz | 穿透較好、覆蓋較遠；適合 IoT、舊裝置、低頻寬裝置 | 可用不重疊頻道少；干擾多；容量較低 |
| 5 GHz | 企業容量主力；裝置支援最廣；頻道較多 | 穿透較 2.4 GHz 弱；部分頻道受 DFS 雷達避讓約束 |
| 6 GHz（Wi-Fi 6E／Wi-Fi 7 裝置） | 額外乾淨頻譜；適合高容量、低延遲場景 | AP 同裝置都要支援先用到；室內室外、功率受法規約束；舊裝置用唔到 |
Band Steering 係網絡引導支援嘅裝置優先用 5 GHz 或者 6 GHz，減少 2.4 GHz 擠塞。頻道越闊，單一裝置峰值速度越高，但可用不重疊頻道越少，同頻干擾風險越高；高密度環境通常用較窄頻道換取更多不重疊頻道同穩定性，正文唔會寫任何具體頻道寬度數值建議。同頻干擾係多個 AP 或者裝置用同一頻道，要輪流使用空氣時間，容量被分薄、延遲上升；鄰頻干擾係 AP 用部分重疊但唔完全相同嘅頻道，互相聽唔到對方，會同時傳送並撞毀訊框，重傳率上升，一般認為比同頻干擾更差。所以頻道規劃要避免鄰頻重疊。DFS（Dynamic Frequency Selection）係 5 GHz 部分頻道同雷達共用頻譜，AP 用呢啲頻道之前要先聆聽有無雷達訊號，偵測到雷達就要離開該頻道並一段時間內唔用。DFS 頻道可以提供額外容量，但有機會因雷達偵測而突然轉頻道，影響對穩定性敏感嘅應用；近機場、港口、氣象雷達範圍，或者語音、IoT 等唔容忍中斷嘅場景，要特別謹慎。任何具體聆聽時間、停用時間、距離門檻，正文唔會寫。
七、會議同宴會高密度：問題通常唔係訊號唔夠
會議室或者宴會廳問題通常唔係訊號唔夠，而係容量唔夠：少量 AP 可以覆蓋成個廳，但應付唔到大量裝置同時連接同傳輸。常見做法係細細胞設計：用較多 AP、較低發射功率，將每個 AP 服務範圍縮細，等每個 AP 服務較少裝置，減少競爭。大型活動可預留臨時 AP 擴充位置；臨時 AP 需要有線回程同電源，唔可以假設無線 Mesh 頂得住高密度。活動專用 SSID 同網段要同客房網絡分開，避免活動流量拖累住客網絡，亦方便活動完結後關閉。活動之前，最好同主辦方確認活動性質：係純粹講座定係需要大量裝置同時上網、會唔會有直播或者視像連線、參加者會集中喺邊個區域。活動期間安排人手喺場跟進，活動完咗之後，記得將臨時改過嘅設定還原，唔好留低一啲之後冇人記得嘅改動。
頻寬管理五個原則
- 每裝置上限：為單一裝置設上限，防止個別裝置壟斷容量。
- 應用優先：視像會議、語音等即時應用優先於背景下載，唔係所有流量平等。
- 空氣時間公平（Airtime Fairness）：慢速舊裝置傳同樣數據要用更多空氣時間；若無公平機制，慢裝置會拖慢成個頻道。企業級 AP 有空氣時間公平機制，將空氣時間分配拉平。
- 分層或者分組：唔同群組，例如住客、活動參加者、員工、主辦方，可有唔同政策；活動主辦方或者影音等關鍵用途可獨立政策。
- 監察：活動期間要監察每頻道利用率、每 AP 空氣時間、每 AP 裝置數、重傳率、認證失敗、漫遊失敗、DFS 事件等，及早處理。
以上全部係原則，正文唔會寫任何頻寬上限數字、每裝置頻寬建議、活動人數對照表。辦公室同酒店以外，會議場地嘅網絡分流原則，亦可以參考 辦公室網絡方案。
八、常見誤解
誤解一：訊號格數等於網速
手機或者電腦嘅 Wi-Fi 格數，主要反映裝置同附近 AP 之間嘅無線訊號強度，唔直接量度互聯網速度。訊號滿格，仍然可能因為上游頻寬、容量擠塞、干擾、DNS、認證等原因而上網慢。格數只係講裝置去到 AP 呢段路順唔順，唔講 AP 去到互聯網呢段路順唔順。
誤解二：加多 AP 就一定好
AP 數量增加，若無頻道同功率規劃，只會增加干擾。同一頻道嘅 AP 同裝置要輪流用空氣時間；部分重疊頻道仲會互相撞毀訊框。目標係啱數量嘅 AP，唔係最多 AP。降低發射功率、縮細細胞、規劃頻道，先至令多 AP 變成多容量；否則多 AP 只係多干擾。
誤解三：免費 Wi-Fi 等於無管理
免費只係收費模式，唔代表網絡無認證、無分網、無頻寬管理、無監察。酒店訪客網絡仍然需要認證、分網、頻寬管理、監察，先至可以同時兼顧住客體驗同安全。免費係指住客唔使額外付費，唔係指網絡無管理。
其他誤解
換更貴 AP 就解決，係誤解：若問題係覆蓋規劃、頻道、認證、容量，換 AP 未必解決，要先勘測搵根因。測速快等於體驗好，係誤解：測速只反映某一刻某一裝置嘅下載速度，唔反映延遲、封包遺失、漫遊、尖峰時段表現。Mesh 可以代替有線回程，係誤解：酒店高密度環境應以有線回程為主，Mesh 只係延伸手段。
九、驗收檢查清單：唔好只喺空房測試
房間抽測
抽測唔同樓層、唔同位置嘅房間，例如近 AP、遠 AP、轉角房、尾房、近電梯房，唔好只測 AP 正下方。每間抽測房，房門口、書枱、床頭、浴室門口要分別測試，記錄邊個位置弱。測試唔同裝置類型，例如手機、筆電，唔好只用一種裝置做結論。檢查房內 AP 係咪正常運作，指示燈同管理平台狀態係咪正常。
漫遊測試同認證測試
漫遊測試要沿住客真實路徑行一次：房間、走廊、電梯大堂、電梯、大堂、會議室或者餐廳，途中保持視像通話或者持續探測，觀察有無中斷、重新認證。記錄裝置係咪黏住舊 AP，可以喺管理平台睇裝置關聯 AP 變化。認證測試要用全新裝置或者忘記網絡後重新連接，測試認證頁係咪正常彈出；測試房號加姓氏登入流程，正確資料通過、錯誤資料被拒、退房後失效；測試唔同作業系統嘅認證頁表現；檢查認證前放行清單係咪包括作業系統連通性檢測域名、認證頁憑證係咪有效。
尖峰時段測試同文件交付
唔好只喺空房或者無人時段測試，要喺實際尖峰時段監察表現，例如夜晚住客集中上網時段、會議進行期間。監察項目包括頻道利用率、每 AP 空氣時間、每 AP 裝置數、重傳率、認證失敗、漫遊失敗、DFS 事件，比較尖峰同非尖峰表現，唔好只用一次測速做結論。文件交付要齊：AP 位置圖、佈線圖、線號、交換器連接、IP 資訊、SSID 清單、頻道規劃、功率設定、認證設定、分網設定有記錄，日後維護人員跟到。
舊樓改造同投訴處理
舊建築改造要面對磚牆、鋼結構、有限佈線路徑；新佈線可能要開槽、拆天花、修補牆身，施工期長，可能要分階段施工以減少對營運影響。以上係一般原則，香港項目需現場勘測確認，正文唔會寫成香港酒店普遍如此，亦唔會寫任何香港酒店改造案例、樓宇佈線法規要求、裝修期長短。收到住客投訴網速慢或者連唔上嗰陣，前台第一時間要問清楚邊間房、咩時間開始出事、同埋用緊咩裝置。同一層多間房同時出事，好可能係嗰層嘅設備或者線路問題；得一間房出事，就要先睇房入面嘅設定同裝置。問清楚之後，前台可以按情況即時幫手，例如教住客重新連接、或者安排轉房，之後再將投訴內容記低，交俾工程團隊跟進。投訴根因可以分為認證頁問題、漫遊斷線、隔牆衰減、容量不足、干擾、裝置因素，排障嗰陣逐類對照，唔好將單一投訴寫成統計排名。
酒店 Wi-Fi 做得好唔好，唔好只係喺工程完成嗰日試一次就收貨。最準嘅做法係喺入住高峰時段再行一次全場測試：由大堂行去客房、再由客房行去餐廳同健身房，一路開住視像通話，睇下會唔會中途斷線；同時用幾部唔同品牌嘅手機試登入 Portal，確認登入流程唔會喺某啲機型上面卡住。如果測試嗰陣發現某層走廊訊號特別弱，好可能係 AP 位置俾裝修遮住，或者同鄰近 AP 互相干擾，呢啲問題喺人少嗰陣未必睇得出，高峰期先會現形。
另外，客房同公共空間應該分開諗。客房講求每間房穩定、唔好俾隔籬房干擾；宴會廳同會議室就講求同一時間容納大量裝置，兩者嘅 AP 密度同設定重點並唔相同。投入使用之後，亦要定期檢查：韌體更新、Portal 內容係咪過期、邊啲 AP 經常負載特別高。住客嘅投訴往往係最早嘅警號，收到投訴之後先記錄低邊層、邊個時段、咩裝置出事，再對照檢查，先至搵到真正原因，而唔係一味加 AP 了事。
收到住客投訴網速慢或者連唔上嗰陣，前台第一時間要做嘅，唔係即刻話會派人整，而係問清楚三樣嘢：邊間房、咩時間開始出事、同埋用緊咩裝置。呢啲資料睇落瑣碎，但係搵原因嘅關鍵——同一層多間房同時出事，好可能係嗰層嘅設備或者線路問題；得一間房出事，就要先睇房入面嘅設定同裝置。問清楚之後，前台可以按情況即時幫手，例如教住客重新連接、或者安排轉房，等住客唔使喺房入面乾等。之後再將投訴內容記低，交俾工程團隊跟進，咁先至唔會出現投訴完冇人理、住客第二次投訴嗰陣又要由頭講過嘅情況。
酒店有宴會、會議或者大型活動嗰陣，網絡需求會同平時好唔同。活動開始之前，最好同主辦方確認清楚活動性質：係純粹講座定係需要大量裝置同時上網、會唔會有直播或者視像連線、參加者會集中喺邊個區域。確認咗之後，工程團隊就可以按活動需要檢查該區嘅覆蓋同設定，活動期間亦安排人手喺場跟進，萬一出現問題可以即刻處理。活動完咗之後，記得將臨時改過嘅設定還原，唔好留低一啲之後冇人記得嘅改動，影響日常運作。
前台同房務同事係最先接觸住客投訴嘅人，佢哋識唔識基本排查，直接影響住客體驗。培訓唔使好深入，但要講到明：點樣問住客攞到關鍵資訊、點樣幫住客做最基本嘅重新連接、邊啲情況可以直接處理、邊啲情況要即刻轉介工程團隊。最重要係唔好叫住客自己去改複雜設定，或者叫住客等唔知幾耐。有一份簡單嘅應對流程，寫低邊個情況搵邊個、點樣記錄，貼喺前台當眼處，新同事都可以即刻跟住做，唔使靠估。
酒店網絡出問題，好多時唔係單一部門可以解決，前台、房務同工程之間嘅交接就好重要。前台收到投訴之後，要將房號、時間、裝置同問題描述清楚交俾工程團隊，工程團隊處理完之後，亦要話返俾前台知結果，等前台可以同住客跟進，唔好令住客問極都冇答案。定期開一個簡短嘅內部檢視，將最近收到嘅投訴攞出嚟睇：邊層出事最多、邊類問題最常見、邊啲已經跟進好、邊啲仲未解決。跟進到結案先至算完成，唔好記低就算。呢種跨部門交接做得好，投訴先至唔會喺部門之間走失。
除咗處理投訴，定期檢視亦好重要。每隔一段時間，工程團隊應該檢視一次投訴記錄，睇下邊層、邊類問題最常見，再對照返檢查一次相關設備。韌體有更新嗰陣，應該按計劃更新，更新之後檢查一次各樓層係咪仍然收到訊號。Portal 內容亦要定期檢查，確保上面嘅推廣同資訊未過期，唔好令住客見到舊優惠。定期檢視唔使好複雜，但長期做落去，可以及早發現問題，唔使等到住客投訴先至知。