蝦皮聊聊要多快回？客服 SLA、人力排班與優先級設計

蝦皮聊聊不需要所有訊息都在同一分鐘回覆。先把會影響付款、退款、出貨時限與客戶權益的案件排到前面，再用每日訊息量、平均處理分鐘、尖峰係數、服務時段與可用人力，設定自己能長期守住的 SLA。平台最低要求只能當合規底線，不能直接當成公司的最佳客服標準。

截至 2026-09-06，蝦皮幫助中心目前說明「聊聊表現」是賣家回應買家聊聊的頻率，也就是賣場顯示的聊聊回應率；但本次可確認的官方頁面沒有提供可安全沿用的統一回覆時數、計分門檻或所有訊息是否納入的完整公式。因此這篇文章不寫死平台數字，實際使用前仍須在賣家中心及最新官方文件確認。

五類訊息先分流

這是賣家內部範例，不是蝦皮官方 SLA。P0、P1 先看客戶權益與剩餘處理時間；售前訊息雖可能影響轉換，也不能插隊到讓退款、取消或出貨案件逾時。

首次回覆與結案時間要分開。首次回覆是確認已受理並告知下一步；結案時間是問題真正解決。只回「收到」卻沒有責任人與預計處理點，不算完成。

用六個數字估算客服容量

先蒐集同一服務時段的：

• 訊息量：需要人工處理的對話數，不是訊息泡泡數。
• 平均處理分鐘：閱讀、查訂單、回覆與紀錄的總時間。
• 尖峰係數：尖峰時段工作量 ÷ 平均時段工作量。
• 可用人力：實際能處理聊聊的人數。
• 服務時段：每人每天排入客服的分鐘數。
• 有效負荷率：扣除休息、交接、查證與例外後可用比例。

尖峰工作量分鐘 = 對話數 × 平均處理分鐘 × 尖峰係數

每人有效容量 = 每人服務分鐘 × 有效負荷率

所需人數 = 向上取整（尖峰工作量分鐘 ÷ 每人有效容量）

以下是假設案例：一天有 180 個需人工處理的對話，每件平均 4 分鐘，尖峰係數 1.5；每人服務 480 分鐘，有效負荷率先保守抓 70%。

尖峰工作量 = 180 × 4 × 1.5 = 1,080 分鐘

每人有效容量 = 480 × 70% = 336 分鐘

所需人數 = 向上取整（1,080 ÷ 336）= 4 人

70% 是假設，不是通用標準。若同一人還要出貨、接電話或處理退款，要把那些不可用分鐘扣掉。活動日、晚間與發薪日的來訊分布也可能不同，不能只用全日平均掩蓋尖峰。

預估等待時間怎麼看

簡化的即時估算可以是：

預估等待分鐘 = 前方待處理工作分鐘 ÷ 目前可用客服人數

前方有 90 分鐘工作、目前 3 人能處理，粗估等待約 30 分鐘。這個公式假設案件難度相近，遇到複雜退款、系統延遲或人員同時離線會失真，因此要每 15 ~ 30 分鐘重算，並把 P0、P1 另開優先佇列。

當預估等待會超過內部 SLA 時，不要用無意義罐頭話術灌回應率。可以啟動備援人力、暫停非必要工作、延後一般詢問，或在允許的功能內提供清楚的服務時段與預期回覆；任何自動回覆都不能假裝案件已解決。

排班要看時段，不只看日總量

把最近 28 天的對話依星期與半小時切開，排除一次性大促後計算 P80 或 P90 需求。新品、活動與物流異常另加標記。資料不足時先人工排一位值班與一位備援，不要用兩天高峰推算全年編制。

每班至少定義：

1. 主責人與備援人。
2. P0、P1 升級方式。
3. 交班時未結案件清單。
4. 可以承諾與要請主管批准的事項。
5. 回覆品質抽查比例與錯誤修正方式。

退款金額、法律承諾、例外補償與高風險個資處理應由授權人批准。客服可先蒐集證據與提出建議，不能為趕 SLA 越權答應。

30 天驗證 SLA 是否合理

每週看四個數字：各優先級首次回覆達標率、結案時間、重開案件率、每件處理分鐘。速度變快但重開率與負評上升，代表回覆品質被犧牲；達標率低但人員閒置，可能是分流或交班設計錯誤。

SLA 應降載或重設的條件包括：連續兩週尖峰需求高於有效容量 20%、P0／P1 逾時、錯誤承諾增加，或客服加班已成常態。要把工作正式移交，可銜接 蝦皮店 SOP 與授權門檻；退款平台流程則由 安心退賣家 SOP 負責。

我以前曾用自動貼圖和改回未讀處理聊聊率，但那是很久以前的平台環境，現在不建議照做，當時提過的「12 小時」也不能當成現行規則。

可以先從這一步開始： 匯出或人工記錄最近 14 天每半小時的新對話數與處理分鐘，先把 P0／P1 分流，再以 P80 尖峰建立一週排班。守不住時先調整範圍與人力，不要用虛假回覆製造漂亮數字。

延伸資料

聊聊規則查核到 2026-09-06。官方公開頁面沒有完整列出統一回覆期限和計分公式，因此排班前仍要再看一次賣家中心。