香港保險業 CRM 導入合規指南：HubSpot vs Salesforce

香港保險業導入 CRM，合規門檻先於功能比較。Salesforce（Financial Services Cloud + Shield）適合受嚴格審計、需要欄位級加密與完整審計軌跡的持牌機構；HubSpot 適合以行銷與中介人營運為主、要求快速上線的團隊。關鍵差異在資料駐留、同意管理與記錄保存能力。

為什麼保險業的 CRM 專案，本質上是合規專案

一般零售或 B2B 企業導入 CRM，失敗多半是「用戶不用」。保險業不一樣：導入失敗的代價可能是監管查詢、投訴個案難以舉證，以及資料外洩事故。

根據 IBM《Cost of a Data Breach Report 2024》，全球資料外洩事故平均成本為 488 萬美元，而金融業是成本第二高的行業。香港個人資料私隱專員公署（PCPD）每年公布的資料外洩事故通報數字亦持續處於高位，公署已多次就機構未能妥善保障客戶資料發出執行通知。

保險 CRM 存放的資料，典型包括身份證號碼、受益人關係、健康申報摘要、理賠記錄、財務需要分析（FNA）結果。這些在《個人資料（私隱）條例》（PDPO，香港法例第 486 章）下全部屬個人資料，部分更屬高度敏感。換句話說，CRM 選型決定的不只是銷售漏斗長甚麼樣，而是你能不能在監管機構問「這位客戶在 2023 年 4 月同意了甚麼」時，三分鐘內給出答案。

這篇指南從合規出發，拆解 HubSpot 與 Salesforce 在香港及亞太保險情境下的真實取捨。

導入前必須盤點的四層監管要求

第一層：PDPO 與六項保障資料原則

PDPO 的六項保障資料原則（DPP1–DPP6）直接對應 CRM 的設計決策：

1. DPP1（收集目的及方式）— CRM 表單收集的欄位必須與保險銷售或服務目的相稱。常見問題是行銷表單順手收集身份證號碼，但該階段根本不需要。
2. DPP2（準確性及保留期間）— 資料不可保存超過必要期間。這代表 CRM 需要有可執行的資料保留政策，而非「永久保存」。
3. DPP3（使用限制）— 用於直接促銷必須取得明確同意，這是香港最容易踩雷的一條。
4. DPP4（保安）— 加密、存取控制、第三方處理者管理。
5. DPP5（透明度）— 私隱政策須說明資料類別與處理方式。
6. DPP6（查閱及改正）— 客戶有權查閱與改正，CRM 必須支援 DSAR 流程。

PCPD 指出，PDPO 第 35 條對直接促銷有獨立規範：首次使用個人資料作直接促銷前，必須通知資料當事人並取得其不反對（部分情況為明確同意），而將資料提供第三方作促銷用途則須取得書面同意。違反屬刑事罪行。對於與銀行、旅遊或零售夥伴做 cross-sell 的保險公司，這一條直接決定 CRM 的同意資料模型要怎麼設計。

值得注意的是，PDPO 第 33 條（限制個人資料移轉至香港境外）至今仍未生效，PCPD 在其跨境資料轉移指引中建議機構自願採用建議的合約條款。這給了跨境 CRM 架構一定彈性，但不代表可以忽略——一旦生效，架構改造成本極高。

第二層：保險業監管局（IA）的操守與科技要求

保監局就持牌保險代理人與持牌保險經紀分別發出操守守則（GL25、GL26），當中對銷售過程的記錄保存、財務需要分析、適合性評估與披露，都有明確要求。保監局亦發出網絡保安相關指引（GL20），要求受規管機構建立網絡保安管治框架。實際適用版本與條文編號請以保監局官網最新文本為準。

對 CRM 的具體含義：

• 每一次銷售互動（會面、建議、客戶簽署）都必須能夠重建時序
• FNA 與產品推介的對應關係必須可追溯
• 記錄保存期必須涵蓋保單生命周期後的追溯期，長期壽險業界普遍以遠長於七年的期間作基準
• 中介人離職後，其名下客戶記錄的存取權必須能即時撤銷但資料不得刪除

第三層：跨境營運疊加的法規

如果你的保險集團同時在新加坡、台灣、澳洲營運，CRM 就不只面對 PDPO：

• 新加坡：PDPA 加上金管局（MAS）的《Technology Risk Management Guidelines》與外判通告，對雲端服務商的盡職審查有具體要求
• 澳洲：Privacy Act 1988 與 APRA Prudential Standard CPS 234（資訊安全）
• 台灣：個人資料保護法，金管會對保險業資通安全有另行規範
• 歐盟客戶：GDPR 的資料主體權利與跨境傳輸機制

第四層：集團內部的資料治理

多數大型保險集團的 CRM 導入卡關點不是監管，而是內部：代理人渠道、經紀渠道、銀保渠道、直銷渠道對「客戶擁有權」的定義不同，導致同一個客戶在系統內有四筆記錄、四套同意狀態。這是資料模型問題，兩個平台都解決不了，必須在導入前決策。

Salesforce 在保險合規場景的真實能力

資料駐留與加密

Salesforce 的 Hyperforce 架構已在多個亞太區域提供本地資料駐留，包括澳洲、日本、新加坡與印度等（實際可用區域以 Salesforce Trust 官網為準）。對需要向 MAS 或 APRA 解釋資料位置的機構，這是實質優勢。

Salesforce Shield 是保險業最常被要求的加購模組，包含三項：

• Platform Encryption：欄位級靜態加密，支援 Bring Your Own Key（BYOK）
• Event Monitoring：記錄誰在何時查閱／匯出了哪些記錄，這是回應「代理人離職前大量下載客戶名單」場景的唯一有效工具
• Field Audit Trail：欄位歷史保存可延長至十年，直接對應長期業務的記錄保存要求

欄位級加密可透過 Metadata API 部署，例如：

1<!-- objects/Contact.object -->
2<fields>
3    <fullName>HKID_Number__c</fullName>
4    <encryptionScheme>ProbabilisticEncryption</encryptionScheme>
5    <type>Text</type>
6    <length>20</length>
7</fields>

存取控制則以 Permission Set 加 Sharing Rule 組合，確保中介人只能看到自己名下客戶：

1// 離職中介人：撤銷存取但保留記錄
2List<User> leavers = [SELECT Id FROM User WHERE IsActive = false 
3                      AND Profile.Name = 'Licensed Insurance Agent'];
4for (User u : leavers) {
5    // 重新指派 Owner 至渠道主管，原記錄與歷史完整保留
6}

Financial Services Cloud

Salesforce 的 Financial Services Cloud 提供保險業預建資料模型，包括 Policy、Claim、Producer、Household 等物件，以及 Financial Account 與關係圖譜。對需要處理家庭保單組合、受益人關係、團體保單架構的壽險業者，自建這套模型通常需要數個月。

代價

Salesforce 的合規能力是分層收費的。Shield、Financial Services Cloud、Data Cloud、Sandbox 都是獨立授權項目。同樣重要的是實施複雜度：Gartner 在其 CRM 市場分析中長期指出，大型 CRM 專案的實施成本往往等同甚至超過軟體授權成本。保險業因為資料模型複雜，這個比例通常更高。

HubSpot 在保險合規場景的真實能力

強項在哪裡

HubSpot 的 Marketing Hub 與 Sales Hub 在幾個保險情境確實更有效率：

• 同意管理原生支援：HubSpot 的 subscription types 與 legal basis for processing 欄位是為 GDPR 設計的，可直接對應 PDPO 第 35 條的「直接促銷同意」追蹤需求
• 表單與落地頁：代理人招募、保險產品諮詢、理賠查詢表單可由市場部直接建置，無需開發資源
• 生命周期行銷：續保提醒、保單周年、理賠後滿意度追蹤，workflow 設定門檻低

HubSpot 的 Enterprise 層提供 sensitive data 處理能力、field-level permissions 與 audit log。HubSpot 亦已推出歐盟（法蘭克福）等地區的資料託管選項，實際可選區域請以 HubSpot Trust Center 為準。

同意狀態可透過 API 讀寫，便於與核心保單系統同步：

1curl -X GET \
2  'https://api.hubapi.com/communication-preferences/v3/status/email/[email protected]' \
3  -H 'Authorization: Bearer YOUR_PRIVATE_APP_TOKEN'

寫入退訂狀態（例如客戶透過電話中心要求停止促銷）：

1curl -X POST \
2  'https://api.hubapi.com/communication-preferences/v3/unsubscribe' \
3  -H 'Authorization: Bearer YOUR_PRIVATE_APP_TOKEN' \
4  -H 'Content-Type: application/json' \
5  -d '{
6    "emailAddress": "[email protected]",
7    "subscriptionId": "7654321",
8    "legalBasis": "LEGITIMATE_INTEREST_CLIENT",
9    "legalBasisExplanation": "Opt-out received via contact centre, ref CC-2026-0142"
10  }'

限制在哪裡

誠實說，HubSpot 在三個地方會讓保險合規團隊不滿意：

1. 沒有等同 Shield 的欄位級加密與 BYOK。如果你的資安政策要求 HKID 或健康資料必須以機構自管金鑰加密，HubSpot 原生無法滿足，必須靠 tokenisation 在寫入前處理。
2. 資料模型彈性有限。Custom objects 在 Enterprise 層可用，但處理「一張團體保單對多位受保人對多位受益人」這類多層關係，建模空間不如 Salesforce。
3. 審計粒度較粗。HubSpot 有 audit log，但要回答「某代理人在過去 90 天查閱過哪 300 位客戶的保單細節」這類問題，深度不及 Event Monitoring。

怎樣在兩者之間做決定

不要問「哪個比較好」，問這四個問題：

1. CRM 會不會存放核心保單資料與健康資料？ 會 → Salesforce（Shield 近乎必要）。 不會，只做前端潛客與行銷，保單資料留在核心系統 → HubSpot 可行。
2. 你的持牌中介人數目有多少？ 數百人以上、多層級架構、需要階梯式存取控制與佣金可視化 → Salesforce。 數十人內勤團隊為主 → HubSpot。
3. 監管審計的頻率與深度如何？ 受 IA 直接監管的保險公司或大型經紀 → Field Audit Trail 與 Event Monitoring 的價值很難被取代。 以保險科技、比價平台或推薦渠道身份營運 → HubSpot 的審計深度通常足夠。
4. 上線時間表是甚麼？ 行銷團隊要在一季內跑起來 → HubSpot。 有 12–18 個月的核心系統整合藍圖 → Salesforce。

一個實務上常見的答案是兩者並存：HubSpot 做潛客獲取與行銷自動化，Salesforce Financial Services Cloud 做持牌銷售流程與保單服務，中間以明確的資料邊界切開——行銷層不碰健康資料與身份證號碼，銷售層不做大量外發 email。這個架構的代價是需要維護雙向同步與一套統一的同意狀態真相來源（single source of truth），通常放在 Salesforce 或獨立的 CDP。

同意管理：最容易被低估的設計決策

香港保險機構最常見的 CRM 合規缺陷，不是加密不足，而是同意狀態說不清楚。

一個可審計的同意模型至少需要記錄五個維度：

1. 同意的對象（哪一間法人實體、是否包括集團關聯公司）
2. 同意的用途（保單服務 vs 直接促銷 vs 提供予第三方）
3. 同意的渠道（email / SMS / 電話 / WhatsApp）
4. 同意的時間與取得方式（線上表單、紙本、錄音）
5. 同意的證據（表單提交 ID、錄音檔案引用、簽署文件連結）

Salesforce 的 Individual 與 Contact Point Type Consent 物件原生支援這個粒度。HubSpot 需要以 subscription types 加 custom properties 組合實作，可行但要有紀律。

無論哪個平台，不要把同意狀態存成一個布林值欄位。這是我們在協助亞太區金融與保險相關機構盤點 MarTech 架構時最常見、也最昂貴的技術債。

AI 功能在保險 CRM 的合規邊界

2026 年的 CRM 選型繞不開 AI。Salesforce 的 Einstein Trust Layer 與 HubSpot 的 Breeze 都提供生成式 AI 功能，但保險業使用時有幾條明確紅線：

• 不得以 LLM 生成產品適合性結論。AI 可以草擬會面摘要，但 FNA 與適合性評估的判斷必須由持牌人作出並留下記錄。
• 提示內容必須納入資料治理範圍。將客戶健康申報貼進 AI 助手，等同一次資料處理行為，需要有法律依據。
• 零保留（zero retention）承諾需要書面確認。Salesforce 的 Einstein Trust Layer 公開說明其 zero-data-retention 架構；使用任何第三方 AI 外掛前，應要求供應商以合約形式確認同等條款。

務實的做法是把 AI 用在不碰敏感資料的環節：代理人招募文案、續保提醒的多語言版本（繁中／簡中／英文／印尼文）、內部知識庫問答、通話記錄的結構化擷取（在去識別化後）。

跨市場團隊如何降低導入風險

如果你的保險業務橫跨香港、新加坡、台灣與東南亞，CRM 導入的最大風險不是技術，是法規差異被當成技術差異處理。

可行的架構原則：

• 單一全球 CRM 實例 + 市場層級資料隔離，而非每個市場一個獨立實例。後者看似安全，實際上讓跨境客戶視圖永遠無法成形。
• 同意模型以最嚴格市場為基準設計，再以市場旗標放寬，而非相反。
• 資料保留政策按市場參數化，在 CRM 層以自動化流程執行，而非靠人手清理。

Branch8 曾為一間在香港與東南亞同時營運的受規管金融服務機構，執行 Salesforce 與行銷自動化平台的同意資料模型盤點。該專案的核心工作不是寫程式，而是先把四個市場、三條渠道的同意取得方式畫成一張矩陣，再反推系統需要哪些欄位與稽核事件——技術實作只佔整體工時的一小部分。這個先後次序，決定了專案是否會在上線後被合規部門退回。

90 天導入路線圖

第 1–30 天：合規盤點

1. 列出所有客戶接觸點與其資料收集欄位
2. 建立同意取得方式矩陣（市場 × 渠道 × 用途）
3. 確認各市場資料駐留與外判通報要求
4. 定義資料保留期限與觸發條件

第 31–60 天：架構與配置

1. 完成資料模型設計與欄位分類（公開／內部／敏感／受限）
2. 配置加密、存取控制與審計設定
3. 建立 DSAR（資料查閱要求）處理流程，含服務水平
4. 與核心保單系統的整合介面規格定稿

第 61–90 天：試行與驗證

1. 單一渠道、單一市場試行
2. 執行一次模擬監管查詢：重建指定客戶的完整互動時序
3. 執行一次模擬 DSAR：在法定時限內產出完整資料副本
4. 資安團隊滲透測試與存取權覆核

第 62 與 63 項是最常被跳過、也最能暴露架構缺陷的步驟。如果你無法在試行階段重建一位客戶的完整同意與互動歷史，正式上線後也不會變得比較容易。

六個常見失敗模式

1. 把 CRM 當成資料湖：甚麼都塞進去，結果敏感資料擴散到無法控制。
2. 同意狀態分散在多個系統：行銷平台、電話中心、保單系統各有一份，互相矛盾。
3. 先買授權再做盤點：買了 Shield 卻沒有欄位分類，等於付費買了一個沒開啟的功能。
4. 忽略中介人離職場景：存取權撤銷流程缺失，是資料外洩最常見的起點。
5. 資料保留政策只寫在文件裡：沒有在系統層自動執行，DPP2 形同虛設。
6. 把多市場差異留給使用者判斷：讓前線決定哪些客戶可以收促銷訊息，必然出錯。

最後的判斷標準

選 CRM 的真正問題不是「HubSpot 還是 Salesforce」，而是：當監管機構明天要求你在五個工作天內，提供某位客戶自 2019 年起的所有互動記錄、同意變更歷史與資料存取日誌，你的系統做得到嗎？

做得到的架構，兩個平台都能實現；做不到的架構，再貴的授權也補不回來。

如果你的團隊正在評估保險或受規管金融業的 CRM 導入，Branch8 在香港、新加坡、台灣與東南亞的交付團隊，可協助進行合規盤點、資料模型設計與平台實作。歡迎與我們聯絡，討論你所在市場組合的具體要求。

Sources

• Office of the Privacy Commissioner for Personal Data, Hong Kong — PCPD
• Insurance Authority Hong Kong — Regulatory Framework and Guidelines
• IBM — Cost of a Data Breach Report
• Salesforce — Financial Services Cloud
• Salesforce Trust — Security, Compliance and Data Residency
• HubSpot — Trust Center and Security
• HubSpot Knowledge Base — Subscription Types and Consent
• Monetary Authority of Singapore — Technology Risk Management