首次回覆時間不是越短越好，而是先讓團隊知道哪些詢問必須優先、哪些可以照營業時間算、哪些不需要硬追 1 小時內。對台灣中小企業最實用的第一版，不是把每一則訊息都壓成同一個時限，而是先分成 3 層客服 SLA：高優先案件、一般詢問、非即時型案件，再把負責人、營業時間與對外承諾一起寫清楚。這樣做，客服速度才會變成可管理的節奏，而不是每個人都一直在救火。
首次回覆時間真正要解決的，不只是快
很多團隊一看到訊息回慢，就直覺想把目標改成「1 小時內全部回完」。問題是，若沒有先分清楚案件優先級，這個目標通常只會把內部搞得更亂。高價值詢問、客訴、訂單異常、售後急件，本來就不該和一般表單、合作提案、例行詢問用同一條線排隊。
Zendesk 在 2026 年更新的 first reply time 指南把重點講得很直白：first reply time 衡量的是團隊回應客戶請求的速度，而且應該搭配實際可用時段與服務品質一起看，不要只追表面速度。它也提醒，速度不該以犧牲回答品質為代價。Zendesk
對台灣 SME 來說，這代表首次回覆時間真正要解的是三件事：第一，客戶不要等到失去耐心；第二，團隊知道誰先接哪一類詢問；第三，對外說的回覆承諾能和實際排班對得起來。如果這三件事沒有一起成立，再漂亮的平均值都只是數字。
等待時間、首次回覆時間與解決時間不要混在一起
很多 SME 會把「客戶等多久」「第一次有人回多久」「整件事解決多久」混成同一件事，結果報表看起來都像客服慢，卻不知道慢在哪一段。這是第一次設 SLA 最常見的誤區。
| 指標 | 在看什麼 | 最適合回答的問題 | 常見誤判 |
|---|---|---|---|
| 等待時間 | 客戶從發出第一則訊息到有人接手的時間 | 客戶有沒有被放著不理 | 把等待時間誤當成專員效率 |
| 首次回覆時間 | 從案件建立或被指派到第一次正式回覆 | 客服團隊有沒有在承諾時間內回應 | 把自動回覆或已讀當成人工回覆 |
| 解決時間 | 從案件開始到結案的總時間 | 整體處理流程順不順 | 把複雜案件和簡單問題放在同一個目標 |
Zendesk Help 進一步把 first reply time 的邊界定義得很清楚：一般情況是從 ticket 建立開始，到第一則公開回覆為止；而且 first reply time 與 SLA first reply time 雖然都用到 first reply 這個概念，實際行為仍可能不同。尤其在 business hours、進階設定或 ticket 建立方式不同時，結果會不一樣。Zendesk Help
漸強實驗室的 CAAC 幫助中心也用繁中把這些指標拆開：等待時間是從聯絡人第一則訊息到專員第一次回覆；首次回覆時間則是從對話被指派到任一專員回覆第一則訊息；解決時間再另外計算。這個拆法對台灣常見的 LINE 或對話型客服特別有幫助，因為你可以知道問題是卡在沒人接、指派太慢，還是處理流程太長。Crescendo Lab
台灣 SME 最實用的 3 層客服 SLA
如果你的人力不多，第一版不要直接設一條全通道統一 SLA。先分成三層，通常就能讓現場運作穩很多。
| 層級 | 典型案件 | 建議首次回覆時間 | 誰負責 |
|---|---|---|---|
| 高優先 | 付款失敗、訂單異常、到店前改期、負評客訴、既有客戶緊急問題 | 營業時間內 1 小時 | 值班客服、店長或主責窗口 |
| 一般詢問 | 商品問題、報價詢問、預約諮詢、合作表單、售前比較 | 營業時間內 4 小時 | 客服或業務輪值 |
| 非即時型 | 履歷投遞、媒體邀約、一般合作信、非急件售後文件補件 | 1 個工作天內 | 指定部門 owner |
這種分法的價值在於，它先承認每一則訊息的商業風險不同。你若把客訴、預約改期和一般合作詢問都塞進同一個 1 小時目標，最後通常是高風險案件也沒被處理得更好，只是整隊都處在過載狀態。
HubSpot 的 SLA 設定文件也給了很直接的啟發：time to first reply 可以依 ticket priority 來套不同的 due soon 與 overdue 規則，而且 SLA 也能只在 operation hours 內計算。這說明 first reply 本來就不該只有一種時限，而是應該依案件重要性和團隊可用時段去設。HubSpot Knowledge Base
營業時間算法，比 24/7 承諾更重要
很多 SME 最容易踩雷的，不是 SLA 設太慢，而是對外講得像 24 小時隨時有人，內部卻根本不是這樣運作。只要你沒有夜班、假日值班或外包客服，首次回覆時間就不該把深夜和休假時間硬算進去。
Zendesk 的 first reply time 指南直接用一個例子說明：如果客戶週五下午送出請求，而你的團隊週一上午才上班，那不該把整個週末都算進 first reply time。這就是 business hours 衡量的重要性。Zendesk
HubSpot 也寫得很明確：SLA 可以設成只在團隊 operation hours 內生效，也可以設成 24/7，但兩者不該混用。對台灣 SME 來說，這代表一開始更穩的做法通常是先用營業時間 SLA，再把官網、LINE 歡迎訊息、表單自動回覆和 FAQ 寫清楚，讓客戶知道真正的人工時段。HubSpot Knowledge Base
哪些詢問不該硬套同一個回覆時限
第一次設 SLA 最怕的是用一個平均值掩蓋掉完全不同的商業場景。以下幾種詢問，最不適合硬套同一條首次回覆時間。
第一種是高情緒或高風險案件，例如客訴、退款爭議、履約異常、價格糾紛。這些案件不只要求快，還要求回覆的人有權限、有上下文，甚至要能做補償或升級判斷。第二種是明顯帶成交機會的高意圖詢問，例如已經附需求、預算、時程的報價表單，或明確要預約的詢問。這類案件應該優先於一般資訊型提問。
第三種則是非即時型案件，例如一般合作、媒體採訪、履歷或文件補件。這些若也硬塞進 1 小時目標，不只浪費現場注意力，還會讓真正該快的案件被埋掉。比較好的方式，是先把分流規則寫成客服或表單欄位，讓團隊在案件進來的第一分鐘，就已經先做一次優先級判斷。
內部 SLA 和對客承諾，不要說成同一件事
很多團隊會把內部追蹤用的 SLA 和對客戶公開承諾的回覆時間講成一樣，結果不是講太滿，就是內部根本做不到。這兩者最好分開。
HubSpot 在 SLA glossary 裡提醒，成功的組織通常會同時有 internal SLAs 和 external customer contracts。internal SLA 處理的是部門間的交接、優先級、負責人與回覆節奏；external promise 處理的則是客戶實際會感受到的服務期待。HubSpot
對台灣 SME 來說，實務上可以這樣拆：內部規定高優先詢問 30 分鐘內一定完成指派，客服 1 小時內回第一句人工回覆；對外則寫「營業時間內通常 1 小時內回覆急件，一般詢問 4 小時內回覆」。這樣既保留了內部壓力管理，也不會把自己公開綁死在做不到的承諾上。
7 天把首次回覆時間變成可執行 SOP
第 1 天，先拉出最近 50 筆詢問，分成客訴、售前、售後、合作、其他五類。第 2 天，標記哪些其實應該優先，哪些不需要即時回。第 3 天，先定 3 層客服 SLA，不要超過三種。第 4 天，把營業時間、值班人與代理規則寫清楚。第 5 天，補上自動回覆、FAQ 或表單確認訊息，避免客戶在非營業時間完全沒有資訊。第 6 天，把 due soon 和 overdue 條件接進共用看板、CRM 或客服工具。第 7 天，只檢查三個問題：高優先案件有沒有真的被提前處理、一般詢問有沒有拖過頭、以及哪一類案件其實應該再拆細。
這套 SOP 的重點不是把報表做漂亮，而是先讓現場真的知道怎麼分流。只要分流有用，後面你要再接 AI 摘要、工單路由、FAQ 建議或客服知識庫，才不會把原本的混亂自動化。
資料更新與來源
本文最後查核時間為 2026 年 7 月 12 日。首次回覆時間的定義、business hours 邏輯與 median / SLA 觀念，優先參考 Zendesk 2026 年更新的 first reply time 指南與 Zendesk Help。priority-based SLA、operation hours 與 ticket property 的設定，優先參考 HubSpot Knowledge Base。對話型客服的等待時間、首次回覆時間與解決時間差異，參考 Crescendo Lab 的繁中說明。
- Zendesk: First reply time
- Zendesk Help: Understanding ticket reply time
- HubSpot Knowledge Base: Set SLAs in the inbox
- HubSpot: Service Level Agreement glossary
- Crescendo Lab Help Center: 對話、效率、團隊
本文提供的是台灣 SME 的客服與營運流程建議，不是法律、合約或產業強制標準。若你屬於醫療、金融、政府標案、24/7 維運或有正式違約罰則的 SLA 場景，仍應再依實際合約、值班制度與法規要求調整。
結論
首次回覆時間真正有用的設計，不是把每一則訊息都逼進同一條秒數，而是先把高優先、一般詢問與非即時案件分清楚，再用營業時間、負責人與對外承諾把節奏寫出來。對台灣 SME 來說，只要先把這 3 層客服 SLA 做穩，客服回覆速度就會從「每一則都在救火」變成「知道現在該先救哪一則」。
FAQ
首次回覆時間一定要追到 1 小時內嗎？
不一定。若你把所有詢問都壓成 1 小時內，小團隊通常只會一直救火。比較實用的做法是先分高優先、一般詢問與非即時案件，再為每一層設不同時限。
自動回覆可以算進首次回覆時間嗎？
多數官方說明會把自動回覆和人工首次回覆分開看。自動回覆可以先告知營業時間與下一步，但不要把它當成真正完成人工承接。
客服 SLA 要用營業時間還是 24/7？
若你的團隊沒有夜班或假日值班，通常先用營業時間計算比較合理，再把官網、LINE 與表單上的可回覆時段說清楚。
首次回覆時間和解決時間可以用同一個目標嗎？
不建議。首次回覆時間看的是有沒有人先接住客戶，解決時間看的是整體處理流程；兩者混在一起，通常只會讓報表看起來全都慢。
如果現在只有 LINE、Email 和表單，沒有正式工單系統，也能做客服 SLA 嗎？
可以。第一版先用共用試算表、共用信箱或 CRM 欄位，把詢問類型、優先級、首次回覆時點與 owner 記下來，就已經能先把流程穩住。