香港 B2B 貿易公司六個月 HubSpot 導入實錄

一間香港 B2B 貿易公司在六個月內完成 HubSpot 導入，關鍵不在買了哪個版本，而在三件事：把分散在 Excel 與郵箱的報價資料統一成單一客戶視圖、用自訂物件重建「詢價—報價—訂單—出貨」流程、並讓業務團隊真的每天登入使用。

以下這個案例以匿名方式呈現——一間總部在香港、供應鏈橫跨深圳與越南、客戶分佈在美國、英國與澳洲的 B2B 貿易與採購代理公司。行業與形態是真實的，公司名稱不會出現。文中所有數字皆為公開研究來源，並在句中標明出處；我們不會替這次導入編造成效百分比。

導入前的起點：五套報價系統、零個單一真相

這類貿易公司的典型狀態是這樣的：

• 業務用個人 Outlook 信箱跟客戶往來，客戶歷史存在每個人的郵件裡
• 報價用 Excel 範本，每位業務有自己的版本，成本加成邏輯不一致
• 供應商報價與 MOQ 資訊存在採購部另一套 Excel
• 訂單進 ERP（本案是一套本地部署的中小型 ERP），但 ERP 不記錄「還沒成交的詢價」
• 管理層要看 pipeline，靠每週一次的 Excel 彙總會議

問題不是沒有資料，而是資料的所有權屬於個人而非公司。當一位資深業務離職，他手上二十多個歐洲客戶的議價歷史、規格偏好、驗貨要求全部隨郵箱一起消失。

這不是個別現象。Gartner 的 B2B 採購研究指出，77% 的 B2B 買家形容自己最近一次採購經驗「非常複雜或困難」；當賣方內部資料同樣分散，複雜度會再疊加一層。而 Salesforce 的《State of Sales》報告則顯示，業務代表實際花在銷售上的時間只佔工作週的約三成，其餘時間耗在行政、資料輸入與內部協調。對一間人手緊、毛利薄的貿易公司，這是最貴的隱形成本。

為什麼貿易公司的 CRM 需求跟 SaaS 公司完全不同？

多數 HubSpot 導入教學是寫給 SaaS 或訂閱制公司看的：MQL、SQL、試用轉付費、MRR。B2B 貿易公司的形狀完全不一樣。

交易週期不是漏斗，是循環

SaaS 的客戶成交一次就進入續約邏輯。貿易公司的同一個客戶,一年可能下 12 次訂單，每次規格、數量、價格都不同。用標準的 Deal pipeline 去硬套，結果是一個客戶底下堆了幾百筆交易，報表完全無法閱讀。

產品不是 SKU，是規格組合

同一款產品，不同客戶要求不同的包裝、認證（CE、FCC、UKCA）、標籤語言。HubSpot 標準的 Products 物件無法承載這種變體邏輯。

買賣雙邊都要管

貿易公司同時要管客戶（Company）與供應商（也是 Company）。兩者需要不同的屬性組、不同的生命週期、不同的權限可見度。

這三點決定了整個資料模型設計，也決定了為什麼「開通帳號就上線」在這類公司必然失敗。

第 1–2 個月：資料盤點與遷移，而不是急著設定功能

前兩個月完全沒有碰自動化。工作內容是：

1. 盤點資料源：列出所有存放客戶資料的位置，包括業務個人硬碟裡的 Excel。實際找到的檔案數量遠多於 IT 部門原本的認知。
2. 定義去重規則：同一家美國買家可能以三種寫法存在（縮寫、全名、含 Inc. 與不含）。去重邏輯要先由業務主管確認，而不是交給工具自動判斷。
3. 決定不遷移什麼。這一步最常被跳過。三年沒互動、沒有訂單記錄的聯絡人不遷入 HubSpot，避免一開始就污染資料庫。Forrester 長期的研究指出，B2B 資料每年會有相當比例因人事異動而失效，遷入垃圾資料只會加速信任崩塌。

遷移本身用 HubSpot 的 Import API 分批處理，並保留來源欄位以便追溯：

1# 使用 HubSpot CLI 驗證帳號與 portal
2npm install -g @hubspot/cli
3hs init
4hs accounts list

1{
2  "name": "legacy-companies-batch-01",
3  "files": [{
4    "fileName": "companies_2019_2025.csv",
5    "fileFormat": "CSV",
6    "dateFormat": "DAY_MONTH_YEAR",
7    "fileImportPage": {
8      "hasHeader": true,
9      "columnMappings": [
10        { "columnObjectTypeId": "0-2", "columnName": "company_name", "propertyName": "name" },
11        { "columnObjectTypeId": "0-2", "columnName": "country", "propertyName": "country" },
12        { "columnObjectTypeId": "0-2", "columnName": "legacy_source", "propertyName": "data_source_system" }
13      ]
14    }
15  }]
16}

保留 data_source_system 這個自訂欄位，之後任何資料品質爭議都能追回原始檔案。這是一個成本極低、回報極高的習慣。

用自訂物件重建貿易流程

HubSpot 的 Custom Objects（Enterprise 版本，或透過 API 於 Professional 以上依方案條款使用）是這類專案的核心。本案建立了兩個自訂物件：

Quotation Line（報價行）

承載每一次報價的品項、規格、供應商成本、加成率、有效期。與 Deal 建立關聯，一筆 Deal 可掛多筆報價行。

Supplier Capability（供應商能力）

記錄每家供應商可做的品類、認證、MOQ、平均交期。採購與業務共用同一份資料。

建立自訂物件的 API 呼叫大致如下：

1curl -X POST \
2  https://api.hubapi.com/crm/v3/schemas \
3  -H "Authorization: Bearer $HUBSPOT_PRIVATE_APP_TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{
6    "name": "quotation_line",
7    "labels": { "singular": "Quotation Line", "plural": "Quotation Lines" },
8    "primaryDisplayProperty": "line_reference",
9    "properties": [
10      { "name": "line_reference", "label": "Line Reference", "type": "string", "fieldType": "text" },
11      { "name": "unit_cost_usd", "label": "Unit Cost (USD)", "type": "number", "fieldType": "number" },
12      { "name": "markup_pct", "label": "Markup %", "type": "number", "fieldType": "number" },
13      { "name": "certification", "label": "Certification", "type": "enumeration", "fieldType": "checkbox",
14        "options": [
15          { "label": "CE", "value": "ce" },
16          { "label": "FCC", "value": "fcc" },
17          { "label": "UKCA", "value": "ukca" }
18        ]
19      }
20    ],
21    "associatedObjects": ["DEAL", "COMPANY"]
22  }'

同時使用 Association Labels 區分「客戶」與「供應商」兩種 Company 關係，讓同一個物件類型能承載雙邊角色：

1curl -X POST \
2  https://api.hubapi.com/crm/v4/associations/deal/company/labels \
3  -H "Authorization: Bearer $HUBSPOT_PRIVATE_APP_TOKEN" \
4  -H "Content-Type: application/json" \
5  -d '{ "label": "Supplying Factory", "name": "supplying_factory" }'

這個設計的取捨要說清楚：自訂物件讓報表變得精準，但也提高了日後維護門檻。欄位一旦被 workflow、報表、整合同時引用，改名或刪除的代價很高。建議在第一次上線前就凍結命名規範，並寫進內部文件。

第 3–4 個月：自動化要解決真實痛點，不是展示功能

這階段只做三條自動化，刻意克制。

詢價自動分派

網站表單與 sales@ 共用信箱進來的詢價，依據國別與品類自動指派負責人，並建立 Deal。避免「誰先看到誰接」造成的重複跟進。

報價有效期提醒

報價行的有效期前三天，自動通知負責業務。原本這靠個人記憶，海運與原物料價格波動時，過期報價會直接吃掉毛利。

靜止交易復甦

Deal 超過 21 天無任何 activity，自動變更階段並推送任務。管理層第一次看見 pipeline 裡到底有多少是「假的」。

一條簡化的 workflow 定義邏輯：

1{
2  "name": "Stale Deal Alert - 21 Days",
3  "type": "DEAL",
4  "enrollmentTriggers": [{
5    "filter": { "property": "notes_last_updated", "operator": "LT", "value": "21_DAYS_AGO" }
6  }],
7  "actions": [
8    { "type": "SET_PROPERTY", "property": "deal_health", "value": "at_risk" },
9    { "type": "CREATE_TASK", "subject": "Re-engage stale opportunity", "dueInDays": 1 },
10    { "type": "SLACK_NOTIFICATION", "channel": "#sales-ops" }
11  ]
12}

與 ERP 的雙向同步

訂單成立後，Deal 需要把資料推入 ERP；ERP 的出貨與收款狀態要回寫 HubSpot。本案沒有用現成連接器（本地部署 ERP 沒有官方整合），而是用 HubSpot Private App token 加一層中介服務，以 Webhook 觸發、佇列重試的方式處理。

1// 中介層：接收 HubSpot webhook，轉譯後推送 ERP
2app.post('/hubspot/deal-won', async (req, res) => {
3  const events = req.body;
4  for (const evt of events) {
5    if (evt.propertyName === 'dealstage' && evt.propertyValue === 'closedwon') {
6      await queue.add('erp-sync', {
7        dealId: evt.objectId,
8        attempt: 0
9      }, { attempts: 5, backoff: { type: 'exponential', delay: 2000 } });
10    }
11  }
12  res.sendStatus(200); // HubSpot 要求快速回應
13});

重點是 webhook handler 必須立刻回 200，實際工作丟進佇列。這是我們在多個跨境整合專案中反覆遇到的坑——同步處理會在 ERP 慢回應時造成 HubSpot 重送與資料重複。

AI 如何在不增加人手的情況下放大產出？

這是 2026 年這類專案最實際的變化。貿易公司的業務每天要處理大量非結構化輸入：客戶英文郵件、工廠中文微信訊息、PDF 規格書。

本案在第四個月加入的 AI 輔助環節包括：

• 郵件摘要與意圖標記：用 LLM 讀取往來郵件，產生結構化摘要寫回 Deal 的自訂欄位（例如「客戶要求改包裝」、「客戶在議價」）。業務主管不用逐封讀信也能掌握狀況。
• 多語言草稿：業務以中文輸入重點，產生英文回覆草稿，人工修訂後發送。對應歐美客戶的溝通品質一致性提升，但仍保留人工把關。
• 規格書資料抽取：從供應商 PDF 抽取 MOQ、交期、認證，寫入 Supplier Capability 物件。

McKinsey 的生成式 AI 研究指出，客戶營運與銷售是生成式 AI 價值潛力最集中的職能之一。不過必須誠實說明取捨：LLM 輸出必須當作草稿而非事實。本案的設計原則是「AI 寫入的欄位一律加前綴標示，且不可直接觸發對外自動發送」。任何對外郵件仍需人工按下發送鍵。

跨境資料合規：香港、新加坡、歐盟怎麼一起處理？

一間香港公司、客戶在歐盟與英國、供應鏈在中國與越南、可能還有新加坡的關聯實體——資料保護不是單一法規問題。

• 香港：個人資料（私隱）條例（PDPO）由私隱專員公署執行，對直接促銷有明確的選擇退出要求。B2B 聯絡人的公司郵箱仍可能構成個人資料。
• 新加坡：PDPA 由 PDPC 執行，同意與通知規則與香港不完全一致。
• 歐盟 / 英國：客戶在歐盟時，GDPR 的域外適用性會觸發。

實務做法是在 HubSpot 用 Subscription Types 分開管理不同市場的訂閱偏好，並依聯絡人所在地套用不同的同意收集邏輯，而不是全球一套最寬鬆的規則。HubSpot 內建的 GDPR 功能可以開啟合法基礎（lawful basis）欄位，這在歐盟客戶佔比高的貿易公司值得一開始就啟用。

這也是把營運樞紐設在亞洲的其中一個策略價值：香港與新加坡的團隊同時熟悉大中華供應鏈與歐美客戶的合規預期，在時區上又能覆蓋亞洲白天與歐洲早晨。對美、英、歐公司而言，這是一個能同時貼近供應端與符合客戶端法規要求的位置。

第 5–6 個月：採用率才是真正的成敗指標

CRM 專案失敗，九成不是技術問題，是沒人用。第五、六個月的重心全部放在採用。

減少輸入，而不是要求輸入

每多要求業務填一個欄位，採用率就掉一截。最終上線的 Deal 必填欄位控制在五個以內，其餘靠自動帶入或 AI 抽取。

把報表變成他們的工具

業務個人 dashboard 顯示「我的過期報價」、「我本月已報價未跟進」，而非只給管理層看的 pipeline 總覽。當系統對個人有用，登入才會變成習慣。

停用舊路徑

最後一步是關掉 Excel 報價範本的共用資料夾。只要舊路徑還在，部分人就不會轉換。這一步要有管理層明確背書，否則執行不了。

我們不會在這裡給出一個「成交率提升 X%」的數字，因為那需要導入前後可比的基準線，而多數貿易公司在導入前根本沒有可靠基準。這本身就是誠實的觀察：如果你的公司現在說不出上一季的報價轉換率，導入後任何「提升」的宣稱都不可驗證。真正的六個月成效，是從「說不出來」變成「說得出來」。

六個月後，哪些事情確實改變了？

可以誠實描述的變化是機制層面的：

1. 客戶歷史歸屬於公司。業務異動時的交接從「轉寄郵件」變成「更改擁有者」。
2. 報價邏輯統一。加成率與有效期由系統管控，不再是每人一套 Excel。
3. 管理層能自行查詢。週會從「彙總資料」變成「討論資料」。
4. 供應商能力可搜尋。新詢價進來時，採購能在系統內找到合適工廠，而不是靠記憶。

同樣要說明代價：

• 授權與整合維護是持續成本，不是一次性支出。
• 自訂物件建得越深，日後更換平台的遷移難度越高。
• 前兩個月幾乎看不到任何「成果」，需要管理層願意忍受這段空窗期。

想複製這個路徑？六個月分階段檢查清單

1. 第 1 個月：盤點所有資料源；定義去重與不遷移規則；確認 ERP 整合可行性（有無 API）。
2. 第 2 個月：完成資料遷移與欄位命名凍結；建立自訂物件 schema。
3. 第 3 個月：上線三條核心自動化；訓練業務使用 Deal 與報價流程。
4. 第 4 個月：接通 ERP 雙向同步；導入 AI 輔助摘要與抽取，設定人工把關規則。
5. 第 5 個月：建立個人與管理層雙層 dashboard；依市場設定訂閱與同意管理。
6. 第 6 個月：關閉舊系統路徑；檢視採用率數據；建立資料品質的月度檢查機制。

如果你只有資源做好一件事，選第一個月的資料盤點。所有後面的問題，幾乎都源自這一步被跳過。

Branch8 總部設於香港，並在新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲設有交付團隊，專注於 CRM 與 CDP 的導入、遷移與跨境整合。如果你正在評估 HubSpot、Salesforce 或客戶資料平台的落地路徑，歡迎與我們談談你的資料現況與目標架構。

Sources

• HubSpot Developers — CRM API Documentation
• HubSpot — Knowledge Base
• Gartner — Sales Practice Research and Insights
• Salesforce — State of Sales Research Report
• McKinsey & Company — Growth, Marketing & Sales Insights
• Office of the Privacy Commissioner for Personal Data, Hong Kong (PCPD)
• Personal Data Protection Commission Singapore (PDPC)
• HKTDC Research — Market Intelligence