促銷前客服如何備戰？用活動變更表預排人力與問答

以活動變更表整理優惠、庫存、客服窗口與常見問答，並用透明的假設算例估算來訊尖峰、安排值守與異常決策。

促銷上線前，客服面對的往往不是一道優惠問答，而是折扣條件、庫存、出貨與活動時間同時變動。若只把活動頁轉給第一線，遇到贈品已送完、折扣不能併用或結帳金額不同，客服仍得臨場找人判讀。可以先用一頁活動變更表串起三件事：哪些內容變了、由誰確認、顧客會怎麼問；再把預估來訊拆到時段，安排值守和異常決策。本文的數字只是示範算法，實際排班應採用團隊自己的活動紀錄與處理速度。未確認的條件先列為待確認，不能在顧客對話中自行補成承諾。表格不必另造厚重制度，重點是活動負責人、客服與供貨或出貨窗口看的是同一組已確認條件，並知道遇到例外時由誰裁定。

活動哪些變更影響客服

先把活動視為營運變更，而不只是改一段促銷文案。表格記下活動名稱、起訖時間、適用商品與入口，並列原條件和活動期間的新條件。顧客若在活動前加入購物車、活動開始後才付款，客服便能依表判斷採用的時點，不必看著截圖猜測。

逐項核對會改變顧客決定或訂單處理的內容：折扣門檻、優惠碼併用、贈品數量、免運規則、適用地區、出貨預估、缺貨處理及取消方式。不是每項都會改；未改項目仍要由窗口確認。待定項目記下負責人和預計回覆時間，避免客服把空格解讀成沒有例外。

每個變更還要連到顧客會在哪裡看見它，以及客服下一步怎麼做。若折扣只限指定組合，標明適用商品、結帳時的判斷方式和不符合資格時的說法；若出貨地區有別，寫明要先取得哪項資料、再交給誰確認。把「規則有改」拆成具體差異，客服才不用自行推理。

建議一列記一件事，欄位用「項目、舊值、新值、生效時點、顧客影響、確認窗口、客服答覆、未決事項」。例如贈品改為送完為止，還須確認庫存由誰更新、頁面何時提醒、已成立訂單遇到贈品用罄時怎麼處理。把下一個決定者列出來，比只留「請洽內部」更可執行。

上線前由活動負責人與客服逐列走讀，對照活動頁、結帳說明與客服用語。用一筆活動前成立、一筆活動中成立的假設訂單，檢查折扣與贈品如何處理。若仍有空缺，標出暫不承諾、補答窗口與回覆時間。這張表的目的，是讓跨部門在同一頁準備，不是把內部討論整段轉給顧客。

優惠條件由誰核准

每項條件都要指定核准人，但不必讓所有人重看全文。活動負責人確認目的、時段與顧客承諾；定價或商品窗口核對折扣和適用範圍；庫存、出貨窗口確認數量與配送說法；客服檢查顧客能否照答覆完成下一步。各人確認不同事實，不能用一人看過文案代替全部核對。

核准人依變更類型決定：門檻或折扣碼併用由能決定價格的人確認；贈品與到貨安排由掌握庫存和出貨的人確認；開始、結束或延長活動由活動負責人確認。客服可以指出條件矛盾、說明顧客會怎麼理解，但不能自行增加折扣、承諾補償或推估交貨日期。

表格列出每個負責人的職務或姓名、確認欄位、聯絡方式和最晚回覆時間，並把問題問到可明確回答的程度。例如不要只寫「麻煩確認優惠」，而要問「滿額折抵是否限指定品項、能否與會員券併用」。若回覆只涵蓋品項，併用規則仍標為待確認，不因部分核准就推定全部成立。

活動負責人統整確認結果後，客服用符合資格與不符合資格的假設訂單走一遍：頁面怎麼呈現、顧客要提供什麼、例外交給誰。任何說明若與結帳條件不一致，先回到能改設定或確認規則的窗口；客服照已確認內容回覆，並告知顧客查核時間，不讓第一線承擔商業決定。

若上線後有人要求更改條件，先由有決策權的人確認是否採用，再指定誰同步活動頁、結帳設定與客服說法，標明新條件何時生效。變更尚未完成時，客服沿用已確認且適用的條件，對新情況採查核回覆。這是活動運作所需的分工，不是額外建立文件版本核准制度。

預估問題如何盤點

盤點問答從顧客旅程寫起：活動前看不看得懂資格、結帳時優惠有沒有套用、付款後如何查訂單、收到商品後遇到贈品或配送差異怎麼處理。每個問題用顧客會說的句子描述，再對回變更表中的條件；只複製活動標題，往往答不到顧客卡住的步驟。

以折扣活動為例，列出「這件商品算不算」、「兩個優惠能不能一起用」、「忘記輸入碼是否能補」、「訂單拆開後門檻怎麼算」等具體問法。再依庫存和物流變動補上「贈品是否還有」、「這個地區能不能寄」、「出貨時間是否改變」。只納入本次活動可能碰到的情境，不需把客服所有問題都塞在一份清單裡。

每題答案要指出依據與下一步，而非只寫一句口號。例：先請顧客提供訂單編號並確認商品，再按已確認的適用清單判斷；若訂單狀態或贈品數量無法從現有資訊確認，就轉給相應窗口，說明何時回覆。對客服而言，清楚的查核路徑比猜一個快速答案更有用。

盤點來源可先看過往相似活動的來訊分類、客服交接中反覆出現的疑問，以及活動頁上容易誤讀的條件；若沒有可用紀錄，標註這是本次預想情境，不把猜測寫成顧客常見事實。按影響和處理難度排優先，折扣錯用、付款結果不明或缺貨處理，要先備好升級窗口。

走讀時由一人扮顧客，照著活動頁提出問題；客服只能看表作答，再檢查是否還要追問資料、是否可直接處理、何時升級。凡是答案出現「應該」、「可能」或彼此矛盾，就把缺少的條件交給負責人確認。最後把常用的幾題放在值班入口，並讓當班人員都能找到完整清單。

來訊尖峰怎麼估算

排班看每小時來訊，不只看活動總量；平均分布可能遮住開場或通知後的短時尖峰。優先找相似活動逐時記錄，並用當班人數與完成量估算團隊每人每小時可處理量。沒有可比資料，就列低、中、高假設並標明是估值，活動中再修正，不當成通用標準。

以下是假設算例：四小時預估160則，前兩小時100則、後兩小時60則；暫以每人每小時10則作排班假設，前段需求為100÷（2×10）＝5人，後段為60÷（2×10）＝3人。這只算直接承接來訊的人數，尚未包含休息、複雜案件與臨時缺勤的緩衝。

再用班表核對高峰。若同時要查複雜訂單或回多個入口，依團隊紀錄估算占用，另指定可調度備援處理休息和升級。若缺少尖峰所需人力，可分批開放、延後通知或準備可直接答覆的資訊，並由活動負責人決定是否調整曝光。

活動當天定時查看新進量、待處理量和最久等待時間，對照假設；若隊列連續累積或複雜案件增加，先叫備援、重新分派簡單問題，再回報負責人。不要只看平均回覆速度，也不要為追數字略過查核。觀察結果要轉成下一時段的人力調整。

收班記下超估時段、跨部門查詢占用與交接情況，分辨來訊超量、答案不足或排班錯位。若無歷史數據，保留假設、觀察時段和修正原因，供下一次相似活動使用，不把單次猜測變成固定比例。

異常時誰決定暫停

活動開始前就要說清楚誰能決定暫停、縮小適用範圍或恢復活動，以及客服遇到什麼情況要立即升級。活動負責人通常掌握是否繼續的決定；商品、結帳、庫存或出貨窗口則確認各自負責的狀態。客服可以停止使用有疑慮的說法並回報，不能自行改優惠或對所有顧客承諾補救。

把觸發條件寫成可辨認的事件，例如結帳折抵與已核准條件不符、頁面顯示的贈品資訊和可用數量衝突、顧客無法完成付款，或某個配送安排已不能照原說明處理。條件要指出回報對象、先收集哪些資訊，以及等待決定時可以怎麼答；不要只寫「有狀況就通知主管」。

客服回報時整理發生時間、顧客看到的畫面、適用商品或訂單狀態，以及目前已確認的事實。只蒐集判斷問題所需的內容，再依表交給負責窗口；若不同顧客遇到相同情況，補上發生筆數與入口，讓決策者判斷影響範圍。回覆顧客時先承認正在核查，說明下一次更新時間，不先猜原因或結果。

等待決策時使用事先確認的暫行答覆，必要時先停止推薦有疑慮的優惠說法，並把未決案例集中交接。若決策者確認只是單一訂單問題，就依個案路徑處理；若發現設定或庫存影響一批訂單，則由有權者決定是否暫停活動或更改條件，同時安排誰更新對外資訊和客服答案。

恢復前再確認造成異常的條件已修正、適用範圍清楚，並由負責人通知客服採用的新說法及生效時間。若仍未能確認，就維持查核回覆和升級路徑，不因訊息減少便推定問題消失。把決策人、備援聯絡方式和恢復條件放在變更表可見處，當班人員才找得到。

活動後如何回收問題

活動結束後，先將來訊依優惠資格、折扣未套用、庫存贈品、配送、取消及付款等情境分類，另外記下哪些問題需要跨部門查詢。統計時按相同時段對照原先估量與實際隊列，並標記活動入口或條件變化；不要只留一個總數，否則難以看出人力是在哪個環節不足。

接著挑出反覆發生或花費查核時間較長的問題，追到原因：活動條件寫得不清楚、頁面與結帳顯示不同、庫存資訊來得太晚，還是客服找不到負責窗口。用具體案例描述「顧客看見什麼、客服怎麼查、最後由誰確認」，不要只記成「大家常問優惠」。若證據不足，保留為待觀察，不把單一個案說成普遍現象。

回看排班假設時，比較各時段預估與實際來訊、直接處理量和等待隊列。尖峰估低就檢查通知時間或活動入口；人力看似足夠卻仍累積，則查看答案是否缺漏、查詢是否等待其他部門。由此決定下次要調整的是人數、時段、問答內容或升級方式，不把所有問題都用加人解決。

把結論轉成下一次活動可使用的動作：補上已確認的答覆、安排負責窗口提早回覆庫存、重新估算某時段人力，或請活動負責人調整顧客可見說明。每項動作寫下負責角色和完成時點，再由客服走讀更新後的情境。未採用的建議也記下原因，免得下次從同一個未決點重新開始。

最後把本次假設、來訊分布、異常決定和待改事項放回團隊活動紀錄，讓下一次能比較相似情境，而不是照搬本次數字。下一步先把這次活動的日期、優惠條件、庫存窗口與假設來訊量填進同一張表，再與相關負責人逐列確認；如需進一步了解 ReplyBot，請前往 ReplyBot 官網。