WooCommerce 促銷開賣前：庫存、結帳與客服交接要演練甚麼
客人揀咗最後一件特價貨，再輸入優惠碼，結帳金額應該係幾多？落單後，倉庫又點知道可唔可以出貨？開賣前先用一張測試單走一次：核對每件貨嘅折扣、付款結果、庫存變動，同邊位同事負責跟進。
本文是一份開賣前營運演練清單，重點是：用測試站把高風險路徑走一次，留下證據，再決定 Go／No-Go。它不重複隔離 staging的完整設定、更新後功能回歸、排程積壓分流、還原演練或換主機後驗收；本篇只聚焦促銷開賣前的跨團隊演練。
不要把正式站當測試場。 WooCommerce 官方要求測試付款與結帳應在 staging 進行；核心測試訂單沒有特殊狀態，可能觸發訂單電郵、進入分析，外掛或服務也未必分得清測試與正式訂單 [6]。本文不提供「在正式站安全測試」的承諾，也不建議在開賣期間批量改價、批量改券、批量取消訂單或手動改狀態當退款。
一、先填一張開賣核對表
開賣前不要先問「折扣碼設好了嗎」，而是先寫清楚：開賣那一刻，哪些條件必須同時為真？ 這張契約會決定你要測甚麼、誰簽核、何時停手。
| 開賣核對表 | 通過條件 | 證據 | 負責人 |
|---|---|---|---|
| 商品與變體 | 每個要賣的變體都有價格、庫存層級正確、缺貨與缺圖不會誤導 | 變體清單、庫存截圖、前台逐個變體測試 | 商品／營運 |
| 價格與排程 | 促銷價開始與結束時間符合宣傳；結束後回到正確價格 | 產品編輯頁的排程、前台價格、時區 | 商品／網站 |
| 優惠券 | 可疊加或不可疊加、到期日、使用上限、適用商品都符合條款 | 優惠券設定、測試車與訂單總額 | 市場推廣／營運 |
| 結帳與付款 | 訪客與登入用戶都能完成；測試模式不會收真錢 | 測試訂單、付款網關測試紀錄、訂單狀態 | 網站／付款 |
| 通知與訂單 | 訂單電郵、庫存扣減、訂單狀態與客服佇列一致 | 測試電郵、訂單備註、庫存前後對照 | 網站／客服 |
| 客服與出貨 | 誰看哪個佇列、何時截單、例外怎樣升級，都已交接 | 交接表、值班表、回覆範本、升級聯絡 | 客服／倉務 |
這張表不是文件工作。它的作用是：關鍵格填不到證據時，不要用「應該冇問題」開賣；先暫停受影響範圍，補證據或改期。
二、庫存與變體：先分清「哪一層庫存」
WooCommerce 的庫存不是一個開關，而是幾個層級與狀態的組合。促銷前最常見的誤判，是把「有啟用庫存管理」當成「每個變體都有人看守」。
1. 全域庫存管理與商品層級
在 WooCommerce > Settings > Products > Inventory，你可以選擇是否啟用庫存管理。啟用後，WooCommerce 會按銷售與退貨加減數量；停用時，實體商品仍可設定「有貨」、「缺貨」或「允許預訂」，但系統不會保留數量 [1]。
同一頁亦控制 Hold Stock (minutes)：未付款的 Pending payment 訂單會保留庫存，到達時限後訂單會被取消，保留的庫存釋放回可用數量。官方明確指出，這個設定只適用於 Pending payment，不適用於 On hold [1]。促銷時如果客服把大量訂單手動設為 On hold，這些訂單不會按 Hold Stock 自動釋放，庫存會被長時間佔住。
2. 商品層級與變體層級可以混合
可變商品可以選擇在商品層級管理總庫存，或為每個變體獨立管理庫存。官方文件說明，兩者不是二選一：設定為變體層級管理的變體，會由變體庫存扣減；未設定變體層級的變體，則由商品層級庫存供應 [2]。
這代表同一個商品內可能同時存在兩種扣庫存方式。促銷前要逐個變體確認「Manage stock?」與「Stock quantity」，不要只看商品層級的總數。
3. 沒有價格的變體不會顯示
官方文件指出，變體必須有 Regular Price；沒有價格的變體不會在商店顯示 [2]。促銷前若用批量方式改價，漏填價格的變體會直接從前台消失，而不是顯示錯誤價格。這在限時促銷中很容易被誤認為「售罄」。
4. 預訂、缺貨門檻與顯示
變體可以允許預訂；官方文件說明，啟用後庫存可以低於零 [2]。此外，全域設定可控制 Out Of Stock Threshold、缺貨通知、缺貨商品是否從目錄隱藏，以及前台是否顯示庫存數量 [1]。促銷前要決定：缺貨商品是「繼續顯示但標示售罄」，還是「直接隱藏」；兩者對客服查詢與轉化路徑不同。
5. 促銷價排程與批量改價
產品編輯頁的 Sale price 可以設定 From／To 日期；官方文件說明，To 日期是價格停止顯示的日期，在當日 11:59 pm 到期 [3]。這與優惠券的到期規則不同，下文會再說明。
可變商品亦可用 Bulk actions 的「Set sale prices to regular prices decreased by」批量設定促銷價。官方提醒，這個動作會取代現有促銷價；輸入 0 會清除促銷價；沒有 Regular Price 的變體會被跳過 [2]。如果你在開賣前最後一刻批量改價，請先匯出原設定，並在測試站確認每個變體的新價格。
| 庫存／變體測試 | 預期 | 要留的證據 |
|---|---|---|
| 每個要賣的變體 | 有價格、可加入購物車、庫存層級正確 | 變體 ID、價格、庫存、前台截圖 |
| 混合庫存層級 | 變體層級扣變體；其餘扣商品層級 | 下單前後兩個層級的數量 |
| 允許預訂 | 可下單，庫存可低於零，客服知道預計出貨日 | 訂單狀態、庫存負數、客服備註 |
| 缺貨商品 | 按設定顯示售罄或隱藏，不會仍可加入購物車 | 前台商品頁、購物車按鈕狀態 |
| Hold Stock 時限 | Pending payment 到期取消並釋放；On hold 不受此設定影響 | 訂單狀態時間、庫存變化、訂單備註 |
| 促銷價結束 | To 日期 11:59 pm 後回到 Regular Price | 排程前後的前台價格、時區 |
三、優惠券：邊界比折扣更重要
優惠券出事，通常不是「折扣計錯」，而是「不應該用的情況用了」。WooCommerce 核心提供固定購物車、固定商品與百分比折扣；真正要測的是使用限制與使用上限 [4]。
1. 到期日與促銷價的到期規則不同
官方文件明確寫道：優惠券設定了到期日，在該日期當日已不可使用 [4]；而促銷價的 To 日期是 當日 11:59 pm 到期 [3]。這是一個很容易在開賣日造成客訴的差異：
- 如果你希望優惠碼在 11 月 5 日仍可使用，到期日不能直接填 11 月 5 日；按官方規則，當日已經不能用。
- 如果你的宣傳是「11 月 5 日最後一天」，要同時檢查優惠碼與促銷價，不要假設兩者會在同一刻結束。
- 測試時要分別測「到期日當日」與「到期日前一日」，不要只測一個時間點。
2. 使用限制：五個最常漏測的欄位
官方文件列出的使用限制包括 [4]：
- Minimum spend／Maximum spend：以購物車顯示的小計為準；如果商品價格含稅，小計亦含稅。
- Individual use only：勾選後，此優惠券不能與其他優惠券同時使用。
- Exclude sale items：排除已減價商品；但固定購物車折扣仍可能作用於其他合資格、非減價商品。
- Products／Exclude products／Product categories／Exclude categories：限制或排除特定商品與分類。
- Allowed Emails／Email restrictions：按客戶的 billing email 驗證；支援
*@gmail.com這類萬用字元。
3. 使用上限：三個不同的「上限」
官方文件區分三種使用上限 [4]：
- Usage limit per coupon：整張優惠券在所有客戶之間的總使用次數。
- Usage limit per user：每位客戶可使用多少次。
- Limit usage to X items：最多有多少件合資格商品可獲百分比或固定商品折扣；留空代表全部合資格商品。這個設定不限制固定購物車折扣。
促銷前要問清楚：你限制的是「總用量」、「每人用量」還是「每人可折扣的商品件數」？三者可以同時存在，測試時要分別觸發。
4. 疊加：不要假設「一定可以」或「一定不可以」
核心的 Individual use only 可以阻止一張券與其他券同時使用 [4]。但這不代表所有未勾選的券都一定會按你預期的方式疊加；不同外掛、自動套用規則與計算次序都可能改變結果。例如 Smart Coupons 便在優惠券加入「可與哪些券一起使用／不可與哪些券一起使用」的擴充限制 [12]。
因此，與其背誦「核心可否疊加」，不如在測試站建立一個優惠券組合矩陣，逐項確認：
| 優惠券測試 | 要確認 | 常見錯誤 |
|---|---|---|
| 單張券 | 折扣、總額、稅與運費符合條款 | 只測登入用戶，沒有測訪客 |
| 兩張券（可疊加） | 兩張券的先後次序與總額符合預期 | 假設所有券都會疊加 |
| Individual use only | 第二張券被拒絕，訊息清楚 | 只測一張券，沒有測組合 |
| Exclude sale items | 減價商品不被折扣；其他合資格商品仍可按規則獲折扣 | 以為整張券一定失效 |
| Min／Max spend 邊界 | 剛好等於、低於、高於門檻的結果 | 只測遠高於門檻的購物車 |
| 到期日當日 | 按官方規則，當日不可使用 | 把「最後使用日」填成到期日 |
| Usage limit per coupon | 達到總用量後失效 | 沒有預留客服補發或測試用量 |
| Usage limit per user | 同一客戶達到上限後失效；訪客與登入用戶分別測 | 只用一個帳戶測試 |
| Limit usage to X items | 只有指定件數獲折扣；固定購物車折扣不受此限 | 以為所有折扣類型都會被件數限制 |
| Allowed Emails | 合資格與不合資格 email 的結果 | 只測 billing email，沒有測訪客結帳 |
| 自動套用券（如有外掛） | 自動套用與手動輸入的先後次序、可否移除 | 把外掛行為當成核心行為 |
另外兩個容易漏掉的官方細節：優惠券會先作用於商品價格，再計算稅項；運費不會被一般優惠券扣減，除非你使用的是免運費優惠券 [4]。如果促銷條款寫「全單免運」，你要測的是免運費券或運費規則，而不是普通折扣券。
四、沙盒與訪客結帳：測的是「客人看到的路徑」
WooCommerce 核心沒有一個名為「sandbox」的單一開關；沙盒／測試模式通常由付款網關提供。例如 WooPayments 與 Stripe 擴充都有自己的 test mode，讓你可以用測試卡完成結帳，而不收取真錢 [7][8]。你要測的不是「網關有 test mode」這件事，而是訪客由商品頁到訂單確認頁的完整路徑。
1. 訪客結帳的設定與限制
在 WooCommerce > Settings > Accounts and Privacy，可以啟用 Enable guest checkout，允許客戶不建立帳戶就結帳。官方說明，訪客訂單不會綁定 WordPress 使用者帳戶；但訂閱商品仍需要帳戶 [5]。
這代表訪客結帳不是「所有商品都一樣」。如果你的促銷包含訂閱、會員價、下載商品或需要帳戶才能使用的功能，要逐項確認訪客路徑是否仍成立，或是否應引導建立帳戶。
2. 測試訂單不是「隱形」的
官方文件明確指出，WooCommerce 核心的測試訂單沒有視覺差異或特殊狀態；測試訂單可以觸發訂單電郵，也會出現在 WooCommerce 分析。其他擴充、外掛或服務可能無法區分測試與正式訂單 [6]。因此：
- 測試應在 staging 進行；官方明言，為避免測試付款在正式站造成非預期影響，應只在 staging 測試 [6]。
- staging 只隔離網站資料，不會自動隔離 SMTP、外部 webhook、CRM／ERP 或倉務系統。測試前要使用受控測試收件人，停用或指向測試 endpoint，並確認倉務不會收到測試單 [6]。
- 在 staging 完成測試後，按官方建議刪除測試訂單，避免被誤出貨或計入分析 [6]。在正式站發現疑似測試單，不要直接刪除；應隔離該單、對帳交易與倉務，保留審計紀錄。
不同網關的提示不同：WooPayments 的測試訂單會在編輯訂單頁顯示 test mode 提示、加入訂單備註，測試電郵亦有 [Test] 前綴；並可在 WooCommerce > Status > Tools 批量刪除 test mode 的 WooPayments 訂單。這個工具不會刪除其他網關的訂單，也不是正式訂單的清理工具 [7]。核心測試訂單則沒有這個特殊狀態。不要把「某個網關有提示」當成所有網關都有。
3. 訪客結帳測試矩陣
| 測試 | 預期 | 證據 |
|---|---|---|
| 訪客完成測試付款 | 到達訂單確認頁，收到訂單電郵，訂單狀態正確 | 測試訂單 ID、電郵、狀態、付款網關紀錄 |
| 訪客使用優惠券 | 折扣、總額、稅與運費符合條款 | 購物車總額、訂單總額、優惠券使用次數 |
| 訪客選擇不同變體 | 價格、圖片、庫存與購物車內容同步 | 每個變體的前台與訂單截圖 |
| 測試付款失敗 | 訂單狀態合理、庫存按規則處理、客戶看到清楚訊息 | 失敗訂單、訂單備註、庫存前後 |
| 需要帳戶的商品 | 訪客路徑按業務規則被引導或阻止，不會無聲失敗 | 前台提示、帳戶建立流程、訂單狀態 |
| 訂單電郵與客服通知 | 只發一次、內容正確、收件人正確 | 電郵標題、時間、收件人、SMTP 紀錄 |
五、客服與出貨交接：把狀態翻譯成行動
促銷開賣時，客服與倉務看到的不是「WooCommerce 狀態」，而是「我現在應該做甚麼」。交接表要把每個狀態翻譯成行動，而不是只貼一張狀態表。
1. 先分清七個狀態
官方訂單狀態文件把每個狀態連到結帳、付款、出貨、取消或退款流程 [9]。促銷交接最少要分清：
| 狀態 | 業務意思 | 客服／倉務行動 |
|---|---|---|
| Pending payment | 已收到訂單，但付款尚未確認；不要當作已付款 | 不要出貨；按付款方式與網關核對，留意 Hold Stock 時限 |
| On hold | 通常等待付款確認或人手審核；不要當作已付款 | 不要當作已付款；Hold Stock 不適用於 On hold |
| Processing | 通常表示等待出貨；對已擷取付款的網關，付款已確認；使用核心 COD 時，官方說明訂單會先設為 Processing，直至收款 | 先核對付款方式、收款狀態、網關交易與 fulfillment；是否先出貨後收款，只按既定 COD 協議 |
| Completed | 通常表示已完成；使用 COD 時，應先確認收款，才可設為 Completed | 核對 fulfillment、追蹤資料與客服紀錄；不要重複出貨 |
| Cancelled | 訂單被取消；庫存會按設定回復 | 確認是否需退款；狀態變更不等於已退款 |
| Refunded | 通常表示已退款；自動與手動退款不同，手動退款可能未實際退回款項 | 先查現有退款紀錄與付款商交易，避免重複退款 |
| Failed | 付款失敗或未完成 | 不要出貨；聯絡客戶前先看訂單備註與網關訊息 |
三個官方細節很重要：
- Processing 不是出貨證明，也不一定代表已收款。 對已擷取付款的網關，官方 troubleshooting 文件說明 Processing 代表付款成功、等待出貨，且不會自動變成 Completed；出貨後通常需要人手更新，部分擴充可以自動完成 [10]。但使用核心 COD（貨到付款）時，官方 COD 文件說明訂單會先設為 Processing，直至收款，店主要確認收款後才可設為 Completed [14]。所以同一個 Processing 可能代表「已付款待出貨」或「COD 待收款」；交接表要同時記錄付款方式、收款狀態、fulfillment 與追蹤資料，是否放行出貨只按既定 COD 協議。
- Completed 也不是出貨證明。 狀態可能由人手或擴充自動設定；使用 COD 時，官方要求先確認收款才可設為 Completed [14]。要核對 fulfillment、追蹤資料與客服紀錄，不要只憑 Completed 回覆客戶「已出貨」[11]。
- 手動改狀態不是退款。 WooCommerce 退款文件區分自動與手動退款：自動退款經相容網關把款項退回原付款方式；手動退款只會在訂單記錄退款，仍要在付款商後台把錢退回 [15]。Stripe 文件亦提醒，手動把訂單改為 Refunded 或 Cancelled 不會自動退款 [13]。退款前先查現有退款紀錄與交易狀態，避免重複退款；退款後再核對訂單狀態與備註 [9]。
2. 交接表要有五個欄位
促銷前，客服與倉務的交接表最少要有：
- 佇列負責人：誰看 Pending／On hold、誰看 Processing、誰看 Failed／退款。
- 值班時間與截單時間：促銷日最後幾點截單、翌日何時恢復。
- 升級觸發：付款已扣但訂單未轉 Processing、庫存與訂單不符、同一客戶重複下單、出貨延誤。
- 退款與改單權限：誰可以退款、誰可以改地址、誰可以取消；不要把權限分散到所有人。
- 回覆範本：缺貨、優惠券不適用、訪客訂單查詢、出貨延誤、退款進度。
3. 出貨通知要避免重複
WooCommerce 的 fulfillment 功能可以記錄出貨內容與追蹤資料；官方文件說明，建立、更新或取消已完成的 fulfillment 時可選擇通知客戶，更新已完成的 fulfillment 時通知開關預設開啟；draft fulfillment 則不會發送通知 [11]。促銷期間如果客服與倉務各自更新 fulfillment，客戶可能收到多次通知。交接時要指定單一更新者，並在測試站確認通知開關。
六、測試訂單對帳與清理
測試訂單不是「做完測試就按刪除」那麼簡單。你要先證明它沒有污染正式流程，再清理。
1. 測試訂單登記表
每次測試至少記錄：
- 測試訂單 ID、建立時間、測試站網址、付款網關與 test／live 模式；
- 客戶類型（訪客／登入）、使用的變體、優惠券、購物車內容；
- 預期總額與實際總額、稅與運費；
- 下單前後庫存、優惠券使用次數、訂單狀態；
- 是否收到訂單電郵、客服通知、分析紀錄；
- 清理負責人與刪除時間。
2. 對帳要對「外部結果」
測試訂單的狀態只能證明 WooCommerce 內部流程；付款網關的交易、電郵服務的寄送紀錄、庫存數量與分析資料，才是外部結果。對帳時要問：
- 付款網關是 test 還是 live？有沒有真的收費？
- 訂單狀態是否與付款結果一致？
- 庫存是否只扣一次？取消或失敗後有沒有按規則回復？
- 優惠券使用次數是否只加一次？
- 訂單電郵與客服通知是否只發一次？
- 測試訂單有沒有進入正式出貨佇列或分析？
3. 清理與隔離
清理要分 staging 與正式站：
- staging 測試單：官方建議測試後刪除，避免被誤出貨或計入分析 [6]。WooPayments 可在 Status > Tools 批量刪除 test mode 的 WooPayments 訂單；這個工具不會刪除其他網關的訂單 [7]。
- 正式站疑似測試單：不要直接刪除，也不要批量刪除訂單。只隔離該張訂單，核對付款交易、庫存、電郵、倉務與分析，保留訂單備註與審計紀錄；如果已誤發通知或誤扣庫存，按事故處理。
如果測試訂單意外出現在正式佇列：
- 先標記並隔離該單，不要直接出貨；
- 核對付款模式、交易、庫存、電郵、倉務與分析；
- 保留訂單備註、截圖與時間線；不要刪除正式站訂單；
- 如果已誤發通知、誤扣庫存或誤出貨，按事故處理並通知相關負責人。
七、Go／No-Go：關鍵項未確認，暫停受影響範圍
開賣前的 Go／No-Go 不是投票，而是逐項核對證據。先寫清楚促銷範圍：哪些商品、分類、變體、優惠券、地區與客戶群；開始與結束時間以站點時區為準。若團隊用香港時間，先換算，然後在開始前後與結束前後各測一次。促銷價 To 日期 11:59 pm 與優惠券到期日當日不可用的規則不同，兩個邊界都要測。關鍵閘門（付款、超賣、測試單污染、庫存錯扣）沒有證據時，暫停受影響的促銷、變體或優惠券，或延後該部分開賣；非關鍵項可 Hold 並記錄，不必關閉全站。
| 閘門 | Go 的條件 | No-Go／Hold 的訊號 |
|---|---|---|
| 庫存與變體 | 每個變體有價格、庫存層級正確、缺貨與預訂規則已確認 | 有變體沒有價格、庫存層級不明、混合層級未測 |
| 價格與優惠券 | 促銷價排程、優惠券到期日、疊加與使用上限都已實測 | 到期日當日仍假設可用、疊加規則只靠推測 |
| 結帳與付款 | 訪客與登入用戶都能完成測試付款；test／live 模式清楚 | 只在正式站測、測試卡與真卡混用、網關模式不明 |
| 通知與訂單 | 訂單電郵、客服通知、庫存扣減與狀態一致 | 電郵重複、狀態停在 Pending／On hold、庫存未扣 |
| 客服與出貨 | 佇列負責人、截單時間、升級與退款權限已交接 | 沒有人看 Failed、沒有人核對 fulfillment／Completed、退款權限不清 |
| 測試訂單清理 | 測試訂單已對帳、已刪除或隔離，沒有進入正式佇列 | 測試訂單仍在分析、仍可出貨、付款模式不明 |
不是一見 未確認 就關閉全站。涉及付款、超賣、測試單污染、庫存錯扣等關鍵項，暫停受影響的促銷、變體或優惠券；非關鍵項可 Hold 該項，繼續其他已驗證範圍。停手也不是關閉整個結帳、webhook 或全站，更不要用資料庫還原覆蓋正式訂單。
混合購物車排練例子（純算術示例，不是客戶案例）
以下是一個混合購物車示例：同一張 10% 券，購物車內同時有減價貨、正價貨與運費。數字只為說明「預期總額 vs 實際總額」怎樣對，不代表任何商店或 Managed-WP.™ PRO 的價格；亦未計稅。
| 購物車項目 | 設定 | 預期 |
|---|---|---|
| 商品 A × 1 | 促銷價 100（原價 120），屬減價貨品 | 10% 券不適用；以 100 計 |
| 商品 B × 1 | 正價 200，非減價貨品 | 10% 券折扣 20；以 180 計 |
| 運費 | 30，非免運費券 | 不獲折扣；加 30 |
| 合計 | 100 + 180 + 30 | 310 |
| 實際 | 在測試站記錄購物車與訂單總額 | 不等於 310 就查：券是否套用到 A、是否按 300 計算、運費是否被折扣 |
這個例子的關鍵是：券設定為 Exclude sale items，所以只作用於正價商品 B；商品 A 雖在購物車內，但不獲折扣。若實際總額是 300 而不是 310，常見原因是券錯誤套用到 A，或按 300 的整個小計計算。
六步演練：由開賣核對表到 Go／No-Go
- 01 · 開賣核對表列出每項開賣條件
商品、價格、優惠券、結帳、通知、客服與出貨，每一格都要有證據與負責人。
- 02 · 庫存與變體分清商品層級與變體層級
混合庫存、無價格變體、預訂、缺貨門檻與 Hold Stock 要逐個測；促銷價 To 日期 11:59 pm 到期。
- 03 · 優惠券邊界到期日、疊加、使用上限
到期日當日不可用；Individual use only 阻止疊加；總用量、每人用量、件數上限與 allowed emails 要分別測。
- 04 · 沙盒與訪客結帳測客人看到的路徑
核心沒有單一 sandbox 開關；test mode 由付款網關提供。只在 staging 測，不要用正式訂單做測試。
- 05 · 客服與出貨交接把狀態翻譯成行動
Processing 不等於已出貨；Completed 亦不證明已出貨。指定佇列負責人、截單時間、退款權限與升級路徑。
- 06 · 測試訂單對帳與清理先對帳；正式站只隔離，不刪除
核對付款模式、狀態、庫存、優惠券用量、電郵與分析；測試單進入正式佇列時，先標記，不要直接出貨。
GO：六個閘門都有證據。NO-GO：關鍵項未確認時，暫停受影響的促銷、變體或優惠券；非關鍵項可 Hold，不是關閉全站。
下載完整 SVG 流程圖開賣前的凍結窗口
在 Go 之前，建議設定一個簡短的凍結窗口：停止批量改價、批量改券、批量改庫存、安裝或更新外掛、改結帳欄位。凍結不是因為這些操作一定錯，而是因為開賣期間的變更很難與促銷效果分開，也很難即時回滾。
如果真的要在開賣中修正，應先：
- 指定單一變更負責人；
- 保存修改前後的設定與截圖；
- 在測試站先重現；
- 準備回復步驟與通訊範本；
- 避免同時改多個變數。
八、開賣日時間線
以下時間線是實務建議，不是 WooCommerce 功能保證；請按你的開賣時間、時區與團隊規模調整。
- T-1 日：最後演練逐個變體、逐張優惠券、訪客與登入路徑各測一次；保存測試訂單登記表；確認客服與倉務收到交接表。
- T-0：開賣只由指定負責人開啟促銷；第一張正式訂單要由頭到尾核對付款、狀態、庫存、電郵與出貨佇列。
- T+15 分鐘：第一批訊號看庫存是否按預期扣減、優惠券是否被正確套用、有沒有 Failed 或重複訂單、客服有沒有收到同一問題。
- T+1 小時：佇列與容量看 Processing 是否有人處理、Pending／On hold 是否有積壓、出貨截單時間是否仍可行。
- T+4 小時：庫存與例外看熱賣變體是否接近缺貨、預訂商品是否要提前溝通、退款與改單是否按權限處理。
- 收市：對帳與收尾核對訂單、付款、庫存、優惠券用量與客服紀錄；保存異常事件；按排程結束促銷，確認價格與優惠券回復正確。
即時停手訊號
出現以下任何一項，應暫停受影響的促銷、變體或優惠券，停止進一步變更，先對帳；非關鍵項可 Hold 並記錄：
- 同一個變體超賣，或庫存與訂單明顯不符；
- 優惠券疊加超出條款，或同一客戶重複使用；
- 付款已扣但訂單長期停在 Pending／On hold；
- 訪客完成付款但收不到訂單確認；
- 測試訂單進入正式出貨佇列；
- 客服或倉務無法在截單前處理積壓。
停手不是失敗，而是避免把一個小錯誤放大成大量錯誤訂單。
九、常見問題
測試訂單會不會出現在正式訂單列表？
核心 WooCommerce 的測試訂單沒有特殊狀態，看起來與正式訂單相似，也可能觸發電郵與進入分析 [6]。因此測試應在 staging 進行；完成後刪除測試訂單。WooPayments 的測試訂單會有 test mode 提示，並可批量刪除，但其他網關未必相同 [7]。
訪客結帳會不會收不到訂單資料？
訪客訂單仍會收集 email、帳單與送貨資料，只是不綁定 WordPress 使用者帳戶 [5]。但訂閱商品仍需要帳戶；如果你的促銷包含訂閱或會員功能，要另外測試訪客路徑。
優惠券可以和其他優惠券一起用嗎？
核心提供 Individual use only，勾選後該券不能與其他券同時使用 [4]。不同外掛可能加入額外的疊加或排斥規則，例如 Smart Coupons 的「可與哪些券一起使用」設定 [12]。不要假設，直接在測試站建立組合矩陣實測。
優惠券到期日當日還可以用嗎？
按 WooCommerce 官方文件，優惠券在設定的到期日當日已不可使用 [4]；促銷價的 To 日期則是當日 11:59 pm 到期 [3]。兩者規則不同，開賣前要分別測試。
把訂單改成 Cancelled 或 Refunded 就會退款嗎？
不會。手動改狀態不是退款。WooCommerce 退款文件區分自動與手動退款：自動退款經相容網關把款項退回原付款方式；手動退款只記錄訂單，仍要在付款商後台退款 [15]。Stripe 文件亦提醒，手動設為 Refunded 或 Cancelled 不會自動退款 [13]。退款前先查現有退款紀錄，避免重複退款。
開賣中發現超賣，應否批量取消訂單？
不應把批量取消當成第一個反應。先停止促銷或暫停相關變體，保存訂單與庫存證據，按付款、出貨與客服情況逐批處理；批量取消可能同時改變庫存與客戶通知，令對帳更困難。本文不提供批量取消的安全承諾。
資料來源
WooCommerce — Does the Stripe extension modify my order statuses?
WooCommerce — How to stack or combine coupons (Smart Coupons)
開賣前，先把關鍵條件核對清楚
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正準備促銷開賣，需要按實際站點、WooCommerce 版本、付款網關與外掛組合整理演練清單，可先確認支援邊界。
聯絡 Managed-WP.™ PRO若你需要按實際 WooCommerce 促銷流程整理庫存、優惠券、測試訂單與客服交接紀錄，可聯絡 Managed-WP.™ PRO。
編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理。標示為實務建議的內容不是 WooCommerce、付款網關或外掛的功能保證；版本、介面、外掛與供應商行為可能變更，請以實際環境及最新官方文件為準。本文沒有指示在正式站建立測試訂單、批量改價、批量取消或手動退款。