排隊管理策略
來電一多、座席不夠接，客戶就得排隊。排隊管理要解的，就是這段等候期間怎麼讓客戶不難受、佇列又跑得有效率——這件事做得好不好，很大程度決定了客服中心的服務水準。
排隊演算法
FIFO（First In, First Out）
最基本的排隊原則：先到先服務。
| 特性 | 說明 |
|---|---|
| 公平性 | 最高——嚴格依等候時間排序 |
| 實作複雜度 | 最低 |
| 適用場景 | 客戶等級無差異的通用佇列 |
| 缺點 | 無法區分緊急程度與客戶價值 |
優先級排隊（Priority Queue）
為不同類型的來電設定優先等級，高優先級來電插入佇列前方。
優先級設定維度：
| 維度 | 範例 | 典型優先級 |
|---|---|---|
| 客戶等級 | VIP/白金/一般 | VIP 最高 |
| 通話類型 | 緊急掛失/一般查詢 | 緊急最高 |
| 來源渠道 | 付費專線/免費專線 | 付費較高 |
| 等候時間 | 已等候超過門檻 | 動態提升 |
| 業務價值 | 高價值續約/一般諮詢 | 高價值較高 |
純靜態優先級有個陷阱：低優先級的客戶可能永遠排不到（Starvation）。解法是加「時間衰減」——低優先級客戶的有效優先級會隨等候時間慢慢往上升，確保他最後總會被服務到。
技能匹配排隊（Skill-Based Queue）
來電依據所需技能進入對應佇列，僅分配給具備該技能的座席。
來電 A（需英語+帳務技能） → 英語帳務佇列 → 等待匹配座席
來電 B（需中文+技術技能） → 中文技術佇列 → 等待匹配座席多佇列歸屬： 一通來電可同時存在於多個佇列中（主技能佇列 + 次要技能佇列），由先空閒的合格座席接聽。
| 策略 | 說明 |
|---|---|
| 主技能優先 | 優先由主技能座席接聽 |
| 等候時間優先 | 超過門檻後，次要技能座席也可接聽 |
| 技能鬆綁（Skill Relaxation） | 隨等候時間延長，逐步放寬技能要求 |
預估等候時間（EWT）
計算方法
| 方法 | 原理 | 準確度 |
|---|---|---|
| 平均值法 | EWT = 最近 N 通的平均等候時間 | 低，受極端值影響 |
| 位置法 | EWT = 佇列位置 x 平均服務間隔 | 中，假設穩定到達率 |
| 模擬法 | 基於即時參數的排隊論模型 | 高，計算較複雜 |
| 歷史同期法 | 參照同時段歷史 EWT | 中高，需足夠歷史數據 |
| 混合法 | 即時數據 + 歷史數據加權 | 最高 |
位置法計算範例
佇列中第 5 位
目前可用座席 = 0，通話中座席 = 10
平均通話時長 = 5 分鐘，已通話平均經過 = 2.5 分鐘
預估下次空閒 = 2.5 分鐘
平均服務間隔 = 5 / 10 = 0.5 分鐘
EWT = 2.5 + (5-1) x 0.5 = 4.5 分鐘回呼機制（Callback）
回呼類型
| 類型 | 觸發方式 | 說明 |
|---|---|---|
| IVR 回呼 | 客戶在 IVR 中選擇 | 等候期間主動請求 |
| 網頁回呼 | 客戶在網站填寫表單 | 預約指定時段回撥 |
| 溢位回呼 | 系統自動觸發 | 佇列過長時自動提供 |
| 排程回呼 | 座席/系統安排 | 指定日期時間回撥 |
回呼優先級處理
回呼請求進入系統後的優先級策略：
| 策略 | 說明 |
|---|---|
| 保持原位 | 回呼在排到原始佇列位置時觸發 |
| 立即優先 | 有座席空閒時優先處理回呼 |
| 時間窗口 | 在客戶指定的時間窗口內回撥 |
| 混合佇列 | 回呼與即時來電按比例混合（如 7:3） |
回呼失敗處理
第一次回撥 → 未接聽 → 等待 5 分鐘
第二次回撥 → 未接聽 → 等待 15 分鐘
第三次回撥 → 未接聽 → 發送 SMS 通知，附回撥號碼
↓
24 小時內未回撥 → 關閉回呼請求，記錄處置碼排隊溢位策略
溢位層級設計
| 等候條件 | 溢位動作 | 說明 |
|---|---|---|
| 等候 30 秒 | 播放 EWT | 告知預估時間 |
| 等候 60 秒 | 提供回呼選項 | 改由回呼機制處理 |
| 等候 120 秒 | 溢位至次要技能群組 | 放寬技能匹配 |
| 等候 180 秒 | 溢位至通用群組/外包 | 跨組分配 |
| 等候 300 秒 | 轉語音信箱 | 最終安全網 |
時間型溢位 vs 條件型溢位
| 類型 | 觸發條件 | 特點 |
|---|---|---|
| 時間型 | 固定等候秒數 | 簡單，但不夠靈活 |
| 條件型 | EWT/佇列深度/SLA | 動態，更精確 |
| 混合型 | 時間 + 條件 | 最佳實踐 |
溢位策略最好設計成多層串接（Cascade），每一層都有明確的觸發條件和去處。而最後一層一定要有安全網——語音信箱或強制回呼，別讓客戶無限期地等下去。
排隊音樂與公告設計
排隊音樂（Music on Hold）
| 設計原則 | 說明 |
|---|---|
| 節奏適中 | 避免過於激昂或過於沉悶 |
| 音量一致 | 與語音公告音量保持一致 |
| 授權音樂 | 使用已取得公播授權的音樂 |
| 定期更換 | 建議每季更換，避免常客感到厭倦 |
| 無歌詞 | 有歌詞的音樂可能讓客戶分心或引起不適 |
排隊公告設計
| 公告類型 | 內容範例 | 播放時機 |
|---|---|---|
| 歡迎公告 | 「感謝您的來電，我們將盡快為您服務」 | 進入佇列時 |
| EWT 更新 | 「您目前排在第 3 位」 | 每 60-90 秒 |
| 自助引導 | 「查詢帳單可至官網 My Account」 | 等候 30 秒後 |
| 回呼提示 | 「如需系統回撥，請按 1」 | 等候 60 秒後 |
| 致歉公告 | 「目前來電量較大，感謝您的耐心等候」 | 等候 120 秒後 |
| 營運資訊 | 「提醒您，本月帳單繳費期限為...」 | 穿插於等候中 |
公告排程邏輯
0 秒 → 歡迎公告
15 秒 → 音樂
60 秒 → EWT 更新 + 回呼選項
75 秒 → 音樂
120 秒 → 自助服務引導
135 秒 → 音樂
180 秒 → 致歉 + EWT 更新
195 秒 → 音樂 + 營運資訊
（循環）這裡有個心理學上的巧妙處：研究發現，等候期間有資訊更新的客戶，主觀感覺的等候時間會比實際短 20-30%。所以適當穿插 EWT 更新和有用的資訊（而不是放整段純音樂），能明顯壓低放棄率。
排隊監控指標
即時監控儀表板應包含以下關鍵指標：
| 指標 | 說明 | 告警門檻（參考） |
|---|---|---|
| 當前佇列深度 | 各佇列等候人數 | > 座席數 x 2 |
| 最長等候時間 | 佇列中等最久的一通 | > 180 秒 |
| 即時 SLA | 當前 N 分鐘的服務水準 | < 70% |
| 放棄率 | 即時放棄率 | > 8% |
| 可用座席數 | 各技能可用座席 | = 0（無座席可用） |
| EWT | 預估等候時間 | > 300 秒 |
排隊管理不只是技術問題，更是一種客戶體驗設計。從演算法上的公平與效率拿捏，到等候期間的資訊傳遞和心理感受，每個環節都在左右客戶對這次服務的整體印象。好的排隊策略，能讓等候變成「可以接受的等待」，而不是「被遺忘的煎熬」。