首頁博客資源如何在 6 個步驟中自動化貨件通知：觸發條件、渠道及範本

如何在 6 個步驟中自動化貨件通知：觸發條件、渠道及範本

17TRACK

要自動化出貨通知，請將出貨事件連接至訂單記錄，定義哪些狀態變更需要發送訊息，選擇允許的傳送渠道，並為每個觸發條件附加範本。然後在推出前加入防止重複、例外處理及測試。以下六個步驟展示電子商務團隊如何建立工作流程，在不發送重複或誤導性提醒的情況下，為客戶提供有用更新。

6步驟自動化出貨通知觸發條件、渠道及範本

本指南適用於負責購買後溝通的商戶、電子商務營運團隊及開發人員。建議從一小組可靠通知開始：承運商接收、派送中、已送達，以及需要客戶採取行動的例外情況。只有在其他訊息能回答不同的客戶問題時，才加入這些訊息。

1. 將追蹤事件連接至正確的訂單及收件人

運輸標籤、承運商掃描及客戶通知是不同的事情。建立標籤並不代表承運商已接收包裹。你的自動化流程從一開始就應保留這項區別。

首先，確定哪個系統負責通知決策。這可以是商店的通知工作流程、追蹤應用程式，或連接至訂單管理系統的服務。為每種訊息類型指定一個負責系統，以免多個系統各自發送相同更新。

兩種實際的實施方式如下：

  • 基於應用程式的設定：當你的團隊希望設定受支援的事件及面向客戶的訊息，而不想建立完整整合時，請使用電子商務追蹤應用程式。對 Shopify 商戶而言，17TRACK 應用程式頁面是評估出貨追蹤及通知工作流程的合適起點。在設定規則前，請確認具體觸發條件、渠道、自訂選項及方案要求。
  • 基於 API 的設定：當出貨事件必須傳送至現有訂單系統或自訂訊息工作流程時，請使用追蹤整合。17TRACK Tracking API及其官方文件是相關的實施參考。請確認你打算使用的整合所採用的事件傳送機制、資料欄位、驗證方式及重試行為。接收追蹤資料與發送客戶訊息是兩項不同的責任。

無論選擇哪種方式，都要將每件出貨對應至正確的訂單及收件人。有用的內部記錄包括：

  • 訂單參考編號及出貨識別碼。
  • 追蹤號碼及承運商識別碼（如有）。
  • 該次出貨所包含的商品，尤其是拆分訂單。
  • 客戶聯絡資料、語言、時區及渠道偏好。
  • 最近一次已接收的出貨狀態及事件發生時間。
  • 通知記錄，包括每則訊息涉及哪件出貨。

請將事件發生時間與系統接收更新的時間分開記錄。延遲掃描不應自動變成新的客戶提醒。同時保留承運商的原始描述及標準化狀態，讓支援團隊可以調查含糊事件。

2. 定義能反映有意義出貨變更的觸發條件

觸發條件應代表與客戶相關的變更，而不是每一筆新的追蹤記錄。多次設施掃描可能都只是代表「運送中」。為每次掃描發送通知會造成噪音，卻無助於客戶作出決定。

將傳入事件對應至一小組易於理解的狀態。以下表格是建議的工作流程，而不是適用於所有承運商的通用狀態字典。

觸發條件發送條件訊息目的
已建立標籤可選；區分準備階段與承運商持有包裹。說明追蹤資料已準備就緒。
承運商已接收受支援的事件顯示承運商已接收包裹。確認出貨已進入承運商網絡。
運送中可選的里程碑；抑制重複的例行掃描。提供有意義的進度，而不是逐次掃描資訊。
派送中傳入狀態明確支援這項解讀。協助客戶準備接收包裹。
派送例外發現有意義的問題或需要採取行動。解釋問題及下一個有用步驟。
已送達承運商報告這件出貨已送達。確認報告的結果並提供求助途徑。

處理例外時要比處理例行里程碑更加謹慎。派送失敗、海關問題、地址問題及退回寄件人事件可能需要不同指示。如果事件沒有說明客戶應採取的行動，請勿自行編造解決方案。

對於「最近沒有更新」規則，請根據服務及路線選擇合適門檻，而不是套用一個通用時間間隔。沒有掃描並不代表包裹遺失。應將不確定個案轉交內部審查隊列，或發送準確描述已知情況的中性更新。

請將預計送達日期與出貨狀態分開。只有在擁有可靠來源時才加入估算，並明確標示為估算；不要以你的營運無法支持的計算承諾取代缺失資料。

3. 選擇渠道並設定聯絡規則

選擇渠道應基於它是否適合訊息及客戶偏好，而不只是因為渠道可用。電郵是發送詳細更新的實用起點。對於有時效性的行動，更即時的渠道可能很有用，但只有在許可、供應商規則及當地要求允許的情況下才可使用。

  • 電郵：適合提供訂單背景、追蹤連結、拆分出貨說明及支援指示。請加入純文字版本並檢查流動裝置版面。
  • SMS：在獲准的情況下，適合發送簡短且可採取行動的提醒。識別發送者，保持訊息集中，避免披露不必要的訂單資料。
  • 推送通知：適用於使用你的應用程式並已啟用通知的客戶。連結至相關出貨，而不是一般首頁。
  • 訊息應用程式：當客戶已經使用該渠道，且你的實施方式符合平台的許可及訊息要求時，可以考慮使用。
  • 追蹤頁面：將其用作詳細參考目的地。它可補充外發通知，但當客戶需要採取行動時，不能取代提醒。

記錄各渠道之間的關係。例如，可以使用電郵發送例行里程碑，並使用獲准的流動渠道處理需要採取行動的派送問題。不要自動透過所有可用渠道發送每個事件。

設定免打擾時段處理方式及後備政策。臨時電郵失敗不應自動授權發送 SMS。切換渠道前，請確認你擁有適當的聯絡資料及許可，並確認其他系統尚未發送該訊息。

保持出貨更新的營運性質。加入宣傳內容可能影響訊息在適用規則下的處理方式。在美國，FTC 的 CAN-SPAM 指引說明，當商業內容與交易內容結合時，訊息的主要目的十分重要。不要假設所有提及訂單的訊息都可豁免商業電郵要求。

4. 建立具備清晰後備行為的範本

每個範本都應回答三個問題：發生了甚麼？這對這件出貨意味着甚麼？客戶下一步應做甚麼？使用條件欄位，讓缺失資料乾淨地消失，而不是留下損壞的佔位符。

以下例子是起始範本。方括號中的變數僅作說明，並非特定平台的範本語法。

承運商接收電郵

主旨：你的訂單 [order_number] 出貨已在途中

你好 [first_name]，

[carrier_name] 已接收你訂單 [order_number] 的出貨。你可以在這裡查看進度：[tracking_link]。

[如有可靠估算：[estimated_delivery_date] 預計送達。此估算可能會變更。]

[如訂單已拆分：此出貨包含 [shipment_items]。訂單中的其他商品將有獨立的追蹤更新。]

派送中訊息

根據承運商最新更新，你訂單 [order_number] 的出貨現正派送中。查看進度及任何可用的派送詳情：[tracking_link]。

除非你的營運有充分依據支持該承諾，否則不要加入保證的抵達時間。「派送中」是報告的狀態，並不保證包裹會在當天完成派送。

包含已核實下一步的例外訊息

主旨：訂單 [order_number] 的派送更新

承運商就你的出貨報告了 [plain_language_issue]。[verified_next_step]。在這裡查看最新詳情：[tracking_link]。如需協助，請透過 [support_link] 聯絡我們。

如未確認下一步，請將該句替換為：「我們目前尚未有已確認的下一步。請查看追蹤頁面以取得更新，或聯絡我們的支援團隊。」只有在團隊確實已分派審查時，才可表示團隊正在調查。

已送達電郵

主旨：你的出貨已標記為送達

[carrier_name] 已將你訂單 [order_number] 的出貨標記為於 [delivery_date] 送達。在這裡查看任何可用的派送詳情：[tracking_link]。如你找不到包裹，請透過 [support_link] 聯絡我們，以便我們協助你了解下一步。

對拆分訂單使用出貨層級的措辭。「你的訂單已送達」在另一個包裹仍在運送中時可能會造成誤導。如果承運商名稱、日期或客戶姓名不可用，請使用經測試的替代句子，而不要顯示空白欄位。

5. 加入防止重複、過時及誤導性訊息的安全措施

自動化需要記錄已完成的操作。只要有事件傳入就發送訊息的工作流程，可能會在重試後重複提醒，或在較新的里程碑出現後發送過時資訊。

  • 防止重複處理：如有穩定的事件識別碼，請使用該識別碼。否則，請從合適欄位定義去重鍵，例如出貨、事件類型及事件發生時間。另行記錄相應通知是否已排程或發送。
  • 抑制狀態重複：對應至同一面向客戶狀態的多次掃描，不應自動產生多則訊息。
  • 發送前檢查事件相關性：發送前重新評估隊列中的訊息。如果之後已報告送達，請抑制舊的運送中提醒。
  • 有意處理修正：保留原始事件歷史並審查表面上的狀態倒退。不要假設每個較晚抵達的事件必然較新或更準確。
  • 安全重試：區分發送失敗與結果未知。在支援的情況下，使用供應商的冪等功能，降低重試產生另一則訊息的可能性。
  • 保護收件人配對：絕不要僅根據未經核實的追蹤號碼配對，將出貨與客戶關聯。
  • 升級未解決的例外：指定營運負責人，而不是反覆向客戶發送相同警告。

對於自訂整合，請遵循供應商記錄的驗證、事件確認及重試方式。保持處理日誌有用，但不要將不必要的個人資料複製到日誌中。追蹤連結也應避免披露其他客戶的訂單，或超出收件人所需範圍的資料。

有用的處理順序是：驗證事件、識別出貨、更新狀態、檢查通知資格、選擇獲准渠道、產生範本、將訊息加入隊列，以及記錄結果。如果訊息在隊列中等待，請在發送時重新檢查資格。

6. 測試完整旅程，然後逐步推出

不要只根據測試電郵外觀是否正確來評估工作流程。請測試從出貨事件到客戶目的地的完整路徑，包括失敗情況。

  • 正常旅程：接收、運送中、派送中及已送達會產生預期訊息。
  • 重複事件：重播同一事件不會產生另一則通知。
  • 事件順序錯亂：延遲的運送掃描不會在送達後觸發過時提醒。
  • 拆分訂單：每則訊息都識別正確出貨，不會暗示所有商品均已送達。
  • 欄位缺失：缺少姓名、承運商、估算或商品清單時，會產生易讀的後備文字。
  • 聯絡限制：工作流程遵守渠道偏好、抑制規則及已設定的免打擾時段。
  • 發送失敗：無效地址、供應商錯誤及重試會產生可追蹤結果，不會失控地重複發送。
  • 客戶行動：每個追蹤及支援連結在流動裝置上都能到達預期目的地。

先從有限的出貨群組開始，並將訊息歷史與追蹤歷史一併檢視。讓支援人員可以查看客戶收到的內容。保留暫停控制，讓團隊可以停止錯誤規則，而不必停用出貨追蹤本身。

監察通知資格、發送嘗試、供應商接收、失敗、重複，以及從接收事件到發送訊息之間的延遲。供應商接收並不表示客戶已閱讀訊息，而單靠開啟率也不能證明工作流程有所幫助。

要評估對客戶的影響，請使用一致的定義及可比較的出貨群組，比較與出貨相關的聯絡率。在將變化歸因於通知前，先考慮承運商組合、派送問題及訂單量的變化。

常見問題

標籤建立時是否應發送出貨確認？

你可以發送標籤已建立的更新，但要準確描述。可以表示出貨資料已準備就緒或出貨正在準備中。只有在有相關事件支持時，才使用確認承運商已接收的措辭。

沒有 API 整合，出貨通知是否仍然可行？

可以。基於應用程式的工作流程可能會透過其介面處理連接及通知規則。請核實所選設定中可用的事件、渠道、範本控制及例外處理。當現有系統需要專門路由或決策邏輯時，自訂整合會更合適。

每件出貨應接收多少則通知？

沒有普遍適用的理想數量。請從明確、有用的里程碑及可採取行動的例外開始。抑制重複的運送掃描，只有在訊息提供客戶所需資料時才加入。

追蹤停止更新時應怎樣處理？

應套用適合服務的審查規則，而不是宣佈出貨遺失。檢查最後事件、可用的送達估算及相關營運流程。只有在客戶更新能提供已核實資料或有用下一步時，才發送更新。

已送達通知可以自動關閉支援個案嗎？

送達掃描可以更新個案，但不應自動解決客戶報告的未收到問題。將承運商的送達狀態與客戶問題視為獨立記錄，然後遵循你的調查流程。

來源