飯店 WiFi RFP 檢核表：身份驗證、內容過濾與訪客行銷

飯店 WiFi RFP 檢核表應在單一招標案中測試三項核心能力。員工身分驗證必須使用 IEEE 802.1X 或與身分提供者綁定的個人專屬金鑰。內容過濾必須針對每個網路套用 DNS 原則。訪客資料收集必須記錄每次選擇同意的 GDPR 同意聲明。一份招標案就能為您帶來單一合約、單一管理面板與單一稽核軌跡。

飯店 WiFi RFP 檢核表實際上包含哪些內容？

大多數飯店分三個獨立部分購買 WiFi：

• 員工存取權限由 IT 部門負責，通常使用隱藏網路上的共用密碼。
• 訪客存取權限由 Captive Portal 廠商提供，可能由行銷部門選擇，或與寬頻提供商搭配打包。
• 內容過濾由第三方提供，或根本完全沒有部署。

每個部分都能獨立運作。但組合在一起時，就會產生三份合約、三個管理面板以及三套永遠無法對齊的日誌紀錄。當員工離職時，他們的 WiFi 存取權限往往會一直保留到下一次更換密碼為止。當訪客詢問您持有他們哪些資料時，答案可能儲存在您的資料保護官 (DPO) 從未稽核過的系統中。

單一飯店 WiFi RFP 檢核表可透過同時對廠商在三個領域的表現進行評分來解決此問題：

• 員工身分驗證：誰加入員工網路、他們如何證明自己的身分，以及離職時存取權限終止的速度有多快。
• 內容過濾：在哪些網路上封鎖哪些類別的網站，以及該過濾器有多難被繞過。
• 訪客資料收集與行銷：訪客如何連線、您能瞭解他們哪些資訊，以及每筆行銷紀錄是否都具備合法同意。

此檢核表假設您保留現有的 AP。Purple 可作為雲端覆蓋層（Cloud overlay）運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 以及 Fortinet 硬體之上。因此，您的 RFP 可以專注於軟體與資料，而不是全面汰換硬體。為什麼您下一次的 WiFi 升級不需要新硬體 完整闡述了硬體方面的觀點。

在撰寫 RFP 之前您需要準備什麼？

廠商會根據您撰寫的 RFP 進行回覆。模糊的要求會產生模糊的答案，導致所有廠商得分相同。在起草任何問題之前，請先收集以下六項輸入資料。

AP 與控制器清單

列出每個場館的 AP 廠商、控制器或雲端管理面板以及韌體版本。記錄不同據點之間的差異，例如較新的物業使用 Cisco Meraki，而收購的物業使用 Ruckus。要求廠商按名稱確認對每種組合的支援。

您的身分單一事實來源

明確指出存放員工帳號的名錄：Microsoft Entra ID、Okta 或 Google Workspace。記錄派遣與季節性員工在其中的呈現方式。這些帳號是在人員離職後最常被遺忘並保持啟用狀態的帳號。

網路區隔地圖

繪製您現有的 VLAN。VLAN（虛擬區域網路）能在共用的交換器與基地台上將流量進行邏輯隔離。您至少需要將訪客、員工與支付網路分開。PCI-DSS 會將連接至持卡人資料環境的所有系統都納入稽核範圍。適當的網路切分可確保您的訪客網路不會進入信用卡支付稽核範圍。

指定負責人的過濾政策

確定由誰制定過濾規則：IT、法務或營運部門。接著決定哪些區域套用哪些政策。供家庭使用的大廳所需要的規則，自然與滿是參展商的會議廳不同。

資料保護立場

與您的 DPO 確認您希望收集哪些訪客資料、收集原因以及資料的流向。根據 GDPR 第 4(11) 條，同意必須是自由給予、特定、知情且明確的。在英國，隱私與電子通訊條例（PECR）也規範了電子郵件與簡訊行銷。在廠商詢問之前，請先指定您的 CRM 或行銷平台。

RF 射頻效能基準

身分驗證無法解決訊號覆蓋不足的問題。在招標前，請從您的控制器擷取通道利用率報告，或進行現場勘測。如果 2.4GHz 擁塞是已知問題，請先閱讀 WiFi 通道終極指南：2.4GHz 與 5GHz 深度解析。

如何逐項建立檢核表？

將每項需求寫成可以用「是」、「否」或「佐證資料」回答的問題。「支援企業級安全性」會讓每個廠商得到相同的分數；但「支援搭配 Microsoft Entra ID 的 EAP-TLS，並可在帳號停用時撤銷存取權」則能區分出優劣。

員工驗證需求

員工 WiFi 承載著您的物業管理系統、POS 端點銷售系統、房務管理平板電腦與後勤筆記型電腦。在該網路上使用共用密碼是單點故障的風險。請要求提供以下功能：

• IEEE 802.1X。 這項用於基於連接埠之存取控制的 IEEE 標準，可確保每個裝置在取得位址之前先證明其身分。請詢問廠商支援哪些 EAP 方法。EAP-TLS 在雙邊皆使用憑證，可完全免除密碼。PEAP 則是在加密的 TLS 隧道內保護使用者名稱與密碼。
• Cloud RADIUS。 RADIUS（遠端用戶撥號認證服務）是基地台用來決定裝置是否可以連線的協定。雲端原生 RADIUS 服務可免除您原本需要修補與備份的地端伺服器。
• iPSK 或 PPSK。 身分預共享金鑰（iPSK）與私有預共享金鑰（PPSK）可讓每個人或裝置在同一個網路名稱上擁有自己的金鑰。卡片印表機、智慧電視與較舊的手持裝置無法執行 802.1X，因此需要此功能。
• 目錄同步。 SCIM（跨領域身分管理系統）是用於跨系統建立與刪除帳號的開放標準。請要求廠商展示新進、異動與離職人員如何自動從您的目錄中同步，無需任何人工操作。
• WPA3。 WPA3 需要受保護的管理框架 (IEEE 802.11w)，此框架可阻擋偽造的斷線攻擊。受保護的管理框架：2026 年實用指南 涵蓋了需要詢問的用戶端相容性問題。

Purple 的 Identity-Based Networks 讓每位員工都能以自己的身份連線至網路。當您在目錄中停用某個帳戶時，Purple 就會撤銷該人員的 WiFi 存取權限。

訪客身分驗證需求

報到流程決定了訪客是否能夠連線。每增加一個表單欄位都會損失連線率，而每減少一個欄位則會損失資料。請要求提供以下功能：

• 可設定的 Captive Portal。 Captive Portal 是訪客上網前看到的網頁。要求能夠針對每個物業進行品牌化、支援多國語言，並提供多種登入方式選擇：電子郵件、社群登入或簡訊驗證。
• 經過驗證的行動裝置行為。 iOS 和 Android 會在受限的迷你瀏覽器中開啟 Captive Portal。在評估期間，請要求在最新的 iOS 和 Android 版本進行實機登入測試，而非僅提供螢幕截圖。
• Passpoint 與 OpenRoaming。 Passpoint（也稱為 Hotspot 2.0）是基於 IEEE 802.11u 的業界認證。它能讓裝置自動且安全地加入已知網路，完全無需 Captive Portal。OpenRoaming 是建構在 Passpoint 之上的 Wireless Broadband Alliance 聯盟。它允許訪客使用現有的身分進行連線。
• 連線階段與頻寬控制。 要求提供每個網路的頻寬限制、連線階段長度控制以及每位訪客的裝置數量限制。
• 用戶端隔離。 同一網路上的訪客不應看到彼此的裝置。要求預設開啟隔離功能。

Purple 的 Guest WiFi 在全球 90 多個國家/地區的 80,000 多個實體場地運行此層級服務。根據 Purple 自身的平台資料，它在 2024 年處理了 4.4 億次登入。

內容過濾需求

飯店在共享空間提供公共網際網路存取，使用者通常包含家庭。DNS 過濾是常見做法：平台會拒絕解析被封鎖類別中的網域。請要求提供以下功能：

• 基於類別的 DNS 過濾，並具備具名的分類來源。在英國，至少需要 Internet Watch Foundation (IWF) 的 URL 清單。
• 個別網路政策。 大廳與家庭區域採用嚴格政策。會議廳和員工網路則各自擁有專屬政策。
• 抗規避能力。 DNS over HTTPS（DoH，定義於 RFC 8484）會在加密的網路流量中傳送 DNS 查詢，可能會繞過您的過濾器。請詢問廠商如何處理 DoH 以及自行設定 DNS 伺服器的訪客。
• 認證。 在英國，詢問您的部署是否符合 Friendly WiFi（政府發起的過濾公共 WiFi 認證計劃）。
• 日誌保留控制。 過濾日誌可以識別個人身分，因此適用 GDPR。請詢問日誌保留多久時間以及誰有權限讀取。

訪客資料擷取與行銷需求

訪客 WiFi 是現場用餐顧客、會議代表和代理商預訂人員直接向您識別身份的唯一觸點。請要求以下項目：

• 明確選擇的同意訂閱。 行銷同意必須是單獨且未勾選的選項。GDPR 第 7(4) 條規定，當服務依賴於其不需要的同意時，該同意即非自由給予。存取 WiFi 絕不能要求同意行銷訂閱。
• 時間戳記同意紀錄 適用於每個個人資料，且可匯出以供當事人存取請求（SAR）使用。
• 具名的 CRM 與行銷平台整合，並在回應中顯示欄位對應。
• 造訪分析：全新與回訪訪客、停留時間以及按據點計算的造訪頻率。WiFi 分析 會按場地提供這些報告。
• 資料所有權。 合約應明確規定訪客資料屬於您的第一方資料，並可在退出時完整匯出。

平台、安全性與合規要求

• 認證。 要求提供現行的 ISO 27001 證書，以及用於英國公營部門業務的 Cyber Essentials。Purple 擁有 ISO 27001 和 Cyber Essentials 認證，並符合 GDPR 與 CCPA 規範。
• 正常運行時間。 將承諾寫入 SLA 中。Purple 公佈的平台正常運行時間為 99.999%。
• 管理者登入。 SAML（安全斷言標記語言）允許您的團隊使用其目錄帳戶登入控制面板。請將其與按據點劃分的管理者角色搭配使用。
• 無線測試證明。 PCI DSS v4.0 要求 11.2.1 規定您至少每三個月檢測授權與未授權的無線基地台一次。請詢問平台或您的控制器對此提供哪些報告。

檢查清單一覽

領域	必要要求	需要求的證明	危險訊號（Red-flag）答案
員工身份驗證	採用 EAP-TLS 或 PEAP 的 IEEE 802.1X	針對您的 Microsoft Entra ID、Okta 或 Google Workspace 租戶進行現場演示	"使用強大的共享密碼"
員工裝置	每台裝置採用 iPSK 或 PPSK	單一網路名稱上的兩台裝置使用獨立金鑰	"將印表機放在訪客網路上"
離職人員處理	目錄同步與自動撤銷	停用測試帳戶並計算斷線時間	"管理者手動刪除帳戶"
訪客導覽	具備電子郵件、社群和簡訊選項的 Captive Portal	在最新的 iOS 與 Android 版本上登入	Portal 僅在桌面端顯示
無縫回訪	Passpoint 與 OpenRoaming	回訪裝置無需 Portal 即可重新連線	"在開發藍圖中"但無具體日期
內容過濾	按網路設定 DNS 類別原則	在大廳與會議網路上進行已封鎖類別的測試	所有網路使用同一套原則
規避過濾	DoH 與自訂 DNS 處理	使用設定為 DoH 的瀏覽器進行測試	對 DoH 沒有回應
同意	單獨且未勾選的行銷同意訂閱	包含時間戳記的匯出同意紀錄	將同意訂閱與使用條款綑綁
資料所有權	訪客資料是您的第一方資料	合約條款與匯出格式	廠商跨客戶重複使用資料
合規性	ISO 27001、GDPR、PCI-DSS 網路區隔	現行憑證與資料處理合約	憑證「辦理中」

在簽約前，您該如何測試廠商的回答？

書面回答總是拿高分。在單一據點進行概念驗證 (PoC) 才能展現實際狀況。請對每家入圍廠商執行以下六項測試。

1. 入職測試。 在您的目錄中建立員工帳號。記錄該員工需要多久時間才能連上員工網路。
2. 離職測試。 停用該帳號。詢問該平台是傳送 RADIUS 授權變更 (RFC 5176) 來結束使用中的工作階段，還是等待重新驗證。
3. 訪客登入測試。 使用現有的 iPhone、Android 手機以及筆記型電腦登入。記錄每次失敗與每一次多餘的點擊。
4. 過濾測試。 在大廳網路造訪被封鎖的類別，然後在會議網路造訪。將瀏覽器設定為 DoH 後重複測試。
5. 同意測試。 在一台裝置上同意，在另一台裝置上拒絕。然後像處理當事人存取請求一樣，要求調閱這兩筆記錄。
6. 網路區隔測試。 從訪客裝置嘗試連線至員工印表機和 POS 機位址。兩次嘗試都應該失敗。

將每項測試評為通過或失敗。在評估期間無法執行這些測試的廠商，在得標後也無法執行。

這在真實的飯店物業中運作狀況如何？

擁有 200 間客房且簽訂三份 WiFi 合約的城市飯店

背景。 該飯店透過其寬頻提供者搭售的 Captive Portal 運作訪客存取。員工使用一個共享密碼，每季輪替一次。另一家獨立廠商提供 DNS 過濾。訪客電子郵件以每月試算表匯出的方式提供給行銷團隊，且沒有同意時間戳記。

做法。 飯店根據上述檢核表發布了一份 RFP。要求具備來自 Microsoft Entra ID 的目錄同步、適用於印表機和電視的 iPSK、按網路設定的 DNS 策略，以及每筆記錄上的時間戳記同意。

結果。 三份合約合併為一份。離職者的存取權限以往最長可維持 90 天（直到下次密碼輪替），現在只要帳號被停用就會立即結束。每筆行銷記錄都帶有同意時間戳記，因此當事人存取請求只需透過單一匯出檔案即可處理。

使用混合硬體的 40 個物業集團

背景。 一家飯店集團有 28 個物業採用 Cisco Meraki，另有 12 個收購的物業採用 Ruckus。其最初的入圍名單假設需要兩個平台，每個硬體廠商各一個。

做法。 RFP 指定了這兩家硬體廠商，並要求單一平台同時支援兩者。它還要求在整個物業範圍內使用單一過濾策略集和一個訪客資料庫。

結果。 現在單一儀表板即可涵蓋所有 40 個物業。沒有更換任何無線基地台。大廳的過濾變更現在只需透過一次變更即可套用到整個物業，而不需要針對每個廠商進行兩次變更。

市議會營運的會議暨展覽中心

背景。 一個公部門場館在相同的展廳舉辦學校假期活動與商業展覽。單一嚴格的過濾機制封鎖了參展商進行現場示範所需的網站。

執行的內容： 場館在相同的存取點上運作兩個訪客網路。公共大廳套用嚴格的 DNS 策略，並封鎖了 IWF 清單。參展商則在活動當天憑證的防護下，套用較寬鬆的策略。RFP 同時要求符合 Cyber Essentials。

成果： 目前在同一套存取點上運作兩種策略，無需新增硬體。員工可直接從儀表板針對每次活動切換策略，無需重新設定控制器。

飯店 WiFi RFP 常出現哪些問題？您該如何解決？

RFP 分屬於三個不同部門

IT 部門撰寫員工部分，行銷部門撰寫訪客部分，而完全沒有人撰寫過濾規則。廠商隨後回覆了三份不同的文件。解決方案： 指定一位負責人，並在單一評分模型中對這三個部分設定權重。

同意條款與使用條款綑綁在一起

單一「我同意」核取方塊同時涵蓋了 WiFi 存取權與行銷用途。這種同意方式不太可能符合 GDPR 第 7(4) 條。解決方案： 要求提供獨立且未預設勾選的訂閱選項，並在概念驗證 (PoC) 期間進行測試。

共享的員工密碼在招標後依然存在

某些廠商會建議員工使用共享金鑰，因為這樣設定非常快速。解決方案： 將 802.1X 或 iPSK 列為強制性要求，而非僅作為評分加分項。

過濾器在第一天就被繞過

預設使用 DoH 的瀏覽器可以完全跳過 DNS 過濾。解決方案： 將 DoH 測試納入評估，並要求針對強制執行方式提供書面說明。

Captive Portal 在手機上無法運作

針對桌上型電腦設計的 Portal 經常在 iOS 與 Android 的 Captive 微型瀏覽器中崩潰。解決方案： 在最新的手機上進行測試，並將登入失敗直接評為不合格。

硬體綁定隱藏在評分標準中

某些回覆內容暗中假設您會購買該廠商自家的存取點。解決方案： 在 RFP 中明確列出您的硬體，並要求提供書面支援承諾。場館與企業在 2026 年的網路最佳做法 涵蓋了更廣泛的設計選擇。

各種採購方案的比較為何？

作法	需管理的合約數量	是否需要新硬體	典型的員工身分驗證來源	誰持有訪客資料	適用對象
硬體廠商內建的 Captive Portal	每個硬體廠商 1 份	更換廠商需全面替換	在廠商儀表板中管理的帳戶	硬體廠商的雲端	使用單一硬體廠商且無行銷目標的單一物業
RADIUS、過濾與訪客 Portal 採用獨立的專業廠商	3 份	不需要	透過指令碼或人工同步的 RADIUS 伺服器	Portal 廠商（依其自身條款）	擁有內部工程人員，可整合並修補各個系統的集團
單一雲端覆蓋層（如 Purple）	1 份	在 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 或 Fortinet 上不需要	Microsoft Entra ID、Okta 或 Google Workspace	您（作為第一方資料）	希望在員工與訪客之間建立單一稽核軌跡的多物業集團

費用是多少？您能獲得什麼回饋？

如何定價

要求每家廠商針對四個項目分別報價，以便在相同的基礎上進行比較。

• 平台授權。 Purple 提供三種方案：Connect、Capture 和 Engage。資安擴充模組 SecurePass、Verify 與 Shield 則在此基礎上疊加。請要求廠商將 RFP 的每項需求對應到指定的方案或擴充模組，避免得標後報價產生變動。
• 硬體。 在支援的無線基地台 (AP) 上，覆蓋網路無需新添硬體。任何需要更換硬體的廠商都應提供完整報價。
• 整合。 目錄服務、CRM 與行銷平台的連線。確認每項整合由誰建置，以及由誰維護。
• 內部時間成本。 計算團隊目前在定期更換密碼、移除離職員工權限以及匯出試算表上所花費的時數。

您獲得的效益

• 減少合約數量。 單一平台即可取代分立的員工、訪客與過濾服務廠商，並具備統一的續約日期與單一資料處理協議。
• 更快撤銷存取權限。 存取權限會隨目錄帳號停用而立即終止，從而縮短前員工可利用的漏洞窗口。
• 第一方訪客資料。 每個獲得同意的電子郵件地址，都是您可以直接行銷的對象，無需再透過線上旅遊平台 (OTA)。
• 造訪洞察。 每個據點的回訪率與停留時間，能協助您評估投資方向。

Purple 自 2012 年起即與各類場域合作。包括 Whitbread、Premier Inn 與 Stonegate Pubs 在內的飯店餐飲集團皆採用 Purple，且 Purple 為認證的 B 型企業 (B Corp)。請參閱 飯店 以取得飯店餐飲業的詳細資訊。

相同的架構亦適用於 零售 園區、醫療照護 院區與 鐵路。針對交通樞紐，請閱讀 機場 WiFi 平台供應商：RFP 中應包含哪些需求。

常見問題

飯店 WiFi 軟體如何計價？

Purple 是依方案與擴充模組計價，而非依硬體數量。三種方案為 Connect、Capture 與 Engage，並可以搭配 SecurePass、Verify 與 Shield 作為資安擴充模組。您的報價會反映所需的方案、擴充模組與據點數量。在任何 RFP 中，請要求每家廠商將各項需求對應到指定的方案或擴充模組。這能防止簽約後功能被移至更高的層級，並使各家競標報價能夠直接進行比較。

Purple 可以在我們現有的無線基地台 (AP) 上運行嗎？

可以，Purple 能夠以雲端覆蓋網路的形式運行於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 與 Fortinet 硬體上。您可保留現有的無線基地台與控制器，由 Purple 在其上提供身分驗證、過濾與訪客資料擷取功能。混合架構同樣適用，因此在部分飯店使用 Cisco Meraki、其他飯店使用 Ruckus 的集團也可以運行單一平台。請在 RFP 中列出您的硬體，並要求每家廠商以書面形式確認支援。

我們如何將訪客資料從現有的 Captive Portal 供應商移轉出來？

僅轉移具有可證明同意記錄的資料。要求您目前的供應商提供完整匯出檔案，其中必須包含同意時間戳記以及每位訪客同意的具體字樣。沒有可證明同意日期的記錄不應進入新的行銷資料庫。先在一家物業試行新平台，檢查 CRM 欄位對應，然後逐一物業推廣。在給出終止通知前，當現有供應商仍受合約約束時，請以書面形式確認匯出事宜。

透過 WiFi 收集訪客資料是否符合 GDPR？

是的，前提是同意聲明是獨立、特定且已被記錄的。GDPR 第 7(4) 條規定 WiFi 存取權不能取決於行銷勾選，因此行銷勾選必須是一個獨立且未預先勾選的選項。Purple 採用主動選擇的同意機制，為每個個人檔案儲存帶有時間戳記的同意記錄，並擁有 ISO 27001 認證。在英國，PECR 也適用於電子郵件和簡訊行銷。在評估期間，可要求任何廠商出示匯出的同意記錄。

DNS 過濾對飯店訪客 WiFi 來說足夠嗎？

只要能防止繞過，DNS 過濾就能滿足公共區域的主要需求。它可以在不檢查加密流量的情況下封鎖類別和清單 - 例如 IWF URL 清單。它的弱點是 DNS over HTTPS，這可能會將查詢繞過您的解析器。要求提供針對 DoH 和自訂 DNS 處理的書面解答，並在概念驗證期間進行測試。請為大廳、會議廳和員工網路設定獨立的策略。

我們應該向硬體廠商購買訪客 WiFi，還是選擇獨立的平台？

如果您營運多家硬體廠商的設備，或者希望擁有屬於自己的訪客資料，請選擇獨立的平台。內建的 Captive Portal 適合使用單一廠商且沒有行銷目標的單一物業。與硬體無關的平台能在設備更新時保持您的選擇彈性。它還能將員工身分驗證、過濾和訪客同意紀錄整合在單一稽核軌跡中。對照對照表比較兩者，為各項需求評定合格或不合格。

飯店 WiFi 部署需要投入多少精力？

大部分的工作量集中在整合和策略決策，而非硬體。在支援的存取點上不需要更換任何設備，因此工作重點是連接您的目錄、CRM 和過濾策略。在部署開始前，請與您的資料保護官（DPO）確認過濾類別和同意條款字樣。在一地區物業進行概念驗證，完成本指南中的六項測試，然後按照計劃分批推廣至整個物業資產。