現正接案 — 2026 第三季
首頁/行業/Salesforce 平台路徑

航空業：Salesforce 解法

航空業的 Salesforce 解法不是拿來賣機票，而是把會員、客服、營運事件、B2B 帳戶與旅程資料串在一起。Salesforce 官方把航空相關場景放在 Travel, Transportation & Hospitality 產業解法中，重點是旅客體驗、服務效率與跨系統資料整合。

// 典型功能模組

會員與旅客 360

整合常旅客資料、偏好、旅程歷史、客服紀錄與補償紀錄，讓服務與行銷更精準。

服務復原與客服中心

把班機異動、行李糾紛、補償流程、客訴分流放進可追蹤的案件流程。

B2B 與企業差旅帳戶

管理旅行社、企業差旅、批發票務與合作夥伴關係，不只看單一旅客，也看帳戶價值。

// EKel 會怎麼落地
  1. 01先界定 Salesforce 不碰哪一些核心營運系統，例如訂位主機、航班營運與票務結算。
  2. 02把會員、客服、B2B 帳戶與服務事件模型設計清楚，避免把航空核心系統複製一份進 CRM。
  3. 03設計航班異動、客訴、補償與會員服務的跨團隊流程。
  4. 04用 Data Cloud / 整合層建立可用但可控的客戶與旅程資料視圖。
// 適合的公司
  • →航空公司、航空服務公司、旅行社集團或企業差旅平台。
  • →會員資料、客服案件與 B2B 帳戶分散在不同系統的團隊。
  • →需要改善服務復原、忠誠計畫或企業客戶管理，但不想動核心訂位系統的專案。
// 參考來源
Salesforce Travel, Transportation, and HospitalitySalesforce Agentforce for Industries
回到行業列表看航空 AI 客製方案 →
// 架構分層

航空 Salesforce 是「關係 + 服務 + 帳戶」三軸結構。

// AXIS 1
旅客關係層
會員 360、旅程歷史、偏好、跨夥伴 loyalty 兌換。由 Sales Cloud + Loyalty Management + Data Cloud 共同承擔——把訂位、會員、互動、補償紀錄收成一個跨系統的旅客主檔。
Sales CloudLoyalty MgmtData CloudMember 360
// AXIS 2
服務事件層
Service Cloud 處理航班異動、行李糾紛、補償申請、客訴 case routing。每個事件帶 audit trail——為什麼這樣處理、誰簽、補了什麼，事後調得出。
Service CloudCase RoutingComp EngineAudit Trail
// AXIS 3
B2B 帳戶層
企業差旅、旅行社、批發票務、partner agreement。Sales Cloud 的 Account Hierarchy 處理 parent corporate → travelling employee 的關係；Experience Cloud 給 partner 與 corporate travel manager 自助 portal。
Sales CloudExperience CloudHierarchyPartner Portal
// 典型導入時程

28 週四階段

完整航空 Salesforce 的標準節奏。MVP 在 Week 14 上線一個業務流程；完整 28 週包含 PSS / GDS 整合、B2B 帳戶層、partner / agency portal。單一垂直流程的 sprint 可以 4-6 週做完。

W1
W4
W14
W24
W28
00
01
02
03
// 00 · Week 1–3
系統盤點

訪談地勤、客服、會員、B2B 主管。盤訂位、行李、會員、客服、企業差旅系統的責任分界——確認哪些 Salesforce 該擁有、哪些只查詢。

// 01 · Week 4–14
會員與服務 MVP

會員 360、服務復原 case routing、補償政策引擎。先做一個典型異動場景的 end-to-end 流程驗證。

// 02 · Week 15–24
B2B 與整合

B2B 帳戶結構、企業差旅合約、partner portal、GDS / 訂位主機 / 票務結算系統整合。loyalty partner 跨夥伴帳務對接。

// 03 · Week 25–28
上線輔導

客服中心、loyalty 與 B2B 三隊輪班 hypercare。runbook、role-based training、稽核 trail 自我演練。

// 常見問題

航空架構討論裡最常出現的 5 件事。

01航空 Salesforce 導入要先布哪幾個 cloud？
典型優先順序是 Service Cloud（客服中心整併、case routing）→ Sales Cloud（B2B 企業差旅、agency 關係）→ Loyalty Management（會員、tier、跨夥伴兌換）→ Marketing Cloud（多通路會員溝通與 journey）→ Data Cloud（跨系統會員 360 與分眾）→ Experience Cloud（partner / corporate travel manager 自助 portal）。實際順序看痛點：客服量爆 → Service Cloud 先；會員流失 → Loyalty + Marketing Cloud 先；B2B 帳務複雜 → Sales Cloud + Experience Cloud 先。
02訂位主機 (PSS / GDS) 跟 Salesforce 怎麼分工？
PSS / GDS 永遠是訂位、艙等、票務的 source of truth——Salesforce 不該複製這層。Salesforce 是「旅客關係 + 服務事件」層：客服 case、補償歷史、會員偏好、企業合約、轉介紀錄。整合方式建議用 Platform Events 接 PSS 的 PNR 變動事件，不要用 nightly batch（航空業時效要求高）。
03服務復原 (service recovery) 該由人工判斷還是規則自動化？
兩者都要，但分層：規則引擎處理「政策可量化」的部分（艙等、會員等級、延誤時數對應的補償上下限），人工處理「需要 judgement」的部分（特殊客戶、媒體風險、跨機構服務）。Salesforce flow + decision matrix 處理前者，case escalation rule + queue 處理後者。關鍵是 audit trail 要記錄「為什麼這個決定」，事後可調。
04Loyalty Management 最適合什麼情況的航空公司？
最甜蜜點是「**已經有 Salesforce + Marketing Cloud 平台、現在要建（或重建）會員系統**」的航空公司。這個情境下 Loyalty Management 跟既有 Service Cloud / Sales Cloud / Marketing Cloud 天然整合——不必再做一層中介系統去同步會員資料。如果再上 Data Cloud（Data 360）把訂位、客服、loyalty、marketing engagement 收成跨系統的會員 360 profile，Loyalty Management 的分眾與 journey 觸發會更精準，價值會再放大。 反過來：如果完全沒有 Salesforce、為了 loyalty 一個功能從零導入整套平台，整體 TCO 通常不划算；或者已有成熟自建會員系統 + 千萬級會員 + 複雜跨區稅務，refactor 風險大過 ROI——這兩個情境通常不建議。
05B2B (企業差旅) 跟 B2C 在同一個 org 還是分 org？
幾乎都是同一個 org 用 record type + sharing rule 隔離。分 org 表面上單純，但「企業客戶的個人旅客」會跨兩邊——資料同步成本大過分隔好處。例外：當 B2B 是獨立子公司（不同稅號、不同合規）才會分 org。設計重點是讓 B2B 帳號有自己的 hierarchy（parent corporate → traveler）跟 B2C 的 household 平行存在。

航空業 Salesforce 導入，要先分清 CRM 與核心營運邊界。

我們可以先幫你畫出會員、客服、B2B 與營運系統的責任分界，再決定 Salesforce 應該承接哪一層。

預約免費諮詢→

我們使用 Cookie

我們使用必要性 Cookie 維持網站運作，並使用選用的分析 Cookie（Google Analytics）了解訪客如何使用本站。詳見 Cookie 政策 與 隱私政策。