台灣旅遊業導入 HubSpot CRM:從電郵詢價到自動化報價

台灣旅遊業者導入 HubSpot CRM 的核心,是把散落在電郵信箱的詢價轉成結構化 Deal 物件,再以 Quotes API 與行程模板自動產出報價。重點不在工具,而在資料模型設計、人機分工邊界,以及跨境團隊的時區分工。

為什麼旅遊業的詢價流程特別難自動化?

旅遊產品不是 SKU。一張訂單可能包含機票艙等、三段住宿、兩段陸上交通、導遊語言、保險級距,以及一個會隨人數跳動的分攤價。這讓多數電商式的 CRM 自動化設計在旅遊業水土不服。

市場規模本身不是問題。根據聯合國世界旅遊組織(UN Tourism)的《World Tourism Barometer》,2024 年全球國際旅客抵達人次已大致回到疫情前水準,約 14 億人次。台灣方面,交通部觀光署的觀光統計資料顯示,2024 年來台旅客約 786 萬人次、國人出國人次則超過 1,600 萬,出入境兩端的詢價量都在回升。

問題出在詢價的「形狀」。

旅遊詢價的三個結構性難題

1. 輸入是非結構化的。詢價多半以電郵、LINE 官方帳號、FB 私訊、網站表單自由欄位進來,內容是一段散文:「我們一家五口,小孩分別 4 歲和 9 歲,想過年期間去北海道 6 天,預算一人 5 萬以內。」沒有任何欄位。
2. 報價是多版本的。同一組客人常需要 A/B/C 三版行程,每版又有「含機票/不含機票」。業務在 Excel 上複製貼上,版本控管靠檔名。
3. 成本會變動。房價、包車、匯率每天不同。報價單發出後三天,毛利可能已經被吃掉。

這三點決定了導入順序:先解決輸入結構化,再解決版本控管,最後才碰成本動態化。倒過來做的專案,幾乎都卡在第一關。

導入前該怎麼盤點現況基準?

Branch8 在協助一間以日韓線為主的台灣中型旅行社(線上詢價為主、內外業合計約 20 人的團隊)規劃 HubSpot 導入時,第一個動作不是開 Portal,是做兩週的流程盤點。沒有基準,之後任何「自動化有沒有效」的討論都會變成感覺之爭。

建議盤點以下五項,全部用現有系統就能撈:

• 詢價來源分布:各渠道進件佔比(電郵 / 表單 / LINE / 電話)
• 首次回應時間(First Response Time):從詢價進來到第一封實質回覆的中位數,不是平均數
• 報價版本數:每筆成交案件平均產出幾版報價
• 重工比例:業務每天花多少時間在複製貼上既有行程內容
• 資料落地位置:客戶資料現在實際存在哪裡(Outlook 聯絡人?個人 Excel?共用雲端硬碟?)

最後一項通常最難看。旅遊業的客戶資料分散在業務個人信箱,是離職風險也是個資風險——依《個人資料保護法》(全國法規資料庫),蒐集、處理、利用個人資料應有特定目的並採取適當安全維護措施,「存在某個業務的私人 Excel」很難說得過去。

資料模型:把「詢價」變成可計算的物件

HubSpot 原生的 Contact / Company / Deal 三件組不足以描述旅遊案件。依 HubSpot 開發者文件,Professional 以上方案支援自訂物件(Custom Objects),這是整個設計的地基。

建議的物件結構

Deal(案件) — 一組客人的一次出遊意圖。Pipeline 階段:詢價進件 → 需求確認 → 報價送出 → 議價 → 訂金收訖 → 出團 → 回團。

Custom Object: Itinerary Component(行程元件) — 可重複使用的最小單位:一晚住宿、一段包車、一張門票。每個元件帶成本、建議售價、供應商、有效期間。

Custom Object: Quote Version(報價版本) — 關聯到 Deal,記錄這一版由哪些元件組成、總成本、總售價、毛利率。

Contact 上的旅客屬性 — 護照效期(只存到期月份,不存號碼)、飲食禁忌、偏好艙等、同行人數結構。

建立自訂物件的 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": "itinerary_component",
7    "labels": { "singular": "行程元件", "plural": "行程元件" },
8    "primaryDisplayProperty": "component_name",
9    "properties": [
10      { "name": "component_name", "label": "元件名稱", "type": "string", "fieldType": "text" },
11      { "name": "component_type", "label": "類型", "type": "enumeration", "fieldType": "select",
12        "options": [
13          {"label":"住宿","value":"accommodation"},
14          {"label":"交通","value":"transport"},
15          {"label":"門票","value":"ticket"},
16          {"label":"導遊","value":"guide"}
17        ]},
18      { "name": "unit_cost_twd", "label": "單位成本(TWD)", "type": "number", "fieldType": "number" },
19      { "name": "valid_until", "label": "報價有效至", "type": "date", "fieldType": "date" }
20    ],
21    "associatedObjects": ["DEAL"]
22  }'

一個常見錯誤:把行程元件直接做成 Deal 的自訂欄位(住宿1、住宿2、住宿3……)。短期能跑,但無法做供應商分析、無法算真實毛利、也無法在成本變動時批次更新。欄位是屬性,元件是物件——這條界線一旦畫錯,六個月後要重做。

從電郵到 Deal:進件如何自動分流?

第一層:把所有渠道收攏進同一個收件匣

HubSpot 的 Conversations Inbox 支援連結團隊共用信箱與表單。第一步是把 info@、sales@、各線業務的對外信箱全部轉發進來。這一步沒有技術難度,但有組織阻力——業務會覺得自己的客人被「公開」了。實務上的折衷是:進件統一,但分配後的所有權清楚標記在 Deal Owner 上。

第二層:用 LLM 把散文變成欄位

這是 2026 年與三年前最大的差別。過去要靠正則表示式硬解電郵,準確率低到沒人願意用。現在可以用一個結構化輸出的 LLM 呼叫,把自由文字轉成 JSON,再寫回 HubSpot。

1# Webhook 收到新 Conversation 後觸發
2import json, requests
3
4EXTRACTION_SCHEMA = {
5    "type": "object",
6    "properties": {
7        "destination": {"type": "string"},
8        "depart_month": {"type": "string"},
9        "nights": {"type": "integer"},
10        "pax_adult": {"type": "integer"},
11        "pax_child": {"type": "integer"},
12        "child_ages": {"type": "array", "items": {"type": "integer"}},
13        "budget_per_pax_twd": {"type": ["integer", "null"]},
14        "confidence": {"type": "number"}
15    },
16    "required": ["destination", "pax_adult", "confidence"]
17}
18
19def extract(email_body: str) -> dict:
20    # 任何支援 structured output 的模型皆可
21    resp = llm.responses.create(
22        model="gpt-4.1-mini",
23        input=f"抽取旅遊詢價要素,無法判斷的欄位填 null:\n\n{email_body}",
24        response_format={"type": "json_schema", "json_schema": EXTRACTION_SCHEMA}
25    )
26    return json.loads(resp.output_text)
27
28
29def upsert_deal(contact_id: str, data: dict):
30    if data["confidence"] < 0.75:
31        data["_route"] = "human_review"   # 低信心一律進人工佇列
32    requests.post(
33        "https://api.hubapi.com/crm/v3/objects/deals",
34        headers={"Authorization": f"Bearer {TOKEN}"},
35        json={
36            "properties": {
37                "dealname": f"{data['destination']} / {data['pax_adult']}大{data.get('pax_child',0)}小",
38                "pipeline": "travel_inquiry",
39                "dealstage": "needs_confirmation" if data["confidence"] >= 0.75 else "human_review",
40                "destination": data["destination"],
41                "pax_total": data["pax_adult"] + data.get("pax_child", 0)
42            },
43            "associations": [{
44                "to": {"id": contact_id},
45                "types": [{"associationCategory": "HUBSPOT_DEFINED", "associationTypeId": 3}]
46            }]
47        }
48    )

關鍵設計是那個 confidence 門檻。不要追求 100% 自動化;要追求「自動化的部分可信、不可信的部分明確標記」。把低信心案件丟進人工佇列,比讓它悄悄帶著錯誤資料往下游跑好得多。

注意 API 配額。依 HubSpot 開發者文件,私有應用的請求速率有每十秒與每日上限(依方案層級不同),批次回填歷史資料時務必使用 Batch API 並加上指數退避重試。

1from tenacity import retry, wait_exponential, stop_after_attempt
2
3@retry(wait=wait_exponential(multiplier=1, max=30), stop=stop_after_attempt(5))
4def batch_upsert(objects):
5    r = requests.post(
6        "https://api.hubapi.com/crm/v3/objects/deals/batch/upsert",
7        headers={"Authorization": f"Bearer {TOKEN}"},
8        json={"inputs": objects}
9    )
10    r.raise_for_status()
11    return r.json()

自動化報價怎麼做才不會算錯錢?

HubSpot 提供 Quotes 物件與 Line Items,可以透過 API 組裝報價單並產生對外連結。流程是:選定行程元件 → 產生 Line Items → 建立 Quote → 套用模板 → 發送。

1# 1. 建立 Line Item 並掛到 Deal
2curl -X POST https://api.hubapi.com/crm/v3/objects/line_items \
3  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
4  -d '{
5    "properties": {
6      "name": "札幌市區飯店 4 晚(雙人房)",
7      "quantity": "3",
8      "price": "18600",
9      "hs_cost_of_goods_sold": "14200",
10      "currency": "TWD"
11    }
12  }'
13
14# 2. 建立 Quote
15curl -X POST https://api.hubapi.com/crm/v3/objects/quotes \
16  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
17  -d '{
18    "properties": {
19      "hs_title": "北海道 6 日 / 版本 B(含機票)",
20      "hs_expiration_date": "2026-03-15",
21      "hs_currency": "TWD",
22      "hs_language": "zh-tw"
23    }
24  }'

三個務必內建的防呆:

1. 成本有效期檢核。每個行程元件帶 valid_until。組報價時若任一元件已過期,系統擋下並提示重新向供應商確認,而不是直接送出。
2. 毛利率下限。在 Workflow 中加一條規則:毛利率低於門檻的報價不得自動發送,必須主管核可。HubSpot 的 Approvals 功能(Sales Hub Enterprise)可直接處理這段。
3. 匯率快照。日圓、韓元報價務必記錄當下換匯基準並寫進 Quote 的自訂屬性。客人回頭問「為什麼跟上週不一樣」時,你有依據。

自動化與人工的邊界該劃在哪?

誠實說,全自動報價在旅遊業不成立,至少在客製團體線不成立。可自動化與不可自動化的分野大致如下:

適合自動化:第一封回覆(確認收到 + 補問缺漏資訊)、標準行程的制式報價、報價到期前提醒、訂金未付提醒、出團前文件催繳、回團後評價邀請。

不適合自動化:行程設計取捨的建議、議價、客訴處理、突發狀況(航班取消、天候)的應變溝通。

自動化真正的價值不是取代業務,是把業務從「每天打 40 封內容八成相同的信」中釋放出來。根據 HubSpot 的《State of Marketing》調查,行銷與業務團隊導入 AI 輔助後,最常被提到的效益是內容產出與重複性溝通的時間節省,而非直接的成交率跳升——這個預期值設定對專案說服力很重要,不要向老闆承諾你控制不了的轉換率。

跨境與跨時區團隊怎麼接這套系統?

台灣旅行社的作業現實往往是跨境的:業務在台北,日本線的地接在大阪,東南亞線的訂房組可能在吉隆坡或胡志明市,歐美客源的詢價則在台北深夜進來。

HubSpot 的 Workflow 可以依時間與地區做路由:

• 台北工時內(09:00–18:00 GMT+8)進件 → 直接指派給對應線別業務
• 台北非工時進件 → 自動發出確認回覆,同時依目的地區域指派給該區支援人員,隔日台北接手
• 歐美市場詢價 → 以該客戶所在時區排程跟進郵件,避免在對方凌晨三點寄信

這也是許多歐美業者把 APAC 營運中心設在亞洲的實際理由。香港、新加坡、台北三個時區帶,加上馬來西亞、越南、菲律賓的交付能量,可以做到接近 follow-the-sun 的覆蓋,而不必在總部增加夜班編制。Branch8 的團隊分布在香港、新加坡、台灣、越南、馬來西亞、印尼、菲律賓與澳洲,處理的正是這類需要語言、法規與時區同時到位的場景——繁中、簡中、英文、日文的回覆品質差異,客人是看得出來的。

台灣個資法與跨境資料傳輸要注意什麼?

旅遊業蒐集的資料敏感度高於一般 B2C:護照資訊、同行關係、健康與飲食限制、信用卡末碼。導入 CRM 時要同步處理幾件事:

• 特定目的明確化。表單與電郵自動回覆中載明蒐集目的、利用期間與地區,並提供查詢、更正、刪除的管道。《個人資料保護法》對此有明文要求(全國法規資料庫)。
• 最小化原則。護照號碼與完整出生年月日不要進 CRM,留在訂位系統即可。CRM 裡存到期月份與年齡區間足以支撐行銷與報價邏輯。
• 權限分層。HubSpot 的 Teams 與屬性層級權限可以讓業務只看到自己線別的客戶;財務看得到金額但看不到聯絡方式。
• 跨境傳輸。若資料會流向境外的地接或支援團隊,先確認合約中有資料處理條款。歐盟客源另需考慮 GDPR 的資料主體權利(European Commission 的資料保護頁面有官方說明)。
• 留痕。CRM 的最大合規優勢其實是:所有存取都有紀錄。相較於散落在個人 Excel 的現況,這是一次顯著的體質改善。

90 天導入路線怎麼排?

第 1–3 週:盤點與資料模型。流程訪談、物件結構設計、屬性命名規範(建議全部用英文 snake_case,顯示名稱用中文,避免日後 API 整合踩雷)。

第 4–6 週:進件統一。Conversations Inbox 上線、表單改版、Deal Pipeline 建立。這階段先不碰 AI,讓團隊習慣「所有詢價都在 HubSpot 裡」。

第 7–9 週:報價模板化。把過去一年最常賣的 20 條行程拆成行程元件,建立 Quote 模板。這是最花人力也最有價值的一段,無法外包給工具。

第 10–12 週:自動化與 AI 擷取。上線電郵解析、低信心人工佇列、提醒類 Workflow。先用影子模式跑兩週(AI 抽取結果只寫入備註不寫入欄位),比對準確率後再正式切換。

哪些失敗模式最常見?

• 一次要做完所有事。同時上線 CRM、客服、行銷自動化與 AI,團隊會直接放棄。
• 沒有人負責資料品質。自訂物件建完沒人維護元件成本,三個月後全部過期,系統變成裝飾。
• 把 CRM 當成監控工具。如果業務感覺 HubSpot 是用來算他們 KPI 的,資料填寫品質會立刻崩壞。先讓系統幫他們省事,再談管理可視性。
• 低估內容工作量。20 條行程拆元件,是編輯工作不是 IT 工作。要編列人力。
• AI 擷取沒有退場機制。模型抽錯時若無人工覆核路徑,錯誤會一路跑到報價單上,代價是信任。

如果你正在評估把分散在信箱與 Excel 的詢價流程搬進 HubSpot,或需要同時覆蓋台灣、香港、新加坡與東南亞市場的 CRM 導入與營運支援,歡迎與 Branch8 聊聊你的現況盤點與資料模型設計。

Sources

• HubSpot — Knowledge Base
• HubSpot — Developer Documentation
• HubSpot — State of Marketing Report
• UN Tourism — World Tourism Barometer
• 交通部觀光署 — 觀光統計
• 全國法規資料庫 — 個人資料保護法
• European Commission — Data Protection
• OpenAI — API Documentation