Salesforce 與 Guest WiFi 整合，實現客戶情報

播客腳本 — 「Salesforce 與 Guest WiFi 整合，實現客戶情報」 Purple 技術簡報系列 | 長度：約 10 分鐘 | 英式英語 --- [引言與背景 — 1 分鐘] 歡迎收聽 Purple 技術簡報系列。我是主持人，今天我們要深入探討許多 B2B 組織已在規劃中但尚未徹底解決的議題：將您的 Guest WiFi 基礎架構直接連接到 Salesforce，以產生真實的客戶情報。 若您擁有一個場域——會議中心、飯店、展覽會場、企業園區——並且運行著 Guest WiFi，您正坐擁著豐富的第一方意圖資料礦。每當潛在客戶、合作夥伴或客戶連上您的網路，他們都在傳達某些訊息。他們在現場。他們正在參與。而目前，對大多數組織而言，該訊號都消失在空氣中。 今天我們將探討如何改變這一切。如何將 WiFi 驗證事件傳遞至 Salesforce，與您現有的客戶進行比對，並觸發適當的商業回應——無論是發送警示給客戶經理、充實聯絡人記錄，還是為您的 RevOps 團隊標記以採取行動。 這是一場實用簡報。我們將逐一探討架構、資料模型決策、GDPR 考量以及常見陷阱。讓我們開始吧。 --- [技術深度探討 — 5 分鐘] 我們先從架構開始。Salesforce WiFi 整合的核心有三個組成部分：Captive Portal 層、整合中介層與 Salesforce 資料模型。 Captive Portal——也就是您的訪客連線時看到的頁面——是身份擷取發生的地方。當訪客透過電子郵件、LinkedIn 或社群登入進行驗證時，平台會擷取已驗證的電子郵件地址、時間戳、場域識別碼與同意記錄。最後一項在 GDPR 與《2018 年英國資料保護法》下是不可妥協的。您需要針對行銷通訊取得明確、細分的同意，且該同意記錄必須儲存並可稽核。Purple 平台原生處理此項，在驗證的當下擷取同意，並將同意旗標連同聯絡資料傳遞至 Salesforce。 接著，整合中介層是情報發生的地方。Purple 的整合引擎接收該驗證事件，並執行我們所謂的身份解析。第一步是網域比對：取得電子郵件地址，擷取網域——例如 acme-corp.com——並查詢 Salesforce 中任何具有相符網站或電子郵件網域欄位的客戶記錄。這是您主要的比對訊號。 若找到網域相符，中介層會接著檢查該特定電子郵件地址是否已存在聯絡人記錄。若存在，則更新現有記錄——記錄一筆新活動、更新最後出現時間戳、增加造訪計數器。若不存在聯絡人但客戶存在，則建立新的聯絡人並將其關聯至該客戶。若兩者都不存在——網域未知——則建立潛在客戶記錄並標記以供審核。 此三路徑路由邏輯，是為 WiFi 來源聯絡人建立乾淨 Salesforce 資料模型的基礎。另一種做法——不論情境一律推送為潛在客戶——會造成大多數 RevOps 團隊恐懼的資料品質惡夢：數千筆重複潛在客戶、沒有客戶關聯，以及客戶經理遺漏其現有業務的訊號。 讓我更詳細地談談 Salesforce 資料模型，因為您在此所做的欄位對應決策具有長遠影響。 在潛在客戶物件上，您要擷取：WiFi 場域名稱、首次出現日期、最後出現日期、造訪次數、同意狀態，以及設定為標準化值（如「Guest WiFi」）的來源。在聯絡人物件上，同樣的欄位適用，外加對父客戶的查閱。在客戶物件上，您需要一個彙總摘要欄位，顯示 WiFi 驗證的聯絡人總數、最後訪客日期欄位，以及造訪頻率分數。這些客戶層級的欄位，正是讓此整合對客戶導向銷售真正有用的關鍵。 現在，談談警示機制。這就是商業價值變得有形的地方。使用 Salesforce Flow——若您使用較舊的組織，則用 Process Builder——根據特定條件設定觸發條件。最有價值的警示是我們所謂的「目標客戶造訪」觸發條件：當與標記為目標客戶之客戶關聯的聯絡人，在您的 WiFi 驗證時，指定的客戶經理會在幾分鐘內收到 Salesforce 任務與 Chatter 通知。訊息很簡單：「來自 Acme Corp 的 James 剛剛在您的曼徹斯特場域連線。他們本季已造訪三次。」 這是一個大多數銷售團隊寧願花大錢獲取的溫暖接觸訊號。而您正被動地從您既有的基礎設施中產生它。 另一個值得設定的警示是「重新參與」觸發條件：已沉靜超過九十天的聯絡人連上您的 WiFi。這會浮現出那些實際上回到您範圍內的流失或冷淡聯絡人——這是續約對話的強烈訊號。 第三，「新網域」警示：來自與任何現有客戶都不相符之電子郵件網域的 WiFi 登入。這會傳遞給 BDR 或 RevOps 佇列進行資格確認。並非每個未知網域都是潛在客戶，但篩選出公司網域——排除 Gmail、Outlook 和其他消費者提供商——能提供您高品質的潛在客戶開發訊號。 在技術整合方面，Purple 公開 REST API 並支援傳出的 Webhook。針對 Salesforce 整合的建議模式是 Webhook 到中介層的做法：Purple 在每次驗證事件時觸發 Webhook，一個輕量級的中介層——可以是 Salesforce Connected App、MuleSoft 流程或簡單的 AWS Lambda 函式——接收承載資料、執行網域比對邏輯，並呼叫 Salesforce REST API 來 upsert 適當的記錄。這將邏輯保留在 Salesforce 之外，使其更容易獨立維護與測試。 對於擁有 Salesforce MuleSoft Anypoint Platform 的組織，Purple 的 API 文件提供預建置的連接器範本。對於沒有 MuleSoft 的組織，一個指向 Purple API 的 Salesforce 外部服務定義，結合 Flow，無需自訂程式碼就能達到相同結果。 再一項技術考量：MAC 位址隨機化。現代 iOS 與 Android 裝置在每次網路連線時會隨機化其 MAC 位址，這意味著您無法使用 MAC 位址作為返回訪客追蹤的持久裝置識別碼。在驗證時擷取的電子郵件地址，是您可靠的持久識別碼。這是為什麼針對 CRM 整合目的，基於電子郵件的 Captive Portal 驗證在架構上優於點擊式或僅裝置驗證的另一個原因。 --- [實作建議與陷阱 — 2 分鐘] 讓我提供您區分清潔部署與混亂部署的四件事。 第一：在上線前定義您的網域封鎖清單。消費者電子郵件網域——Gmail、Yahoo、Hotmail、iCloud、Outlook——應排除在客戶比對與潛在客戶建立之外。若您不這麼做，您的 Salesforce 組織將被沒有商業價值的消費者聯絡人淹沒，並降低銷售團隊的資料品質。建立一份維護的封鎖清單，並在您的中介層邏輯中套用。 第二：在部署前與您的 RevOps 主管商定潛在客戶轉換為聯絡人的門檻。常見的錯誤是從 WiFi 事件建立潛在客戶，卻從未轉換它們，使它們無限期地停留在潛在客戶佇列中。定義一條規則：若來自已知公司網域的潛在客戶在三十天內造訪超過兩次，則自動轉換為聯絡人，並關聯至相符的客戶。這能保持您的銷售管道乾淨，並讓您的客戶經理專注。 第三：別跳過同意架構。在 GDPR 規範下，您需要合法的處理基礎，而針對行銷通訊，該基礎就是同意。您的 Captive Portal 必須呈現清晰的行銷選擇加入，與 WiFi 存取的服務條款分開。Purple 平台支援細分的同意類別——WiFi 存取、行銷電子郵件、第三方分享——並在 API 承載資料中以布林值旗標傳遞。將這些直接對應到 Salesforce 聯絡人欄位，並在您的行銷自動化規則中尊重它們。 第四：從第一天起就為您的整合加入錯誤記錄。無法比對或建立 Salesforce 記錄的驗證事件，應記錄到自訂的 Salesforce 物件或外部監控工具。若沒有這項，您將遭遇無聲的失敗——訪客連線了，但沒有建立任何記錄——直到有人注意到資料看起來很單薄，您才會發現。 --- [快問快答 — 1 分鐘] 好的，讓我們針對我最常聽到的問題進行快速問答。 「我應該同步到潛在客戶還是聯絡人？」——從已知客戶的聯絡人開始，未知的則用潛在客戶。永遠不要將所有項目都推送到潛在客戶。 「GDPR 怎麼辦？」——在入口網站取得同意，Salesforce 中的同意旗標，並在每個下游系統中遵守。無可妥協。 「我該如何處理一天內有數千人連線的會議場地？」——限制您的 Webhook 處理速率、批次處理您的 Salesforce upsert，並針對大量事件使用 Salesforce Bulk API。不要對體育場規模的部署使用標準 REST API。 「這可以用於 ABM 嗎？」——絕對可以。在 Salesforce 中標記您的目標客戶，設定 Flow 在這些客戶的任何 WiFi 造訪時警示您的客戶經理，您就擁有任何數位 ABM 工具都無法複製的實體意圖訊號。 「投資報酬率如何？」——使用 Purple Salesforce 整合的組織回報，由 WiFi 造訪警示完全驅動的客戶經理主動聯繫現有客戶的次數，有 20% 到 35% 的增長。由 WiFi 來源聯絡人影響的銷售管道，與冷漠接觸相比，通常顯示高出 15% 到 25% 的成交率，因為訪客已展現了實體參與。 --- [總結與後續步驟 — 1 分鐘] 總結來說：Salesforce WiFi 整合是一項成熟、可部署的能力，能將被動的網路基礎設施轉化為主動的客戶情報訊號。架構很直接——Captive Portal、身份解析中介層、Salesforce upsert——但價值在於資料模型決策、警示配置以及您圍繞它所建立的資料品質治理。 您的立即後續步驟：稽核您目前的 Salesforce 客戶記錄，檢查網域欄位的完整性——那是您的比對基礎。讓您的 RevOps 主管參與定義潛在客戶與聯絡人的路由規則。並檢閱 Purple 的 Salesforce 整合文件，以了解 API 承載結構與可用的 Webhook 事件。 若您在客戶或潛在客戶造訪的場域運行 Guest WiFi，這項整合應在一個季度內上線。資料就在那裡。您只需將它連接起來。 感謝聆聽。若您想更深入探索今天涵蓋的任何主題，完整的技術參考指南可在 purple.ai 取得。我們下次簡報再見。 --- [腳本結束]