WooCommerce 訂單通知設定：LINE、Email 與簡訊

顧客詢問付款或出貨進度時，先區分訂單狀態未更新、訊息沒送達，以及內容不清楚。這篇以 WooCommerce Email、LINE Messaging API 與簡訊說明多管道通知，目的是降低漏接與重複通知，沒有任何組合能保證零漏接。

WooCommerce 店在做訂單流程優化時，常會卡在「怎麼讓顧客即時看到訂單狀態」。LINE 推播與簡訊可以補足電子郵件，但觸達率仍受好友關係、使用者識別、門號與服務狀態影響。這篇要談的，就是怎麼設計多管道通知並降低漏接風險。

Email、LINE 與簡訊沒有固定的主從關係，應依顧客同意、客群使用習慣、重要性與成本分工。Email 可保留完整訂單資訊，LINE 適合已完成帳號綁定的即時通知，簡訊則用於少數緊急情境。舊教學使用的 LINE Notify 已在 2025 年 3 月 31 日終止，不能再採用。

三分鐘重點：訂單通知三層架構

• 底層（保險）：原生 Email。保留完整訂單資訊並監控送達；Email 也可能退信或進垃圾信，不是永遠不會消失的備份。
• 中層（視需求）：LINE 推播。走 LINE 官方帳號＋Messaging API，給顧客即時看，在顧客同意且完成身分對應後使用。LINE Notify 已終止，需遷移。
• 頂層（精準出擊）：簡訊。依事件急迫性、顧客偏好與成本評估，不按客單價一律發送。

為什麼光靠 Email，你的訂單通知常常「傳到了等於沒傳到」

換個方式想。你自己上次打開一封「來自某商店」的 Email 是什麼時候？多半是你主動在找一張收據、或等一個啟用碼的時候。商店寄來的訂單通知、出貨通知、付款提醒，對消費者來說優先級很低，很容易被促銷信、工作信、垃圾信一起淹掉。

行銷郵件基準可作背景參考，但不能直接代表交易信件，也不能用點擊率推論信件是否送達（見 HubSpot 的 Email 行銷基準，2025 年）。應分開監控退信、延遲、開信或點擊，以及顧客是否完成付款或查詢訂單。

WooCommerce 有廣大的使用與外掛生態（依 W3Techs 的市佔統計，2026 年 6 月）。這項全球統計不能推算台灣有多少商店，也不能證明所有商店都遇到相同 Email 問題。

若你的顧客願意加 LINE 官方帳號並完成會員識別綁定，LINE 可作為即時通知管道。沒有自家顧客資料前，不應預設 LINE 一定比 Email 更有效，也不應為了通知強迫顧客加入行銷名單。

而漏接一張訂單通知的代價，遠比你想的高。顧客沒即時收到付款失敗的提醒，那張單就躺在那裡爛掉，你損失的是一筆已經上門的生意；顧客沒收到出貨通知，就會打來問、打來催，吃掉你客服的時間；更糟的是他覺得「這家店連通知都做不好」，下次就不來了。換句話說，通知系統表面上是技術設定，骨子裡是顧客留存與客服成本的戰場。把這件事做對，省下來的不只是幾封信，而是回購率與口碑。

先把 WooCommerce 的「訂單狀態機」看清楚再動手

很多人裝通知外掛的第一個錯，是不知道 WooCommerce 本來就有一套訂單狀態機。你不必記每一個英文狀態名，但你必須知道「哪個狀態會觸發原生 Email」，因為這決定了你要不要額外推 LINE、要不要發簡訊。否則你會把同一個訊息推三次，顧客反而覺得被疲勞轟炸。

這張表是實務上常用的判斷基準：

原生 Email 觸發不代表顧客已閱讀。通知規則應依付款方式與店家流程挑選關鍵事件；若「Completed」不等於實際出貨，就不要拿它當出貨通知，應使用物流外掛提供的出貨或到店事件。

如果你還沒摸熟訂單流程全貌，結帳表單本身也值得一併檢討，因為通知的起點往往是結帳那一刻。可以搭配這篇 WooCommerce 結帳表單客製化教學 一起看，把「顧客填單」到「收到第一封通知」這段體驗整條順起來。

不同金流的漏接點不一樣，通知時機要跟著調

很多人以為「訂單成立就推一封通知」萬事解決。但不同的付款方式，顧客的焦慮點完全不同，你推的時機與內容也要跟著變。最容易踩的雷是這個：店主把同一套通知邏輯套在所有金流上，結果該即時的沒即時、該等的卻催太早。

通知應對應實際事件。信用卡可能先授權後請款，ATM 與超商代碼則通常先產生繳費資料、再確認付款；訊息須說清楚目前是哪一步。貨到付款的收款與到店狀態另行確認，不能一律用 Processing 判斷錢已收到。

同一事件不要重複推送，但付款指示、確認入帳與實際出貨是不同資訊，可以依顧客需要分開通知。重點是內容、觸發條件與去重規則，不是把每張訂單固定限制為兩封。

金流這塊如果你想往深裡走，串接綠界這類本土金物流的完整設定，可以搭配 RY WooCommerce Tools 相關的設定一起看，那會講到怎麼把「付款回呼」這個訊號源接到你的通知規則裡。

LINE 推播的三條路，以及為什麼舊教學裡的 LINE Notify 已經死了

LINE 已在 2025 年 3 月 31 日終止 LINE Notify，相關 API 自 4 月 1 日起不可用，官方建議改用 Messaging API（見 LINE Developers News 的終止公告）。建立在 LINE Notify token 上的流程都必須遷移。

LINE Notify 終止後，舊 token 不能繼續提供服務。是否出現錯誤提示取決於外掛如何處理回應，因此不能只看後台開關仍啟用就判定正常；應實際查看 API 回應及通知紀錄。

LINE Notify 退場之後，你真正能走的是這三條路：

1. 路線 A：LINE 官方帳號＋Messaging API。申請 LINE 官方帳號並開啟 Messaging API，再用 push message 傳送訂單訊息。系統必須先取得 LINE user ID，並安全地對應到 WooCommerce 顧客或訂單；只有加好友而沒有身分綁定，仍不知道該把哪張訂單推給誰。若使用 LINE 登入 協助綁定，也要取得明確同意並提供解除方式。
2. 路線 B：Webhook＋自動化工具串接。用 WooCommerce webhook 觸發訂單事件，必要時再透過 REST API 補查訂單資料，交由 Make、n8n 這類自動化平台呼叫 LINE Messaging API 發訊息。彈性最大，能做複雜條件（例如只有高單價才推、只有週末才推），但設定門檻高，適合有技術底子或委外的團隊。
3. 路線 C：使用第三方外掛。選擇明確支援 LINE Messaging API 的 WooCommerce 通知外掛，依文件設定 Channel Access Token、收件對象與事件條件。不同外掛支援的簡訊商、訂單狀態、身分綁定與收費方式不同，安裝前應查看目前版本與官方相容說明；外掛安裝方式可參考WordPress 外掛安裝教學。

這三條路不是互斥方案：自動化工具與外掛也可以使用同一套官方帳號和 Messaging API。比較時看身分綁定、事件去重、失敗重試、權限和維護成本；不必把自行開發當成經營會員的唯一方法。

走 Messaging API 之前，先搞懂這幾個觀念

不管你自己串 API 還是用外掛，有四個觀念會決定推播能不能穩定運作。很多人卡住，原因往往出在根本不知道有這些限制存在，跟設定難不難沒有關係。

• push 跟 reply 是兩件事。reply message 使用 webhook 事件的 reply token 回覆，官方文件指出 reply 不計入方案訊息數；push message 是主動傳送，會受月訊息額度與方案限制。訂單通知多半使用 push。
• 要同時滿足傳送條件與身分對應。push 通常可傳給已加官方帳號為好友的使用者，或符合官方列出的特定互動條件者。LINE 登入只會提供授權後的識別，並不自動完成加好友或訂單綁定；結帳流程要清楚告知用途並保存對應關係。
• 訊息有格式、額度與政策限制。Flex 與 template message 要符合欄位和尺寸規格，但 LINE Messaging API 並沒有「一般促銷模板一律先送審」的通則。發送失敗時要查 API 回應、使用者關係與月額度。
• token 是鑰匙，要當密碼保管。Channel Access Token 一旦外洩，等於別人可以用你的官方帳號發訊息。把它跟網站的 SSL、密碼一起當機密處理，定期輪換，並且只在 HTTPS 環境下傳輸。關於傳輸安全，可以回頭看 SSL 憑證 為什麼是電商站的底線。

裝好外掛、填入 token 仍不代表能傳送。至少要測試使用者是否符合 push 條件、LINE user ID 是否正確綁定訂單、Token 權限、訊息額度與 API 回應，並記錄失敗原因。

該推進 LINE 的訂單狀態，以及其他先別急著推的

把付款與物流關鍵事件推進 LINE，可能減少查單詢問，但效果要用客服分類、通知送達與自助查詢率驗證，不能預設導入後一定大幅下降。

所以這份清單是這樣分的：

優先評估的通知事件

• 新訂單成立（給店主與出貨端）。這條訊息不是給顧客的，是給你自己與出貨同事的。需先確認官方帳號可加入目標群組、取得正確群組 ID，並只讓有權限的成員收到必要資料。
• 付款成功轉為處理中（給顧客）。顧客最焦慮的瞬間是「我到底付了沒」。訊息應和已確認的金流結果一致，實際客服變化再由商店資料驗證。
• 實際出貨（給顧客）。用物流外掛的出貨事件與追蹤連結，不要只把 WooCommerce Completed 狀態當作出貨證明。
• 付款失敗（給顧客）。提供安全的重新付款入口與客服方式；發送時機依金流回報速度與重試流程設定。

先別急著推的狀態

• 待付款。除非你的金流會卡很久（例如 ATM 轉帳待確認），否則顧客剛結完帳又收到一封「你還沒付款」，反而像在催債。
• 已取消。若取消會影響付款或履約，應清楚告知；是否另推 LINE 取決於既有通知與顧客偏好。
• 每一個微狀態都推。推太多，顧客會把官方帳號靜音，之後再重要的訊息也推不動了。這跟 EDM 行銷 的發信頻率是同一個道理：寧可少推，也不要讓人封鎖。

判斷標準很簡單：這則訊息「晚一小時知道」會不會造成顧客的損失或你的麻煩？會，就推；不會，就讓它留在 Email 裡當備份。通知不是愈多愈好，是愈準愈好。

這個判斷沒有絕對標準，會跟你的產業與客單價連動。低價或高價訂單都不能單靠客單價決定通知管道。先核對顧客偏好、LINE 綁定與實際送達，再看是否有必要以簡訊補位。先用你自己的店當尺，把客單價、退貨率、客服量這三個數字擺在一起看，你就會知道哪些訂單值得花那一封簡訊的錢，哪些讓 LINE 處理就好。

簡訊通知：什麼時候才值得花錢發那一封

簡訊是要花錢的，每發一封都計費。所以問題不是「能不能發」，而是「這張訂單值不值得發」。通常會把簡訊保留給以下幾種情境，其餘訂單可依 Email、已同意且完成綁定的 LINE 與實際送達情況安排。

發送時機與內容技巧，是一門獨立的學問，不要在這裡亂試。建議直接讀過 簡訊行銷實戰指南，把發送時段、字數限制、文案寫法一次搞懂，再回來接訂單通知，才不會把錢花在效果差的簡訊上。

三竹與 Every8D 等服務可提供簡訊介接，但不能據此推論它們都內建 WooCommerce 外掛。以三竹為例，HTTP API 需依供應商流程開通；選購通知工具前核對支援商、驗證方式、發送限制與計費，不是輸入原有帳號就一定可用。

簡訊發送的三個眉角

簡訊看似簡單，但發出去跟發到顧客「真的看到」，中間有幾個細節會決定成效。這幾個眉角都是實務上容易忽略的細節：

• 字數取決於編碼與供應商。GSM-7 單則常見上限為 160 字元，Unicode 常見為 70 字元；串接多則後每段可用長度會下降，台灣供應商的計價與拆分方式仍以其文件為準。
• 依急迫性與偏好安排發送時段。付款異常等即時訊息與一般提醒可採不同規則，非緊急通知可設安靜時段；沒有商店數據不能斷言中午一定更有效。
• 短連結要用可信的。若需要縮短訂單查詢網址，優先使用自有網域或簡訊服務商提供的官方短址，並先測試跳轉與 HTTPS；來路不明的短網址可能讓顧客擔心詐騙。相關設定原則可參考短網址指南。

這幾個眉角跟簡訊行銷的整體策略是同一套。如果你發現自己對「怎麼把簡訊發到精準」這件事有興趣，建議把簡訊行銷的完整框架整篇讀過一次，會得到一個更通用的發送策略，而不只是套用在訂單通知這一個場景。

通知模板要中文化，別讓顧客收到英文系統信

依顧客語言提供清楚的通知，並實際檢查外掛的中文翻譯與自訂模板。不能只憑英文文字就推論特定年齡層一定看不懂或判為詐騙；店名、訂單識別、事件與可信查詢入口都應易於辨識。

通知模板應依顧客選用的語言寫得清楚、易辨識；面向繁體中文客群時，再將對應模板改成自然的繁體中文。改的重點不是翻譯，是「口語化」：把「Order status updated」改成「你的訂單已經開始處理囉」，把「Payment failed」改成「付款好像沒成功，點這裡重新付款」。語氣對了，顧客才會覺得這是「一個真人開的店」在跟他講話，像收到一封私訊，而不會有冷冰冰的系統廣播感。

如果你的模板藏在主題或外掛的語系檔裡、後台找不到改的地方，那就需要動到翻譯檔。這時 Loco Translate 這類工具就派上用場了，可以參考 Loco Translate 教學，直接在 WordPress 後台把外掛的字串改成你要的中文，不用碰程式碼。這一步做完，你的通知才算真正「在地化」，而不只是裝了個會發訊息的外掛。

LINE、簡訊與 Email 工具的比較方式

底下是常用來比較的幾類工具。不點名特定付費外掛的品牌（這類外掛更換很快，品牌推薦一年後多半就過時），而是給你一個比較框架，讓你自己拿當下能找到的工具來套。

不必每家店都同時上三層。可先用 Email 與訂單頁建立可驗證的基本通知，再依顧客綁定率、客服需求與訂單風險加入 LINE 或簡訊。多管道能降低單點失效，但沒有任何設計能保證「零漏接」。

Email 有主機或交易郵件服務成本；LINE 官方帳號方案與免費額度會隨地區及時期調整；簡訊通常按則計費。上線前先按實際訂單量試算，並避免同一事件被多個外掛重複觸發。

還有一個觀念要扭轉。很多人把通知外掛當「一次性設定」，裝好就放著不管。但你的金流會新增、品項會擴充、促銷活動會變，每一個變動都可能讓原本的通知邏輯不再適用。建議每季做一次通知體檢：拿最近一個月的真實訂單，回頭看每一張的訊息有沒有照預期推出去、顧客有沒有按時收到、有沒有哪一類訂單開始漏推。檢查需安排人力與必要服務成本，有助發現漏發或重複發送，但不能保證提前攔下所有問題。

通知文案是微型 CTA，寫壞了等於白推

很多人把通知系統接好之後就放著，從來不檢查文案。但你仔細想，一則訂單通知本質上就是一個行動呼籲：你要顧客去查物流、去補付款、去確認收貨。文案寫得不清楚，推播再即時也沒用。

寫通知文案時，把它當成一個微型 CTA 來設計。一則好的訂單通知應該在三秒內讓人知道三件事：發生什麼事、我要做什麼、點哪裡去做。這跟 CTA 行動呼籲按鈕設計 的核心是同一套邏輯，只是縮小成一行字。

幾個常會檢查的點：訂單編號要放最前面（讓顧客回報時抓得到）、動作連結要獨立一顆按鈕（不要埋在整段文字裡）、語氣要像人講話（不要「親愛的顧客您好，系統已為您更新訂單狀態為已完成」這種機器人腔）。如果你寫文案會卡，可以回頭參考電子報行銷裡的文案結構，把同樣的開頭、重點、行動三段式搬過來用。

行銷報告可作為分眾構想，不能直接推論交易通知效果。訂單信先提供履約必要資訊；若加上優惠等行銷內容，應另確認顧客偏好、同意與退出方式，並量測實際反應。

五個降低通知漏接的檢查項目

通知系統最怕的不是沒裝，是裝了卻「看起來在動、其實沒推出去」。底下這五個是導入時一定要檢查的防呆項目：

1. 保留可追溯的基本通知。通常可保留原生 Email 與訂單頁，但 Email 也有寄送成本、退信與垃圾信風險，必須監控並測試。
2. 用一張真實測試單走完整流程。不要只看後台狀態跑對了，要真的用自己的手機下單、付款、看訊息有沒有真的進來。很多設定錯誤只在真實訂單才會暴露。
3. 注意 LINE 的額度與 API 限制。監控月訊息額度、速率限制、格式錯誤與 API 回應；一般 Messaging API 模板應依格式和政策驗證；不要混用其他產品的送審流程。
4. 簡訊字數要控管。超過單則長度可能拆為多段，段數與計費依編碼及供應商規則。把物流單號、連結都算進去，控制在單則字數內。
5. 備份規則，保護憑證。通知模板與條件規則可依網站備份流程保存；Channel Access Token 應由受控的秘密儲存方式管理，備份若含 token，也須加密、限制存取並定期檢查。養成可復原且不外洩的備份習慣，可以參考 UpdraftPlus 備份教學 的做法，讓你的通知設定不會在換主機或出意外時整個消失。

上線驗收應留下每條管道的觸發、API 回應與實際接收紀錄，並安排失敗告警和人工查詢。測試訊息與維護可能有成本，也不能用一次成功保證之後都會送達。

訊息推不出去？照這個順序排查

出現「外掛啟用但訊息未收到」時，依序確認事件、身分對應、權限、額度與外連紀錄，再進行相容性排查：

1. 先查訂單狀態到底對不對。很多時候不是通知壞了，是訂單卡在「保留中」沒轉成「處理中」，自然不會觸發你綁的那個狀態。先在後台確認訂單狀態，再懷疑外掛。
2. 再查 token 跟額度。到 LINE 官方帳號後台看 Messaging API 的訊息額度是不是用完了、token 是否有效、已撤銷或到期；不同類型 token 的有效期限不同。簡訊則查供應商後台的餘額是不是歸零。
3. 接著查 webhook、排程與網路紀錄。確認訂單狀態事件是否觸發、Action Scheduler 是否積壓、外連 API 是否被防火牆阻擋，以及 LINE 回應碼。頁面快取通常不會直接攔截後台 hook，不要把它列為無證據的主要原因。
4. 查外掛衝突。先在隔離測試站備份並逐一停用可能相關的外掛，用相同事件重測；不要在正式收單時一次關閉全部訂單工具。恢復正常只能縮小範圍，還需重現才能確認衝突。

API 接受請求不等於顧客已閱讀；LINE 也可能在收件人封鎖等情況下回傳成功但不送達。請保留請求識別、回應及可用的統計資料，無法確定時以安全的訂單查詢與客服流程補足。

把點擊追蹤接起來，才知道通知到底有沒有用

通知推出去之後，下一個問題是：有效嗎？顧客有點嗎？有回購嗎？如果你不量測，就永遠在憑感覺調設定，調錯了也不知道。

可在通知連結加入 UTM 或自家短網址識別來源，使用者抵達網站後再由分析工具記錄。GTM 無法直接量到 LINE App 或簡訊客戶端內部的點擊，只能記錄落地頁載入或由短連結服務回報的轉址。站內 LINE 按鈕的追蹤可參考 GTM 追蹤 LINE 按鈕點擊，但兩種情境不完全相同。

以相同定義比較出貨通知與促銷訊息的點擊和落地行為，並注意樣本、收件對象與追蹤限制。沒有自家數據不能斷言出貨通知一定較高；未點擊也可能是訊息已提供足夠資訊。

追蹤接好之後，實務上會固定看三個指標來判斷通知系統健不健康：

• 通知點擊率。出貨通知的點擊率如果長期偏低，可檢查文案、連結、追蹤與是否需要點擊，不能直接認定文案有問題。
• 客服「查訂單」類來訊量。按訂單量與問題類型比較趨勢；沒有下降也可能受訂單成長或物流變化影響。
• 通知後的回購比例。收過出貨通知的顧客，多久後會再下第二單？可觀察關聯，但需考慮客群差異，不能直接視為通知帶來的增量效果。

若顧客同意接收行銷，可另外測試 回購優惠券等方案。出貨不等於已收貨，更不能推論顧客當下心情最好或轉換率必然更高；先把訂單資訊清楚送達，再評估優惠是否適合這個接觸點。

訂單查詢與物流追蹤頁通常包含個資與交易資訊，應要求授權或使用不可猜測的安全連結，並避免被搜尋引擎索引。Google 沒有為一般私密訂單頁提供可提升搜尋顯示的 Order 複合式搜尋結果；不要為了 SEO 在這類頁面加入訂單 Schema。

順帶一提，通知系統穩不穩，跟網站本身的體質有關。如果你的 WooCommerce 站連基本 SEO 都還沒打底，通知外掛再強也只是把一個沒人來的店的通知做得很好而已。打底的事，可以先從 WordPress 架站與 SEO 優化全攻略 開始，把流量與轉換的基礎一起顧起來。

收尾行動方案：三步先把通知系統跑起來

如果你看到這裡，別想著一次把所有管道都接好。那是讓自己卡住最快的方式。建議照下面三步走，每一步都先跑出一個能動的最小版本，再慢慢疊。

1. 第一步：把原生 Email 先做到位。確認核心的付款後、訂單完成與付款失敗等適用 Email；實際出貨通知則檢查物流外掛或自訂事件是否有另行設定、文案看得懂、範本長得像你家的品牌。先核對核心與物流外掛各自的觸發事件及發信成本。檢查的時候，連「寄件人名稱」都要順手改成你的店名，別讓顧客收到一封來自「WordPress」或亂碼主機的信，並搭配網域驗證與寄送紀錄；寄件名稱本身不決定是否進垃圾匣。
2. 第二步：接上一條 LINE 推播。申請 LINE 官方帳號、開 Messaging API、挑一個通知外掛綁起來。先完成顧客同意與 LINE user ID 的安全對應，再挑實際物流出貨事件測試一種通知，觀察送達及顧客回饋，再決定要不要加推其他狀態。千萬不要再回頭用 LINE Notify，那條路已經斷了。這一步也順便把好友累積機制設好，取得顧客同意並完成 LINE user ID 與訂單的安全對應。
3. 第三步：在貴單訂單加上簡訊。挑出你店裡單價最高、或貨到付款比例最高的那批訂單，只對這批發簡訊。算一下簡訊成本佔這些訂單利潤的比例，合理才擴大。如果你的店貨到付款佔比很高，應比較通知成本、未取件率與樣本差異，不保證簡訊會降低退件。

三步走完，你會有一個分層、有備援、可量測的訂單通知系統。它不是最炫的，並可用實際送達、查詢與客服資料持續調整，降低顧客找不到進度的風險。

再提醒一件容易被忘記的事：通知系統不是蓋好就不用管的。你的店會成長、品項會變、顧客結構會移動。每過一陣子，回頭看看你的通知有沒有跟著店一起長大。一個會跟著生意一起演化的通知系統，才是真正能替你省下客服人力、守住顧客信任的長期資產。

我們 Whoops SEO 做的就是這類把 WooCommerce 細節一個一個磨對的工作。如果你正在架店、或店已經跑起來但訂單流程卡卡的，歡迎找我們聊聊，把通知系統當成一個起點，順著把結帳、金物流、SEO 一起順起來。卡關時再來談也行，決定權在你手上。