台灣新創第一次用 HubSpot 免費版：8 個避坑指南

台灣新創第一次導入 HubSpot 免費版，最常踩的坑不是功能不夠，而是資料架構沒規劃、寄信網域沒驗證、以及把免費額度誤當無限。先把欄位命名、Cookie 同意與 DNS 驗證做對，升級時才不會被迫重建整套 CRM。

HubSpot 的免費版（Free Tools）是目前市面上門檻最低的 CRM 起點：不用信用卡、不用合約、十分鐘就能開始記錄客戶。但「好上手」和「好維護」是兩件事。我們在台灣、香港、新加坡協助團隊接手別人建過的 HubSpot 帳號時，重工的原因幾乎都一樣——第一個月的設定偷懶了。

這篇是給台灣早期團隊（種子到 A 輪、行銷與業務加起來 2–10 人）的實務指南：免費版的真實界線在哪、哪些設定必須在第一週做完、以及升級前後會發生什麼事。

免費版到底包含什麼？先看清三層界線

HubSpot 的產品結構容易混淆，因為「免費」有三種意思：

Free Tools（真正的免費版）

永久免費，不需信用卡。包含 CRM 基礎物件（聯絡人、公司、交易、任務）、表單、即時聊天、Email 行銷、會議連結、報表基礎版。功能有上限但沒有到期日。根據 HubSpot 官方產品與服務目錄（HubSpot Product & Services Catalog），免費帳號可儲存最多 1,000,000 筆聯絡人與公司紀錄，行銷 Email 每個日曆月可寄送 2,000 封，交易流程（deal pipeline）限 1 條，會議連結限 1 個，每個物件可建立的自訂屬性上限為 10 個。

Starter（付費入門）

解除免費版的品牌標記（HubSpot logo）、提高寄信與自動化額度、開放簡易自動化與多條 pipeline。以 seat（席次）計價。

Professional 以上

才有完整 Workflow 自動化、自訂報表儀表板、A/B 測試、進階權限與 Sandbox。

重點：免費版不是 Professional 的試用版，是不同的產品層。你在免費版設計的流程，若假設「以後會有自動化補上」，多半要重做一次。額度數字 HubSpot 會不定期調整，簽約前請以官方目錄頁面當天的版本為準。

坑一：把「一百萬筆聯絡人」當成可以隨便匯入

儲存上限高，不代表你該把所有名單塞進去。兩個原因：

第一，Marketing Contacts 計費邏輯。HubSpot 把聯絡人分成「marketing」與「non-marketing」兩種狀態。只有標記為 marketing 的聯絡人才能收到行銷 Email，而付費方案是按 marketing contacts 級距計價（HubSpot 官方定價頁）。若你在免費期間把 5 萬筆來源不明的名單全設成 marketing，升級 Starter 或 Professional 的第一張帳單會非常難看。

第二，資料衛生會反噬。HubSpot 以 Email 為主鍵去重，沒有 Email 的紀錄（例如只留 LINE ID 或電話的展會名單）會產生大量重複。免費版沒有進階去重工具，只能靠手動合併。

實務做法：匯入前先在 Google Sheets 清一輪，並固定一套匯入模板。

1必填：email, firstname, lastname, company, phone
2必填（自訂）：lead_source_detail, consent_source, consent_timestamp
3禁止：把「備註」欄塞進 notes 以外的欄位
4預設：marketing contact status = non-marketing（匯入後再依同意紀錄升級）

坑二：追蹤碼裝了，Cookie 同意卻沒處理

HubSpot 的追蹤碼（tracking code）會寫入 cookie 來識別訪客、串接表單提交與網頁瀏覽行為。台灣團隊常見的錯誤是：網站掛了追蹤碼，但同意機制只擋 GA，沒擋 HubSpot。

台灣的《個人資料保護法》採「特定目的+告知」架構（全國法規資料庫），對線上追蹤的規範不如歐盟 GDPR 明確，但只要你的網站有歐盟、英國訪客，或你打算做跨境市場，ePrivacy 與 GDPR 的同意要求就適用。新加坡 PDPA（Personal Data Protection Commission）同樣要求可證明的同意紀錄。

免費版可以做到的最低標準：

1. 在 HubSpot 設定中開啟 Consent banner / Cookie tracking 同意功能，選擇「需要同意才追蹤」的模式。
2. 表單加上明確的訂閱勾選框，不要預設打勾。
3. 把同意來源與時間寫進自訂屬性，而不是只存在表單提交紀錄裡。

若你用自家 CMS，追蹤碼應由同意管理工具控制載入時機：

1<!-- 只在取得 analytics 同意後注入 -->
2<script>
3window.addEventListener('consent:granted', function (e) {
4  if (e.detail.categories.includes('analytics')) {
5    var s = document.createElement('script');
6    s.id = 'hs-script-loader';
7    s.async = true;
8    s.defer = true;
9    s.src = '//js.hs-scripts.com/YOUR_PORTAL_ID.js';
10    document.head.appendChild(s);
11  }
12});
13</script>

坑三：寄信網域沒驗證，第一波 Email 就進垃圾桶

這是最容易修、也最常被跳過的一步。HubSpot 要求你在 DNS 加入 DKIM 與 SPF 紀錄才能以自家網域寄信（HubSpot Knowledge Base：Connect your email sending domain）。

2024 年起 Google 與 Yahoo 對大量寄件者（每日 5,000 封以上）要求 SPF、DKIM 與 DMARC 齊備（Google Postmaster / Gmail 寄件者規範）。即使你的量遠低於門檻，缺 DMARC 仍會影響送達率。

典型設定（以 Cloudflare 或 Gandi 管理的 .com / .com.tw 網域為例）：

1; SPF — 合併，不要建立第二筆 TXT SPF
2@            TXT   "v=spf1 include:_spf.google.com include:23029831.spf05.hubspotemail.net ~all"
3
4; DKIM — HubSpot 產生的兩筆 CNAME
5hs1-23029831._domainkey  CNAME  hs1-23029831.xxxxx.dkim.hubspotemail.net
6hs2-23029831._domainkey  CNAME  hs2-23029831.xxxxx.dkim.hubspotemail.net
7
8; DMARC — 先用 p=none 收報告，兩週後再收緊
9_dmarc       TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

三個台灣常見地雷：

• 同時有兩筆 SPF TXT → SPF 直接失效。必須合併成一筆。
• 網域在 HiNet 或早期代管商，DNS 面板不支援 CNAME 於子網域 → 需先轉出 DNS 管理權。
• 寄件者用 gmail.com 或 yahoo.com.tw 當 from address → DMARC 政策會直接拒收。務必使用自有網域。

坑四：資料架構一開始就亂

免費版每個物件只有 10 個自訂屬性，這個限制其實是好事——它逼你想清楚什麼才重要。但多數團隊的做法是隨手新增，三個月後出現 來源、來源2、lead source、渠道 四個意思重疊的欄位。

命名規範（第一天就定）

1物件_主題_細項     內部名稱一律小寫底線
2例：contact_lead_source_detail
3    company_market_country
4    deal_product_line
5標籤（label）用繁中，內部名稱用英文 → 之後接 API 或換工具不用改程式
6下拉選單值：固定英文代碼（tw / hk / sg / jp），不要用中文字當值

Lifecycle stage 不要自創

HubSpot 內建的 lifecycle stage（Subscriber → Lead → MQL → SQL → Opportunity → Customer）是所有內建報表的骨幹。台灣團隊常把它改成自家用語，結果所有預設報表都失去意義。建議保留內建階段，另開一個自訂屬性放你自己的分類。

一條 pipeline 的紀律

免費版只有一條交易流程。與其抱怨，不如趁這時候把「一條流程能不能描述我們的成交過程」想清楚。如果 B2B 專案與訂閱續約真的無法共用，那才是升級 Starter 的合理理由。

坑五：以為免費版有自動化

免費版沒有 Workflow。你能用的只有：

• 表單提交後的 follow-up email（最多幾封、無分支邏輯）
• 簡易任務排程與 Email 範本、序列（Sequences 屬付費）
• 手動清單（靜態）與有限的自動清單額度

這對早期團隊其實夠用，關鍵是不要把自動化寫在 SOP 裡然後假設系統會執行。替代方案有兩條：

方案 A：用 HubSpot API 自己補。免費與 Starter 帳號的 API 速率上限為每 10 秒 100 次請求、每日 250,000 次（HubSpot Developer Docs）。以下是用 Private App token 建立聯絡人並設定同意欄位的範例：

1curl -X POST 'https://api.hubapi.com/crm/v3/objects/contacts' \
2  -H "Authorization: Bearer $HUBSPOT_PRIVATE_APP_TOKEN" \
3  -H 'Content-Type: application/json' \
4  -d '{
5    "properties": {
6      "email": "[email protected]",
7      "firstname": "雅婷",
8      "lastname": "林",
9      "contact_lead_source_detail": "line_oa_2026q1",
10      "consent_source": "line_optin",
11      "consent_timestamp": "2026-01-15",
12      "hs_marketable_status": "false"
13    }
14  }'

方案 B：外部排程器。用 Make、n8n 或 Cloud Functions 每小時輪詢一次，做「表單來了就開任務、48 小時沒跟進就通知 Slack / LINE」這類規則。這在 2026 年變得更划算，因為同一個 n8n 流程可以掛一個 LLM 節點，先幫你把中英文混雜的表單留言分類與摘要，再寫回 HubSpot 的 notes。輸出量放大，但人力不用等比增加。

坑六：LINE、電商與台灣金流沒規劃整合路徑

HubSpot 的原生整合以歐美工具為主。台灣新創的真實流量入口往往是 LINE 官方帳號。根據 LINE 台灣官方公布的數據，LINE 在台灣的月活躍用戶超過 2,100 萬，是多數 B2C 團隊的第一觸點。

免費版沒有官方 LINE 整合，可行路徑有三：

1. Webhook 橋接：LINE Messaging API（LINE Developers）的 webhook 事件 → 中介服務 → HubSpot CRM API 建立/更新聯絡人。把 LINE userId 存成自訂屬性，未來才能做跨通道歸戶。
2. 第三方 MarTech 工具（台灣本地方案多以 LINE 為核心）→ 用檔案或 API 同步到 HubSpot，HubSpot 當單一客戶檔案來源。
3. 先不整合：早期量小，人工把 LINE 成交寫回 HubSpot 交易，比維護一條會壞的 pipeline 划算。

電商端（Shopify、Shopline、91APP）情況類似：Shopify 有官方整合，本地平台多半得走 API 或中介。決策原則是——先確定 HubSpot 是不是你的客戶主檔（system of record）。如果訂單真相在電商後台、客服真相在 LINE、名單真相在 HubSpot，那你需要的是明確的欄位權責表，而不是更多整合。

坑七：升級時才發現 seat 計費與合約年限

HubSpot 在 2024 年改為 seat-based 計價模型（HubSpot 官方定價頁）：付費方案區分 Core Seat 與 View-only Seat，Core Seat 按人計費。這對台灣小團隊的影響是——升級成本不只是「方案月費」，而是「方案 × 人數」。

升級前務必確認四件事：

1. 誰真的需要 Core Seat。只看報表的財務與老闆用 View-only 就好。
2. 年繳 vs 月繳。年繳折扣可觀但綁一年，早期團隊若還在調整 GTM，月繳的彈性可能更值錢。
3. Marketing Contacts 級距。升級前先把 non-marketing 狀態整理乾淨（見坑一）。
4. 幣別與發票。跨境團隊常遇到 USD 計價、台灣公司報帳需要的憑證格式問題，先問清楚。

另外，Breeze（HubSpot 的 AI 功能集）多數進階能力綁定付費層與 credit 制度。若你是因為「想用 AI 寫 Email」而升級，先去官方定價頁確認該功能屬於哪一層，以及 credit 的計算方式。

坑八：沒想過資料可攜與退出成本

免費版最被低估的風險：你在裡面累積的關係資料，有多少能帶走？

• 可以匯出：聯絡人、公司、交易、活動紀錄的屬性值（CSV）。
• 匯出很麻煩：Email 開信/點擊的逐筆事件、聊天逐字紀錄、表單提交歷史的關聯。
• 幾乎帶不走：報表設定、清單邏輯、內容資產的版面。

因此每季做一次全物件 CSV 匯出並存進自家雲端儲存，是零成本的保險。若你有工程資源，用 CRM Exports API 排程更省事。

前 30 天上線清單（不花一塊錢）

第一週｜基礎設定

1. 帳號時區設為 Asia/Taipei、語言與貨幣確認（跨境團隊建議介面英文、標籤繁中）
2. 完成 DKIM / SPF / DMARC 設定並用測試信驗證
3. 開啟 Cookie 同意機制，追蹤碼改為條件載入
4. 建立使用者與權限，不要全員都用 super admin

第二週｜資料架構

5. 訂命名規範文件（一頁 Google Doc 就夠）
6. 定義 10 個自訂屬性，寧缺勿濫
7. 保留內建 lifecycle stage，定義每階段的「進入條件」
8. 設計一條 deal pipeline，階段數控制在 5 個以內

第三週｜流量入口

9. 官網主要表單改用 HubSpot form（保留 consent 欄位）
10. 建立 1 個會議連結，接上團隊行事曆
11. LINE / FB Lead Ads 的名單先用人工或 webhook 導入，欄位對齊

第四週｜紀律

12. 每週一份基礎報表（新聯絡人來源、pipeline 金額、48 小時回覆率）
13. 設定每季 CSV 匯出的負責人
14. 寫下「什麼情況下我們會升級」的觸發條件

跨境團隊怎麼把免費版當成起點

台灣新創的擴張路徑通常不是台灣→美國，而是台灣→香港/新加坡→日本或東南亞。HubSpot 免費版可以先把這件事準備好，前提是資料模型一開始就有市場維度。

實務上有三個設計：

• 市場欄位放在 Company 而非 Contact：一家公司在哪個市場，比聯絡人在哪個市場穩定。
• 選單值用 ISO 代碼（tw, hk, sg, jp, au），不要用中文字；未來接資料倉儲或 BI 不用做字串對照。
• 同意紀錄分市場儲存：台灣《個資法》、新加坡 PDPA、歐盟 GDPR 對「可撤回」與「保存期限」的要求不同，同一個布林值不夠用。

我們協助一家台北的 B2B SaaS 團隊（不具名）從 Google Sheets 轉到 HubSpot 時，做法就是先把上述三件事寫成一頁規範，再談工具。當時他們同時在台灣與新加坡試水，Sheets 上的「地區」欄位混用了「台灣／TW／Taiwan／台北」四種寫法。轉入 HubSpot 前的清理工作，比帳號設定本身花的時間更多——這是我們一再看到的模式：遷移的成本在資料，不在工具。

對歐美公司而言，反向的邏輯也成立。若你把亞太的行銷與客服營運放在台灣或香港，HubSpot 免費版可以當作區域團隊的共用客戶檔案層，總部維持 Salesforce 或 Professional 版，中間用 API 同步關鍵欄位。時區上，台北團隊的上班時間覆蓋歐洲早晨與美西下午，交接視窗天然存在。

什麼時候才該升級？

不要因為「功能看起來比較完整」升級，要因為明確的瓶頸升級。合理的觸發條件：

• 每月行銷 Email 寄送量逼近免費上限（2,000 封／月）
• 需要兩條以上的成交流程，且已確認不是流程設計問題
• 手動跟進造成的漏單開始可量化（例如超過 48 小時未回覆的線索比例持續上升）
• 需要多人同時操作，權限混亂已造成資料錯誤
• 需要移除表單與 Email 上的 HubSpot 品牌標記以符合品牌要求

反過來說，如果你的問題是「名單來源亂」、「業務不填資料」、「不知道該追誰」，升級不會解決，只會讓同一團混亂變得更貴。

免費版的價值不在於省錢，在於它給你一段低風險的時間，把資料紀律練起來。多數團隊浪費了這段時間，然後在付費第一年重建一次。

Branch8 的團隊分布在香港、台灣、新加坡、越南與澳洲，長期協助 B2B SaaS、零售與製造業客戶規劃 CRM 與 CDP 架構，從 HubSpot 免費版起步到跨市場的 Salesforce、Segment 整合。如果你正在評估第一次導入，或想在升級前先把資料模型與同意架構整理乾淨，歡迎與我們聊聊你的實際流程。

Sources

• HubSpot — Pricing
• HubSpot — Product & Services Catalog
• HubSpot — Knowledge Base
• HubSpot — Developer Documentation
• LINE — Developers (Messaging API)
• 全國法規資料庫 — 個人資料保護法
• Personal Data Protection Commission Singapore — PDPA
• Google — Email sender guidelines