白標 Captive Portal 軟體：MSP 和經銷商在簽約前應檢查的事項

白標 Captive Portal 軟體可讓 MSP 或經銷商以自己的品牌銷售訪客 WiFi 登入頁面。在簽約前，請務必確認六件事：具備委派管理的真正多租戶架構、涵蓋網域、電子郵件和報告的品牌化、支援您安裝的每個無線存取點（AP）廠商、保護利潤的計費模式、客戶擁有的 GDPR 同意記錄，以及完善的 API 文件。

您應該選擇哪種白標 Captive Portal 模式？

Captive Portal 是裝置在網路授予網際網路存取權限之前看到的網頁。IETF 在 RFC 8952 中規範了此架構，而 RFC 8908 則定義了告知裝置存在 Portal 的 API。

白標 Captive Portal 軟體讓您能夠以自己的品牌銷售該登入頁面。背後的控制台和報告也會帶有您的品牌。

經銷商市場主要由三種商業模式主導。它們在三點上有所不同：

• 誰持有客戶合約
• 您的品牌涵蓋範圍有多廣
• 每個客戶資料的隔離程度有多乾淨

請先選擇模式，然後在該模式下評估廠商。

模式	您的品牌出現在	客戶資料隔離	誰持有客戶合約	典型計費方式	適合對象
完全白標、多租戶	登入頁面、自訂網域、管理控制台、電子郵件、簡訊和報告	每個客戶獨立租戶，具備權限控管的管理員角色與 API 金鑰	您	按案場或按存取點計算的批發價，零售價由您決定	擁有服務台（Service Desk）和場域客戶組合的 MSP
雙品牌經銷	僅登入頁面和電子郵件；控制台與報告顯示廠商品牌	單一共享帳戶內的子帳戶或資料夾	您或廠商	廠商建議售價減去經銷商折扣	將訪客 WiFi 附加到硬體銷售中的經銷商
轉介或直接合約	全程顯示廠商品牌；您僅作為安裝商出現	客戶自己的廠商帳戶	廠商	廠商建議售價；您賺取轉介費或服務收入	執行一次性專案且無支援服務台的夥伴

大多數擁有支援服務台和多個場域客戶的 MSP 都會選擇第一種模式。本指南的其餘部分將假設採用該模式，並向您展示如何驗證廠商宣稱的功能。

白標 Captive Portal 平台的真正差異何在

每個廠商的示範都會展示帶有品牌的登入頁面。真正的差異位在底層，主要體現在六個領域。這些領域共同決定了您的利潤、合規風險以及支援負擔。

真正的多租戶架構與委派管理

真正的多租戶架構意味著每個租戶服務一個客戶。資料、設定、管理員帳戶和 API 金鑰均在平台層級進行隔離。共享帳戶內的資料夾並非租戶。如果設定錯誤的角色導致某個客戶的訪客名單洩漏給另一個客戶，您將需要承擔違規責任。

請在試用租戶中測試委派管理，而非僅看簡報。您至少需要四種角色：

• 您自己的超級管理員
• 客戶管理員
• 限制管理單一場地的場地管理員
• 唯讀的行銷角色

飯店總經理應該只能看到自己營運的飯店，看不到其他內容。

要求透過 SAML 2.0（用於聯合登入的 OASIS 標準）進行單一登入。此功能應支援 Microsoft Entra ID、Okta 和 Google Workspace。

SCIM 2.0（跨領域身分管理系統，RFC 7643 與 RFC 7644）可自動建立和移除管理者帳號。若缺乏此功能，離職人員在有人想起處理前都將持續擁有控制台存取權限。請確認每個租戶均保留稽核記錄且可匯出，以便向客戶說明變更內容與相應操作者。

品牌化深度：網域、寄件者電子郵件、入口網站和報表

品牌化深度是大多數宣稱「白標」的產品力有未逮之處。請針對訪客或客戶可能看到的每個介面進行評分：

• 登入頁面網域。 Captive Portal 應載入自您的網域或客戶的網域。供應商應自動展延其 TLS 憑證。
• 管理控制台。 您的標誌、配色和 URL 應顯示於登入畫面。若使用帶有供應商品牌的控制台，無異於直接告訴客戶續約時該聯絡誰。
• 寄件者電子郵件。 驗證碼和行銷電子郵件必須從您的網域發送。這需要設定與您網域對齊的 SPF (RFC 7208)、DKIM (RFC 6376) 和 DMARC (RFC 7489)，否則訊息將落入垃圾郵件匣。
• 簡訊寄件者 ID。 驗證簡訊應顯示您或場地的名稱，絕不該顯示供應商名稱。
• 報表。 排程匯出與儀表板應帶有您的品牌標示，且無供應商浮水印。若您轉售 WiFi Analytics，每月報表就是客戶實際看到的產品。
• 說明連結和狀態頁面。 控制台連結應指向您的知識庫，或完全不放置連結。

個別租戶範本也相當重要。酒吧集團與地方議會所需的登入流程、同意條款字樣及語言皆不相同。

已安裝基礎架構的硬體涵蓋範圍

您的客戶早已擁有無線基地台，且很少只來自單一供應商。請要求列出明確支援的清單與管理平台：Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 和 Fortinet。「支援所有主流供應商」只是一句警訊，並非明確的答案。

支援的意義不只是轉址。請確認對各供應商皆具備以下四種能力：

• 外部 Captive Portal 轉址
• RADIUS (Remote Authentication Dial-In User Service, RFC 2865) 身分驗證
• 用於會話資料的 RADIUS 計費 (RFC 2866)
• 用於社群和支付登入的圍牆花園 (Walled Garden) 設定

要求供應商針對每個品牌提供已發布的整合指南。然後在您客戶實際運行的韌體版本上進行測試。

硬體涵蓋範圍也能在硬體升級週期中保護您的投資。雲端覆蓋層獨立於網路架構之上，因此客戶即使更換無線基地台供應商，也不會改變訪客體驗。對於任何正在評估 Planning a WiFi 6 to WiFi 7 access point refresh when Cisco Meraki WiFi 6 reaches end of sale 的企業場域而言，這點至關重要。

Purple 的 Guest WiFi 可作為硬體無關的雲端重疊圖層，在上述所有八家廠商的設備上執行。背景資訊請參閱 為什麼您下次的 WiFi 升級不需要新硬體。

某些客戶需要的可能不只是訪客存取。請詢問平台是否支援 802.1X（基於連接埠之網路存取控制的 IEEE 標準）。同時也詢問 iPSK（身分預共用金鑰），這能賦予每個裝置或人員專屬的 WiFi 金鑰。如果您要新增員工存取權限，請將 Windows 11 802.1X 驗證問題排解：企業 IT 指南 備妥供參考。

Passpoint（也稱為 Hotspot 2.0）可讓再次光臨的訪客免透過 Captive Portal 即可自動重新連線。OpenRoaming 作為無線寬頻聯盟（Wireless Broadband Alliance）的同盟，也能在參與的網路之間實現相同功能。缺少這些功能的平台，將會限制您日後可銷售的服務範疇。

您客戶擁有的 GDPR 同意紀錄

根據 GDPR，您的客戶（場館營運商）通常是訪客資料的控管者（第 4(7) 條）。您充當處理者，而平台廠商則是您的次處理者。第 28 條要求該鏈結中的每個環節都必須簽署書面合約。第 28(2) 條禁止處理者在未取得控管者事前書面授權的情況下委任次處理者。

第 7(1) 條要求控管者必須能證明已取得同意。這意味著每個訪客都必須有一份完整紀錄：

• 時間戳記
• 顯示的確切措辭
• 隱私權聲明版本
• 管道
• 已接受的目的

僅標示「已勾選行銷」的旗標是不夠的。序文 32 補充說明預先勾選的方塊不視為有效同意。針對英國的電子郵件與簡訊行銷，同意事項還必須符合《隱私與電子通訊條例》（PECR）。

簽約前請確認以下三點合約條款：

1. 廠商未聲稱可將訪客資料用於自身目的。若有，廠商即成為控管者，且您客戶的隱私權聲明必須明確載明這一點。
2. 第 28(3)(g) 條要求在合約結束時歸還或刪除個人資料。請以書面形式確認匯出格式、時程與費用。
3. 廠商會公布次處理者名單並在有變更時通知您，以便您轉達通知給客戶。

Purple 在登入流程中建置了自願選擇的同意機制，因此每位訪客都是主動選擇接受行銷。Purple 通過 ISO 27001 認證並符合 GDPR 規範。

API 與 Webhook 存取權限

API 決定了您可以建置多少自己的服務。請索取已提供文件的 REST API，並將金鑰存取範圍限定於單一租戶。如此一来，即使單一金鑰遭破解，也不會波及所有客戶。針對租戶、場館與 Captive Portal 範本的批量 API 端點，能讓您透過指令碼自動化完成上線流程，免去手動點擊的繁瑣。

Webhook 會在事件發生時（例如訪客登入或新增同意），立即將事件推送到您客戶的 CRM。請確認以下三點：

• Payload 經過數位簽章，使接收者能驗證傳送者身分
• 傳送失敗時會自動重試
• 速率限制以及 API 存取的任何額外費用均已透過書面確認

技術支援升級機制

在白標平台上，您是第一線技術支援。場域會直接聯繫您，且供應商絕不能直接聯繫您的客戶。這使得供應商的第二線支援途徑成為您最重要的服務條款。

請將以下項目寫入合約中：

• 明確定義的嚴重性等級
• 各等級的相應處理目標時間
• 指定的合作夥伴聯絡人
• 針對場域系統宕機事件，提供直通工程團隊的快速管道

第 33(2) 條規定，處理者必須在沒有不當延誤的情況下通知控制者資料外洩事件。您與供應商的合約必須提供足夠快的通知速度，以便您能向客戶履行該項責任。

同時也請要求提供規模實證。Purple 在 2024 年處理了超過 90 個國家、80,000 多個上線場域中的 4.4 億次登入（資料來源：Purple 內部數據）。

何時選擇完全多租戶白標平台最為合適

當您全權維繫客戶關係時，請選擇完全白標方案。這通常意味著具備以下三個條件：

• 您營運維運服務台（service desk）
• 您按月向客戶按期計費
• 您擁有跨領域的多個場域客戶

訪客 WiFi 隨即成為您自家帳單上的一項定期收費項目。

它也適用於混合硬體設備環境。一個獨立於硬體的通用平台即可取代多個特定廠商的控制台。您的工程師只需學習一套系統，且每個客戶的報表樣式皆保持一致。

實例情境：擁有兩家硬體供應商的區域飯店集團

背景。 某 MSP 為一家擁有 14 家飯店的區域集團管理訪客 WiFi。其中九家飯店採用 Cisco Meraki。前一年收購的五家飯店則採用 Ruckus，共有 210 個無線基地台。該 MSP 原本列入候選名單的 Captive Portal 僅支援 Meraki。

處理方式。 該 MSP 將候選名單調整為不限硬體的通用平台，並在涵蓋這兩家硬體廠商的兩家飯店進行試行計劃。它為該集團建立了一個租戶，並將每家飯店設為單一場域。總經理獲得僅限該場域的管理權限；集團行銷主管則獲得跨全部 14 家飯店的唯讀報表權限。

結果（示意數據）。 所有 210 個 Ruckus 無線基地台均繼續留用而無須替換。該集團在所有物業中採用了統一的登入設計、一致的同意聲明字樣以及單一的月度報表。

如需進一步瞭解該產業的資訊，請參閱 飯店 與 餐廳 WiFi：英國涵蓋範圍與安全性指南。

何時選擇共同品牌或直接合約最為合適

完全白標並不總是值得投入這些管理成本。您可能會將訪客 WiFi 作為硬體專案的一次性附加產品來銷售。在這種情況下，共同品牌帳戶或轉介合作會更簡單，同時可避免為您不想長期營運的產品提供第一線支援。

直接簽約適合擁有內部 IT 團隊的大型單一客戶，例如全國性的 零售 連鎖店。他們的採購團隊可能更傾向於直接與供應商簽約。受監管領域的客戶（例如 醫療保健）通常也會自行執行供應商審查。

您依然可以從安裝、網路管理和場地勘測中獲利。WiFi 場地勘測：實用規劃指南 涵蓋了這些基礎工作。

白標 Captive Portal 軟體的計價方式

主要有三種計費單位：按場地、按 Access Point 以及按訪客。大多數廠商採用批發銷售，並由您自訂零售價格。您的利潤空間與折扣關係不大，更多取決於您的計費單位是否與廠商一致。

計費模式	計費依據	成本可預測性	您面臨的主要風險	最適合的場景
按場地	每個場館，無論規模大小	高：僅在場館增加或減少時變動	小型場地的成本與大型場地相同	連鎖相似場地：酒吧、快餐店、商業街零售店
按 Access Point	每個託管的 Access Point	高：僅在硬體專案變更時變動	高密度部署或 WiFi 7 升級會增加授權費用	體育場館、會議中心和其他有出席高峰的場地
按訪客	每月每個通過驗證的訪客	低：隨出席人數波動	除非設有上限，否則活動高峰會導致帳單暴增	試點專案、季節性場地和低流量場地

最安全的結構是用廠商向您計費的相同單位來向客戶計費。如果您按 Access Point 付費卻按場地收費，每次高密度部署專案都會侵蝕您的利潤。

在簽約之前，請檢查以下四項額外成本：

• 最短合約期限
• 年度調漲條款
• API 存取權或額外租戶的費用
• 簡訊驗證，這通常不包含在授權費用內

實例情境：活動高峰驅動的會議中心

情況。 一家經銷商為擁有 120 個 Access Point 的會議中心提供訪客 WiFi 報價。每月出席人數從淡季的約 3,000 名訪客到大型展覽期間的 45,000 名訪客不等。

處置方式。 第一家廠商按訪客計費。經銷商模擬了 12 個月的出席人數，發現發票金額相差高達 15 倍。因此改用按 Access Point 計費的廠商，並向場館收取固定的月費。

結果（示意數據）。 授權項目每個月都維持在 120 個 Access Point，因此每月成本變動降至零。場館預算有了固定的年度金額。經銷商的利潤不再受活動日程影響。

如何為您的業務作出決定：RFP 提問與警訊

向每家入圍的廠商發送相同的問題，並要求書面答覆。然後在測試租戶中驗證關鍵項目。

應發送的 RFP 問題

1. 每個客戶是否都是獨立的租戶，具有隔離的資料、設定、管理者帳號和 API 金鑰？
2. 存在哪些管理角色？角色能否限制在單一場館內？
3. 您是否支援 Microsoft Entra ID、Okta 和 Google Workspace 的 SAML 2.0 單一登入，以及 SCIM 佈署？
4. Captive Portal、主控台、寄件者電子郵件、簡訊寄件者 ID 和報告是否都可以標示我們的品牌？
5. 誰負責發行和更新自訂網域的 TLS 憑證？
6. 您支援哪些無線存取點（Access Point）廠商？是否為每家廠商提供整合指南？
7. 您是否支援 RADIUS 認證與計帳、802.1X、iPSK、Passpoint 和 OpenRoaming？
8. 計費單位、最短合約期和每年調漲幅度為何？
9. SMS、API 存取或額外租戶的費用如何計算？
10. 您是否會將訪客資料用於您本身的任何用途？
11. 同意紀錄包含哪些內容？我們的客戶可以透過哪些格式匯出？
12. 合約結束時，您如何以及何時歸還或刪除資料？
13. 您在哪裡公布次處理者名單？如何通知變更？
14. 您的事件嚴重性等級與回應目標為何？發生資料外洩時，多久內會通知我們？
15. 您的 ISO 27001 驗證範圍為何？

簽約前應警惕的危險訊號

領域	良好標準	危險訊號
多租戶架構	每個客戶都有獨立租戶，資料與 API 金鑰完全隔離	所有客戶共享同一個帳戶，僅以資料匣區分
品牌推廣	入口網站、控制台、電子郵件、SMS 與報表皆使用您的網域	電子郵件、控制台網址或報頁尾出現廠商名稱
硬體	明確列出支援的廠商，且每家皆有公布的整合指南	僅標示「支援所有主要廠商」卻無具體清單
計費	計費單位符合您向客戶收費的方式，且設有調漲上限	未設上限的按訪客計費，或僅最高階方案支援 API 存取
訪客資料	客戶為資料控制者；廠商僅依指示處理資料	廠商保留自行使用訪客資料的權利
退出機制	在約定期限內將同意紀錄匯出為 CSV 或 JSON	僅限依要求匯出、需收取費用或使用專有格式
技術支援	具備嚴重性等級、回應目標與指定的呈報聯絡人	僅提供工單表單，且未定義回應時間
實例情境：縣市政府更換經銷商

背景。 一家經銷商為縣市政府營運涵蓋 22 所圖書館與休閒中心的訪客 WiFi。在重新招標時，市府選擇了不同的供應商。其活動團隊握有約 38,000 名訪客同意接收最新消息的紀錄。

處理方式。 該經銷商與廠商的合約中包含符合第 28(3)(g) 條的退出條款。該條款要求在 30 天內匯出每筆同意紀錄的 JSON 檔案，並包含時間戳記、條款版本與管道。

結果（示意數據）。 市府將全部 38,000 筆同意紀錄匯入新平台，並可在無需重新取得許可的情況下繼續向訪客發送電子郵件。經銷商則在取得資料已刪除的書面確認後顺暢退出。

常見問題

什麼是白標 Captive Portal？

白標 Captive Portal 是一種訪客 WiFi 登入軟體，MSP 或經銷商可以掛上自己的品牌進行銷售。廠商負責營運平台，而您的標誌、網域、寄件者電子郵件與報表則直接面向客戶。最優質的平台還具備真正的多租戶架構，讓每個客戶都擁有獨立隔離的租戶，並可為場地管理員與行銷團隊分配委任管理角色。

MSP 能否將 Captive Portal 打造為自家品牌？

是的，前提是該平台提供完整的品牌深度。登入頁面應從您的網域載入，並附上有效的 TLS 憑證。電子郵件應從您的網域傳送，並符合 SPF、DKIM 及 DMARC 規範。管理主控台和報表中不應出現任何供應商資訊。如果品牌客製化僅止於登入頁面，您的客戶每個月仍然會看到供應商的名稱。

白標 Captive Portal 軟體如何計費？

大多數供應商按案場、按 Access Point 或按訪客計費，並以批發價銷售，以便您自行制定零售價格。按案場計費適合連鎖型態的類似場地。按 Access Point 計費適合人潮高峰期流量較大的場地。按訪客計費適合試行和低流量案場，但費用會隨需求波動。為保障利潤，請以供應商向您向收費的相同單位向客戶計費。

白標 Portal 必須支援哪些 Access Point？

它必須支援您客戶現有網路中的每個供應商品牌：Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet。針對每一個品牌，請確認其支援外接 Captive Portal 重導向、RADIUS 認證與計費，以及 Walled Garden 功能，並提供已公開發布的整合指南。Purple 的 Guest WiFi 作為跨硬體的雲端覆蓋層，可在所有這八種硬體上運行。

在經銷商平台上，訪客資料歸誰所有？

您的客戶（即場地營運商）應作為 GDPR 規範下的資料控制者擁有訪客資料。您擔任處理者，而平台供應商則為次處理者，各方均受第 28 條合約條款約束。請拒絕允許供應商將訪客資料用於其自身目的之條款。同意紀錄應能依需求匯出，並在合約結束時歸還給您的客戶。

客戶轉移到新的 Captive Portal 平台需要購買新硬體嗎？

不需要，前提是該平台具備跨硬體相容性。雲端覆蓋層可以使用外接 Captive Portal 重導向與 RADIUS，直接連線至您客戶現有運行的 Access Point。您只需要重新設定網路以指向新平台，而無需更換設備。在排定切換時程之前，請先在您客戶實際運行的韌體版本上進行測試。

您能否將現有客戶從另一個 Captive Portal 平台遷移過來？

可以，只要您目前的供應商能以可用的格式匯出每個客戶的同意紀錄與訪客資料。請引用 GDPR 第 28(3)(g) 條，要求提供包含時間戳記、同意內文與管道的 CSV 或 JSON 匯出檔。在新租戶中重新建置 Portal 範本，並在試行場地同時運行兩個平台。隨後分批切換其餘案場，以降低風險。