客服回應時限把關流

🎯 這條流程解決什麼

服務承諾（SLA）最弔詭的地方在於，它平常很安靜，安靜到大家都忘了它存在，直到某張工單默默拖過時限、客戶忍不住寫信抱怨「你們三天都沒回我」，問題才浮上檯面。而這時候通常已經太遲——客戶的耐心耗完了，挽回的成本遠高於當初準時回覆。

純靠人力盯 SLA，現實上很難做到。客服一天面對幾十張工單，有的緊急、有的普通、有的還在等客戶回覆，每張的時限起算點與長度都不一樣。要靠承辦人自己心算「這張還剩多久」幾乎不可能，主管想全面掌握更是難上加難，往往只能等到客訴升級、或月底拉報表時才發現某段時間達標率掉得很慘，卻已經無從補救。

更隱性的成本是「不知道自己在漏」。沒有監控機制時，超時的工單不會主動跳出來喊救命，它就靜靜躺在某個角落過期。一個月累積下來，可能有一兩成的工單其實都破了時限，團隊卻渾然不覺，直到客戶用腳投票、續約率下滑才察覺。這條工作流的價值，就是把這個「沉默的破口」變成「會說話的監工」：快超時先催承辦、真超時就往上報主管，並把達標率變成每天看得到的數字。

🛡 安全提醒：升級通知只在內部團隊頻道流動，勿把工單原文外送；提醒節奏要避免疲勞轟炸，建議同一工單設冷卻時間，免得通知洗版反被忽略。

適合誰：有明確回應時限承諾、想避免客訴升級的客服與技術支援團隊。

導入後的改變

導入前，SLA 是一個「事後才知道」的指標。團隊憑印象覺得「我們回得算快」，但拿不出數字，也不知道哪些工單正在邊緣徘徊。一旦客戶投訴超時，往往是已經發生、無法挽回的事實，主管只能道歉加補償。

導入後，SLA 變成「事前就攔得住」的機制。系統每十五分鐘巡一次所有未結案工單，把快超時的提前推到承辦人面前——這時候工單還沒破時限，承辦人有機會在客戶察覺前先回覆。真的超時的，立刻紅字升級給主管，主管能即時介入而不是月底才知道。

效益相當直接。以一個十人客服團隊、每天約兩百張活躍工單來估，導入前若有一成五的工單在某些時段默默超時、其中部分演變成客訴，導入後因為「快超時就催」這道提前量，多數工單在破線前就被處理掉，實際超時率往往能壓到原本的三分之一以下。客訴升級的件數隨之下降，主管也從「被動救火」轉為「主動補位」，每天靠一份自動產出的達標率報表就能掌握全局，週會檢討有憑有據，不再是各說各話。

流程怎麼運作

第一步「觸發：定時輪詢」，由排程每十五分鐘啟動一次。系統透過工單系統 API 抓出所有「未結案」的工單，以及每張工單對應的回應時限設定。十五分鐘的頻率是個平衡點：夠即時，又不會把工單系統的 API 打爆。

第二步「計算剩餘時間」，這是流程的計算核心。每張工單依其優先級套用不同的 SLA——例如緊急案件可能是一小時內首次回應、一般案件四小時、低優先八小時。系統用「時限起算點＋SLA 時長」算出到期時刻，再減去現在時間，得出每張工單還剩多久，或已經超時多久。這裡要注意工作時間的計算：如果你的 SLA 只算上班時段，就得排除非營業時間，否則半夜的計時會誤判。

第三步「快超時 → 提醒承辦」，當某張工單的剩餘時間低於設定門檻（例如剩不到三十分鐘），系統就私訊提醒該工單的負責人，附上工單連結與主旨，讓他能立刻點進去處理。這是「催」，目的是趕在破線前救回來。

第四步「已超時 → 升級主管」，當工單真的超過時限，系統自動通知主管、在工單上標紅，並附上一段摘要（誰的工單、超時多久、客戶在問什麼）。主管看到就能決定是親自接手、重新指派、還是補一通電話安撫客戶。

第五步「回寫達標率」，每天結束時，系統把當日的超時筆數、各優先級的達標率寫進試算表報表，累積成趨勢。週會時打開報表，哪個時段容易塞車、哪類工單最常超時，一目了然，改善才有依據。

需要的工具與串接重點

平台用 n8n 或 Make。工單系統 API 是資料來源，無論你用 Zendesk、Freshdesk、HelpScout 還是自建系統，重點是能撈出未結案工單清單與各自的時間欄位；串接時務必確認 API 有回傳「建立時間」「最後客戶回覆時間」「優先級」這幾個關鍵欄位，否則算不出正確的剩餘時間。

排程負責每十五分鐘觸發；條件判斷節點負責分流「快超時」與「已超時」兩條路；**通知（Slack／Line）**負責把訊息推到對的人——承辦人收提醒、主管收升級，兩條通知路徑要分開，避免主管被一般提醒洗版；試算表負責累積每日達標率。

串接重點：第一，務必設「同一工單的提醒冷卻時間」，例如同一張工單三十分鐘內只提醒一次，否則每輪輪詢都重發，承辦人很快就會把通知靜音，整套機制就失效了。第二，工作時間計算要對齊你真正的 SLA 定義。第三，升級通知只走內部頻道，工單原文不外送。想把這套監控延伸成更完整的客服自動化體系，可以參考站上的 automation 自動化專區 與其他 workflows 工作流範本。

常見錯誤與注意事項

第一個常見錯誤是「提醒太吵反被無視」。如果每輪輪詢都對同一張快超時工單重發提醒，承辦人一小時收四次同樣的訊息，很快就會麻木甚至關掉通知，這套機制等於白做。一定要設冷卻時間，讓提醒精準而不洗版。

第二，SLA 時間計算別忽略營業時段與時區。如果你的服務承諾只算上班時間，卻用自然時間計時，週末和半夜的工單會被誤判成嚴重超時，升級通知一早就爆炸，反而失去可信度。

第三，升級門檻與通知對象要設計清楚。並非所有超時都該驚動最高主管，建議分層：小幅超時先給組長，連續或大幅超時才往上升。否則主管被太多升級淹沒，真正嚴重的反而被埋掉。

第四，這套流程監控的是「回應時間」這個客觀指標，但它不評斷回應的品質好壞。準時回了一句沒幫助的罐頭話術，數字上達標、客戶卻更氣。SLA 監控要搭配品質抽查一起看，回覆內容的妥適性仍需人工把關，數字達標不等於服務做好。第五，工單資料含客戶個資，所有處理與通知都留在內部系統與團隊頻道，不外流到無合約的第三方。

台灣中小企業情境案例

新竹一家提供 POS 系統的軟體公司，客服承諾「上班時間兩小時內首次回應」，但團隊只有四個人，常常一忙起來就有工單被晾在一旁。某次一家餐廳客戶的收銀機在用餐尖峰當機，工單卻拖了大半天才有人回，客戶氣得在群組公開抱怨，差點影響其他潛在客戶。

導入這條流程後，系統每十五分鐘巡一次，工單剩不到三十分鐘就到時限時，承辦人會收到 Line 提醒；真的超時則直接升級給客服主管。主管每天早上打開試算表就能看到前一天的達標率與哪些工單超時，週會時拿著趨勢圖檢討排班——原來每天午休前後是塞車高峰，於是調整了值班人力。

兩個月後，這家公司的首次回應達標率從約八成三拉到九成六，公開抱怨的情況沒再發生，幾家原本猶豫的客戶也順利續了約。主管說最大的改變不是數字，而是「終於不是等客戶罵了才知道出事」。

延伸應用

這條流程的核心是「監控時間、分級提醒、累積數據」，這個模式能套到很多地方。把監控對象從「首次回應時間」換成「結案時間」，就能盯住那些一直開著沒收尾的長尾工單。加上客戶優先級權重，VIP 客戶的工單可以套更嚴格的時限與更早的提醒，銜接 VIP 關懷流程。

也可以把累積的達標率資料接進更完整的客服儀表板，搭配工單量、滿意度分數一起看，找出「量大、超時、滿意度低」三者交集的問題時段，對症下藥。對技術支援團隊，同一套結構可以延伸去監控「待客戶回覆超過 N 天自動提醒」的場景，避免工單卡在客戶端被遺忘。想找更多能直接組裝進流程的單一動作模板，可以逛逛 recipes 食譜庫。

流程圖

用到的工具

更多「企業職能」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →