很多企業已建立電郵、SMS、App 推播及銷售跟進流程，但各渠道仍各自運作，客戶收到的訊息重複或時機不一致。從 LeadsTech 的實務觀察，先把客戶識別、資料更新責任與各渠道的服務角色設定清楚，才能讓自動化旅程既能回應客戶行為，也不會增加團隊的日常維護負擔。本文會說明如何以 Salesforce Marketing Cloud Journey Builder 把資料、觸發條件、分流、訊息與成效衡量連成可維護的跨渠道旅程。
1. 本文重點精華
- Journey Builder 是 Marketing Cloud Engagement 的旅程編排工具，價值不只是自動發送訊息，而是按客戶事件與資料安排下一步。
- 企業應先定義商業目標、Contact Key、Entry Source、同意狀態及退出條件，再設計畫布活動。
- Decision Split、Engagement Split、Wait 及不同渠道訊息必須配合資料更新速度與頻率規則，避免重複或過度接觸。
- 上線前應完成測試、版本、權限及監察安排，並以目標完成率、渠道互動及業務結果評估成效。
2. Journey Builder 跨渠道客戶旅程應由甚麼開始？
Journey Builder 可設計及管理自動化、多步驟的客戶溝通。客戶由 Entry Source 進入旅程，再經過訊息、等待、分流、資料更新或 Salesforce Sales and Service Cloud 活動，直至達到 Goal、符合 Exit Criteria 或走到旅程終點。這些能力只有在目標、資料與營運規則清楚時才有商業價值。
設計時先回答三個問題：旅程希望改變哪個客戶行為、甚麼事件代表客戶需要下一步，以及哪項結果可以證明旅程有效。以「提高產品示範預約」為例，入口可能是下載技術規格，下一步不是立即連續發送推廣電郵，而是根據公司規模、產品興趣及近期互動安排教育內容、顧問跟進或停止推廣。
假設一家工業設備企業同時服務香港、台灣及東南亞市場。客戶可能先下載白皮書，再參加網上研討會，最後由銷售建立商機。如果電郵、活動平台與 CRM 使用不同識別碼，Journey Builder 可能把同一人當作多個 Contact，造成重複訊息及錯誤歸因。改善方法是先統一 Contact Key、來源欄位、同意狀態與商業階段，再建立旅程。
3. 如何設計 Journey Builder 的資料與進入條件？
Salesforce 官方資料顯示，Journey Builder 的 Entry Source 可包括 Data Extension、API event、Audience、CloudPages、Salesforce data 或其他事件。企業應按資料到達速度與旅程用途選擇來源：批次名單適合定期培育；API event 則較適合表單提交、交易或服務事件等需要快速回應的場景。
Entry Source 不應只包含電郵地址。最低限度要定義穩定的 Contact Key、語言、市場、同意狀態、產品興趣、事件時間及後續分流所需欄位。Journey Data 是客戶進入旅程當刻帶入的資料；Contact Data 則可能隨資料模型更新。設計 Decision Split 前要先確認使用哪一類資料，否則客戶資料已變更，分流仍可能依照舊值。
重複進入規則亦要配合業務事件。同一客戶是否可以再次進入？要等待多久？不同交易是否應視為獨立旅程？若交易型旅程需要逐筆處理，可加入可靠的交易識別碼；若是長期培育，則應限制短期重複進入，並在客戶成為商機或取消同意時退出。
圖 1：跨渠道旅程由進入事件、受眾規則、分流、渠道行動連接至目標與退出條件。
4. 如何安排分流、等待與跨渠道訊息？
Decision Split 按客戶或旅程資料依序評估條件；Engagement Split 則可根據訊息開啟、點擊或退信等互動結果分流。條件的先後次序很重要，因為客戶會沿第一個符合的路徑前進。每條路徑都應有明確業務意思，不要建立大量只有內部人員才看得懂的分支。
Wait 活動用來控制節奏，也讓資料有時間回寫。等待時間不應只按「行銷習慣」設定，而要考慮客戶決策週期、渠道時效及 CRM 更新延遲。例如客戶提交報價後，應先讓銷售接手；若商機已建立，旅程便退出，避免系統仍發送初階教育內容。
跨渠道不代表每個人都收到所有渠道。企業可按同意範圍、偏好、互動及業務價值選擇 Email、SMS、Mobile Push、廣告受眾或銷售任務。每個渠道要有不同角色：電郵解釋內容、SMS 處理時效提醒、App Push 促成應用內行動、CRM Task 交由銷售或客服跟進。
5. Journey Builder 上線前要檢查甚麼？
旅程啟用後，修改通常要透過新版本管理，因此上線前應完成可重複的檢查。以下七項可以作為發布門檻：
- Entry Source、Contact Key 及必要欄位是否在測試資料中完整？
- 同意狀態、退訂及敏感資料處理是否符合目標市場要求？
- Decision Split 的條件順序、預設路徑及一對多資料關係是否已驗證？
- 等待時間、重複進入及不同旅程之間的頻率是否會造成過度接觸？
- 每封訊息的寄件人、個人化欄位、連結、Fallback 及追蹤是否正常？
- Goal、Exit Criteria、抑制名單及銷售接手條件是否一致？
- Journey 名稱、版本說明、負責人、停止流程及異常通知是否已記錄？
圖 2：旅程啟用前應同時檢查資料、同意、頻率、測試與衡量設定。
先以小型測試受眾走完整條旅程，檢查實際等待、分流及渠道結果。測試通過後再逐步放大受眾，並保留回復方案。若旅程牽涉 API event 或 CRM 更新，也要測試重送、延遲、缺值及外部系統暫時不可用的情況。
6. 如何衡量客戶旅程成效？
Journey Builder 的 Goal 可以表示旅程希望促成的結果，但企業不應只看發送量、開啟率或點擊率。衡量框架可分三層：第一層是旅程健康，例如成功進入人數、錯誤、退出及各活動通過量；第二層是渠道互動，例如送達、點擊、回覆或轉換；第三層是商業結果，例如合資格 Lead、示範預約、商機、續約或服務問題解決。
以工業設備企業的假設場景為例，可比較下載規格後 30 日內的預約率、Lead-to-opportunity conversion rate、銷售首次回覆時間及重複訊息比例。這些指標應按市場、產品與客戶階段分層，並與沒有進入旅程或使用舊流程的基準比較。若某路徑表現較差，先檢查資料品質、受眾定義與渠道時機，再調整內容。
每次優化只集中處理一至兩個主要假設，建立新版本並記錄改動、預期影響、啟用日期與結果。這樣 Journey Builder 才會成為可持續改善的營運流程，而不是難以維護的自動化畫布。
7. 常見問題（FAQ）
Journey Builder 是否等同電郵自動化？
不是。Journey Builder 可以把 Entry Source、資料判斷、等待、跨渠道訊息、資料更新及 Salesforce 活動串成客戶旅程；電郵只是其中一種渠道。
Journey Builder 可以即時觸發旅程嗎？
可以，API event 等入口可用於事件驅動場景，但實際時效仍取決於資料來源、整合、系統處理及渠道。上線前應用真實流程測試延遲。
Decision Split 與 Engagement Split 有甚麼分別？
Decision Split 主要按客戶或旅程資料分流；Engagement Split 則按訊息開啟、點擊或退信等互動分流。選擇時要先確認決策所需資料何時可用。
客戶可以同時進入多個 Journey 嗎？
可以，但企業要建立跨 Journey 的優先級、抑制與頻率規則。否則不同部門可能在短時間內向同一客戶發送互相衝突的訊息。
甚麼時候需要顧問協助 Journey Builder？
當旅程牽涉多個資料來源、CRM、API、不同市場同意規則或跨部門營運時，顧問可協助資料設計、整合、測試、治理及成效框架，而不只是建立畫布。
8. 結語
Salesforce Marketing Cloud Journey Builder 的成效取決於資料、商業目標與營運治理是否一致。企業可先選擇一個高價值場景，統一 Contact Key 與進入條件，再以小型受眾驗證分流、頻率及 Goal。若需要規劃跨渠道旅程、整合 CRM 或建立可衡量的上線流程，可聯絡 LeadsTech，並了解 Salesforce Marketing Cloud 服務。
9. 延伸閱讀
- Marketing Automation 客戶旅程設計指南
從商業目標、受眾與接觸點開始規劃自動化旅程。 - 全球 Marketing Automation 策略與導入指南
延伸了解跨市場的資料、內容與營運協作方法。 - 十大 Marketing Automation 工具比較
比較企業選擇營銷自動化平台時需要考慮的能力。
