Salesforce Marketing Cloud Journey Builder 跨渠道客戶旅程設計實務

很多企業已建立電郵、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）

8. 結語

Salesforce Marketing Cloud Journey Builder 的成效取決於資料、商業目標與營運治理是否一致。企業可先選擇一個高價值場景，統一 Contact Key 與進入條件，再以小型受眾驗證分流、頻率及 Goal。若需要規劃跨渠道旅程、整合 CRM 或建立可衡量的上線流程，可聯絡 LeadsTech，並了解 Salesforce Marketing Cloud 服務。

Salesforce Marketing Cloud 聯繫我們

9. 延伸閱讀

• Marketing Automation 客戶旅程設計指南
  從商業目標、受眾與接觸點開始規劃自動化旅程。
• 全球 Marketing Automation 策略與導入指南
  延伸了解跨市場的資料、內容與營運協作方法。
• 十大 Marketing Automation 工具比較
  比較企業選擇營銷自動化平台時需要考慮的能力。