Shopify 購買後自動化：使用 Shopify Flow 和你的客服系統設定工作流程
Shopify Flow 可以自動化購買後支援中 Shopify 端的步驟，而你的客戶服務台仍然是處理客戶對話、工單負責權及客服跟進的系統。最可靠的設定方式，是使用 Flow 偵測訂單事件、檢查少量條件，然後更新訂單，或向客戶服務台整合傳送結構化資訊。不要將 Flow 單獨視為完整的貨件監察系統：承運商延誤、派送例外及退貨事件，可能需要能夠提供這些訊號的追蹤或退貨平台。
本指南將展示如何設計工作流程、選擇合適的觸發條件、將結果連接至客戶服務台，以及測試自動化流程，同時避免建立重複工單或發送誤導客戶的訊息。
工作流程應該做甚麼
一個實用的購買後工作流程包含四個部分：
- 事件：訂單發生某些變化，例如付款、履行、取消或退款。
- 判斷：Flow 檢查事件是否需要採取行動。條件可以包括訂單金額、配送國家、履行狀態、標籤，或客戶是否已經聯絡支援團隊。
- 行動：Flow 新增標籤、更新訂單、發送電郵或通知，或將資料傳送至外部端點。
- 負責人：當需要作出判斷或與客戶溝通時，由某位人員或客戶服務台隊列接收個案。
目標不是自動化每一次客戶互動，而是在保留清晰的例外交接流程下，減少重複的分類工作。
建立前：定義資料真實來源
先決定哪個系統掌握每項事實。Shopify 通常是訂單、付款、履行、退款及客戶資料的來源。承運商或追蹤平台可能是運輸中掃描、派送例外及派送確認的來源。客戶服務台應該是對話記錄、工單狀態、分配及客服備註的來源。
這項區分可以避免一個常見的設計錯誤：建立一個假設 Shopify Flow 能夠識別所有派送問題的工作流程。Flow 可以對 Shopify 事件，以及透過已連接的應用程式或外部服務提供的資訊作出反應，但不能僅因為訂單已履行，就推斷承運商延誤。履行事件確認履行記錄或狀態已變更；它本身並不能證明包裹正正常運送。
在選擇觸發條件前，先寫下你實際需要的事件。例如：
- 「訂單已履行，而客戶應收到標準的購買後訊息。」
- 「貨件出現承運商例外，而支援團隊應收到優先處理個案。」
- 「退款已建立，如果已有對話，客戶應被轉至退款隊列。」
Shopify Flow 與客戶服務台的建議架構
有兩種實際的連接模式。
模式 1：使用原生客戶服務台整合
如果你的客戶服務台有 Shopify 整合，先安裝並設定它。原生整合通常可以讓訂單詳情顯示在工單內，或讓客服人員直接開啟相關訂單，而無需手動複製資料。具體的事件和行動取決於客戶服務台，因此應在其現行文件中確認，而不要假設所有 Shopify 事件都受支援。
在此模式中，Flow 可以處理 Shopify 端的分類。例如，當訂單符合你的支援標準時，可以新增 post_purchase_priority 等標籤。客戶服務台其後可以使用該標籤、訂單資料或應用程式提供的事件來分配對話。
模式 2：從 Flow 發送 HTTP 請求
當沒有原生行動可以完成交接時，如果相關選項獲支援，Shopify Flow 可以向中介服務、自動化平台或客戶服務台端點發送 HTTP 請求。接收系統應驗證請求、在需要時轉換承載資料，並建立或更新工單。
只有在你能夠控制驗證、重複偵測、錯誤處理，以及傳送至外部服務的資料時，才使用此模式。每次 Flow 執行便簡單地建立新工單的請求，很快便可能產生重複個案。
工作流程 1：將履行交接至客戶支援
這是一個良好的起始工作流程，因為履行是清晰的 Shopify 事件，而其營運結果亦容易衡量。
步驟 1：選擇觸發條件
在 Shopify Flow 中，使用符合你流程的履行相關觸發條件建立工作流程。隨着 Shopify 更新 Flow，確切的觸發條件名稱和可用變數可能會改變，因此請選擇管理員介面中目前顯示的選項，並檢查工作流程編輯器中可用的變數。
步驟 2：新增業務條件
不要將每張已履行的訂單都發送給客服人員。新增能夠識別例外或有用營運分類的條件。例如：
- 訂單具有較高的內部支援優先級。
- 配送目的地屬於有獨立服務隊列的市場。
- 訂單包含需要特殊購買後指示的產品。
- 訂單具有表示過往客戶投訴或人工審查的標籤。
- 履行是部分完成，而客戶可能需要解釋。
讓第一個版本保持狹窄。除非有具體的營運原因，否則「所有國際訂單都轉交支援團隊」這類規則可能會增加而非減少工作量。
步驟 3：選擇行動
對於低風險分類，可以新增訂單標籤或內部備註。對於需要負責人的個案，透過整合發送客戶服務台通知或建立工單。只包括接收團隊所需的資訊：
- Shopify 訂單 ID 和訂單編號
- 客戶姓名和聯絡識別碼
- 配送國家或地區
- 履行狀態及追蹤參考資料（如有）
- 轉交原因
- 建議隊列和優先級
如果客戶服務台 API 要求特定 JSON 格式，請以其文件作為契約，不要猜測欄位名稱。在 Flow 中，盡可能透過變數選擇器插入變數，然後將測試承載資料與接收系統要求的欄位作比較。
步驟 4：防止重複工單
使用冪等策略。在建立新個案前，檢查訂單是否已經有支援標籤、開啟中的工單參考資料，或表示交接已完成的自訂欄位。如果客戶服務台支援冪等鍵，請使用基於訂單和事件的穩定值，而不是時間戳記。如果不支援，請讓中介服務在建立另一個個案前，先搜尋現有的開啟個案。
工作流程 2：派送例外升級處理
派送例外需要更加謹慎，因為事件可能源自 Shopify 以外。只有當追蹤應用程式或整合將可靠事件傳入 Shopify，或傳入 Flow 所使用的端點時，Shopify Flow 才應該作為行動層。
健全的設計如下：
- 承運商或追蹤服務報告例外。
- 追蹤服務或中介服務檢查貨件是否仍然開啟，以及類似例外是否已經處理。
- 系統向客戶服務台或兼容 Flow 的端點發送結構化事件。
- 客戶服務台建立或更新工單、分配適當隊列，並向客服人員顯示追蹤背景。
- 客服人員決定是否聯絡客戶、等待下一次掃描、要求確認地址，或提供已批准的解決方案。
使用受控的例外類別清單，例如地址問題、海關延誤、派送嘗試失敗、貨件損壞或近期沒有掃描記錄。除非底層服務提供目前的預計時間，而且你的客戶服務政策允許此訊息，否則避免自動承諾派送日期。
如果你使用 Flow 為相關訂單新增標籤，請選擇描述狀態而非結果的標籤。當承運商尚未確認最終失敗時，carrier_exception_open 比 delivery_failed 更安全。
工作流程 3：退貨、退款及購買後問題
退貨和退款通常會產生重複問題，但不應將它們合併為單一自動化流程。退款可能已完成，但客戶仍在等待付款提供商入賬款項。退貨可能已提出要求，但尚未收到。每種狀態都應有不同的客戶服務台回應或內部指示。
當你的商店 Flow 設定中提供相關事件時，使用 Shopify Flow 對退貨要求、退款建立、取消或訂單更新等事件進行分類。按照你的政策分配結果：
- 資訊性：新增內部標籤，並讓客戶服務台現有的範本回應常見問題。
- 有時限：當承諾的服務時限面臨風險時，建立或提高工單優先級。
- 人工審查：將損壞貨品、有爭議的退款或不尋常的訂單記錄轉交專員。
- 需要客戶採取行動：只要求缺少的資料，例如相片或更正後的地址。
如果退貨由專用退貨應用程式管理，請將退貨狀態保留在該系統，並將必要狀態傳遞至 Shopify 或客戶服務台。除非有清晰的對賬流程，否則不要在三個系統中維護互相競爭的手動狀態。
如何設定客戶服務台交接
啟用外部行動前，先準備客戶服務台一側。
定義隊列和負責權
建立與實際決策相對應的隊列，而不只是廣泛的標籤。「派送例外」、「地址更正」和「退款審查」通常會導向不同程序。為不完整或無法識別的事件指定後備隊列，避免自動化失敗後無人察覺。
建立精簡的事件結構
使用一致的欄位名稱和值。實用的事件可以包括 event_type、event_id、shopify_order_id、order_number、customer_reference、tracking_number、reason_code、priority 及 occurred_at。發送穩定的事件 ID，並在接收端記錄它。
盡量減少個人資料。客戶服務台可能已能根據訂單編號擷取客戶檔案，因此不要傳送整合不需要的額外客戶資料。
設定客戶聯絡規則
決定哪些事件會建立內部工單、哪些會發送面向客戶的訊息，以及哪些兩者皆會做。承運商例外通常應先進行內部審查，再發送自動電郵。標準履行確認可能適合使用已批准的範本。規則應寫入工作流程文件，讓客服人員知道訊息發送的原因。
測試和監察清單
應分階段測試，而不是一次啟用所有行動。
- 測試觸發條件：確認所選事件會對預期的訂單類型執行，而不會因無關變更而執行。
- 測試條件：使用正面和負面例子，包括部分履行、國際目的地、退款及已有標籤的訂單。
- 檢查承載資料：驗證訂單識別碼、追蹤資料、日期、優先級及原因代碼。確認空白欄位不會導致接收 API 出錯。
- 測試重複行為：多次執行同一事件，並確認不會建立多張有效工單。
- 測試失敗處理：在受控環境中暫時使用無效端點或必填欄位。確認負責人能夠看到失敗。
- 有限度推出：先從一個隊列、市場或事件類型開始。在擴展前檢查工單和客服人員的意見。
同時監察營運和客戶結果。有用的指標包括自動交接數量、重複工單、未分配工單、失敗請求、首次人工審查時間，以及客服人員重新分類的已轉交個案百分比。即使 Flow 執行記錄顯示成功，如果自動化產生更多工單，卻沒有改善負責權或解決效率，也代表運作不佳。
應避免的常見錯誤
- 將履行視為派送證明：履行和派送是不同狀態。
- 為每張訂單建立工單：使用條件和分配門檻，讓客服人員專注於例外情況。
- 傳送不穩定的識別碼：訂單編號、事件 ID 和追蹤參考資料應保持一致的對應方式。
- 跳過驗證：將接收客戶或訂單資料的 HTTP 端點視為受保護服務。
- 忽略應用程式和方案限制：確認目前設定可用哪些 Flow 行動、觸發條件、API 呼叫及客戶服務台功能。
- 將政策決策自動化：讓 Flow 分類例行個案，但退款、補償、地址變更及疑似欺詐應在已批准規則和人工審查範圍內處理。
實際推出順序
對大多數 Shopify 商店而言，最安全的順序是先開始使用內部標籤或通知，然後加入客戶服務台分配，最後才引入面向客戶的自動化。先從一個容易驗證的事件開始，例如履行例外或已知退款狀態。記錄觸發條件、條件、行動、負責人、重複規則及失敗路徑。工作流程產生穩定結果後，再逐一加入更多事件類型。
最佳設計不是擁有最多 Flow 行動的設計，而是在適當時間向客服人員提供適當背景、留下可審核記錄，並避免讓客戶重複提供 Shopify 或相關追蹤系統中已經有的資料。
常見問題
Shopify Flow 可以直接建立客戶服務台工單嗎？
這取決於你的客戶服務台及商店中可用的整合。如果沒有原生 Flow 行動，可以在獲支援的情況下，透過 HTTP 請求將事件資料傳送至中介服務或客戶服務台端點。啟用工作流程前，確認接收系統的驗證、承載資料及工單建立要求。
Flow 可以偵測包裹遲到嗎？
單靠履行狀態不能。遲到或延誤的貨件需要派送時間規則，以及可靠的承運商或追蹤事件來源。使用能夠提供這些訊號的追蹤整合或服務，然後將事件轉交客戶服務台或適當的 Shopify 工作流程。
每個購買後事件都應建立工單嗎？
不應。對低風險事件，使用標籤、內部通知或現有的客戶服務台自動化。當需要人員調查、聯絡客戶、批准補救措施或監察例外時，才建立工單。
如何停止重複工單？
使用穩定的事件 ID 或訂單與事件組合鍵，檢查是否已有開啟工單，並記錄交接結果。對於簡單工作流程，support_handoff_complete 等標籤可以提供幫助；但當事件可能重試時，客戶服務台或中介服務查詢會更安全。
推出前應測試甚麼？
測試觸發條件、條件、資料對應、權限、重複行為、失敗警報及面向客戶的措辭。包括部分履行、缺少追蹤資料、重複事件、退款，以及已經有支援個案的訂單。
