First Response Time và Resolution Time: Phân biệt hai chỉ số SLA dễ bị nhầm lẫn

17 giờ trước

9 phút đọc

Một báo cáo IT Helpdesk có thể cho thấy phần lớn ticket đều “đạt SLA”, nhưng người dùng vẫn cảm thấy sự cố mất quá lâu mới được giải quyết. Một nguyên nhân phổ biến là doanh nghiệp đang nhìn vào First Response Time trong khi vấn đề thực sự nằm ở Resolution Time.

Hai chỉ số đều liên quan đến thời gian xử lý ticket nhưng đo hai giai đoạn khác nhau. First Response Time cho biết mất bao lâu từ khi ticket được ghi nhận đến khi người dùng nhận được phản hồi đầu tiên hợp lệ từ đội hỗ trợ. Resolution Time đo khoảng thời gian từ khi ticket được ghi nhận đến khi vấn đề được giải quyết theo quy tắc đã thống nhất.

Nói ngắn gọn:

First Response Time trả lời: “Bao lâu thì có người phản hồi?”
Resolution Time trả lời: “Bao lâu thì vấn đề được giải quyết?”

Một Helpdesk có thể phản hồi trong 10 phút nhưng cần 5 giờ để xử lý sự cố. Vì vậy, chỉ nhìn vào tốc độ phản hồi chưa đủ để đánh giá chất lượng hỗ trợ.

First Response Time và Resolution Time khác nhau ở đâu?

Sự khác biệt quan trọng nhất nằm ở điểm kết thúc của phép đo.

Tiêu chí	First Response Time	Resolution Time
Đo điều gì?	Tốc độ phản hồi ban đầu	Thời gian hoàn tất xử lý
Điểm bắt đầu	Khi ticket được ghi nhận theo quy tắc SLA	Khi ticket được ghi nhận theo quy tắc SLA
Điểm kết thúc	Phản hồi đầu tiên hợp lệ của đội hỗ trợ	Ticket đạt trạng thái được xem là đã giải quyết
Phản ánh	Khả năng tiếp nhận và phản ứng	Khả năng xử lý vấn đề
Rủi ro khi đọc sai	Phản hồi nhanh có thể bị hiểu thành xử lý nhanh	Pause, reopen hoặc lịch SLA không rõ có thể làm sai cách diễn giải

Cách phân biệt này cũng xuất hiện trực tiếp trong các nền tảng IT Service Management. Jira Service Management, chẳng hạn, sử dụng riêng Time to first response và Time to resolution trong cơ chế SLA; Atlassian đồng thời cho phép thiết lập điều kiện để đồng hồ SLA bắt đầu, tạm dừng hoặc kết thúc.

Freshservice cũng tách Average First Response Time và Average Resolution Time thành hai KPI riêng trong Benchmark Report 2025. Điều này cho thấy về mặt vận hành, tốc độ phản hồi và tốc độ giải quyết cần được theo dõi độc lập thay vì gộp thành một khái niệm chung.

Hai số liệu này thường chỉ là một phần trong cấu trúc SLA IT Helpdesk. Vì vậy, khi đọc hợp đồng hoặc báo cáo SLA, doanh nghiệp không nên chỉ hỏi “mục tiêu là bao nhiêu phút?”, mà cần hỏi thêm đồng hồ SLA bắt đầu lúc nào, dừng lúc nào và những khoảng thời gian nào được loại trừ.

SLA IT Helpdesk: Nền tảng cho Uptime 99.9% và vận hành không gián đoạn

First Response Time được tính như thế nào?

Ở mức cơ bản:

First Response Time = [Thời điểm phản hồi hợp lệ đầu tiên] – [Thời điểm ticket bắt đầu được tính]

Ví dụ:

09:00: Nhân viên gửi ticket báo lỗi không truy cập được hệ thống.
09:12: Kỹ thuật viên phản hồi, xác nhận đã tiếp nhận và yêu cầu thêm thông tin cần thiết.

Trong trường hợp này:

First Response Time = 12 phút.

Tuy nhiên, điểm quan trọng không nằm ở phép trừ thời gian mà ở cách doanh nghiệp định nghĩa “phản hồi hợp lệ”:

Một email tự động với nội dung “Chúng tôi đã nhận được yêu cầu của bạn” có được tính là First Response hay không? Hay phải có một kỹ thuật viên thực sự phản hồi?

Đây là phần cần được quy định rõ trong SLA hoặc trong cách hệ thống ticketing được cấu hình. Zendesk định nghĩa First reply time dựa trên khoảng thời gian từ lúc ticket được tạo đến phản hồi công khai đầu tiên của agent. Đây là một cách triển khai cụ thể của nền tảng, không phải quy tắc bắt buộc cho mọi Helpdesk.

Doanh nghiệp cũng phải xác định SLA tính theo business hours (giờ làm việc theo quy định) hay thời gian liên tục.

Một ticket gửi lúc 22:00 có thể tạo ra hai kết quả hoàn toàn khác nếu:

SLA hoạt động 24/7; hoặc
SLA chỉ tính trong khung giờ hỗ trợ, ví dụ 08:00 – 17:00 ngày làm việc.

Atlassian cho phép SLA sử dụng calendar để xác định giờ làm việc và thời điểm đồng hồ SLA chạy, trong khi Freshservice Benchmark 2025 cũng ghi rõ các chỉ số Average First Response Time và Average Resolution Time trong báo cáo của họ được tính theo business hours.

Vì vậy, một cam kết như “First Response trong 30 phút” sẽ chưa đủ rõ nếu không biết 30 phút theo quy định thời gian làm việc như thế nào.

Resolution Time được tính đến thời điểm nào?

Ở mức đơn giản:

Resolution Time = [Thời điểm ticket được giải quyết] – [Thời điểm bắt đầu tính ticket]

Giả sử ticket trước đó tiếp tục như sau:

09:00: Ticket được tạo.
09:12: Kỹ thuật viên phản hồi.
09:30: Bắt đầu xử lý.
14:00: Sự cố được xử lý và ticket đạt trạng thái resolved.

Nếu không có khoảng thời gian được loại trừ:

First Response Time = 12 phút

Resolution Time = 5 giờ

Ví dụ này cho thấy một ticket có thể đạt mục tiêu First Response rất tốt nhưng Resolution Time vẫn còn chậm.

HDI cũng phân biệt thời gian để ticket đạt resolution với lượng thời gian kỹ thuật viên thực sự bỏ ra để xử lý. Theo HDI, thời gian giải quyết phản ánh duration của ticket từ lúc mở đến khi đạt resolution, trong khi effort chỉ là thời gian nhân sự thực sự làm việc trên vấn đề đó.

Đây là khác biệt quan trọng. Một ticket kéo dài 6 giờ không có nghĩa kỹ thuật viên đã làm việc liên tục trong 6 giờ. Ticket có thể đang:

Chờ người dùng cung cấp thông tin.
Chờ vendor phản hồi.
Chờ phê duyệt.
Chờ maintenance window.
Chờ một đội kỹ thuật khác xử lý dependency.

Ngoài ra, doanh nghiệp cần thống nhất cách xử lý ticket reopen.

Giả sử kỹ thuật viên đánh dấu ticket là resolved lúc 14:00 nhưng đến 15:00 người dùng phản hồi rằng lỗi vẫn còn và ticket được mở lại. Nếu báo cáo chỉ tính đến lần resolved đầu tiên, số liệu có thể trông tích cực hơn trải nghiệm thực tế của người dùng.

Vì vậy, SLA cần xác định rõ:

Khi nào ticket được xem là resolved.
Resolved khác closed như thế nào trong workflow hiện tại.
Ticket reopen tiếp tục đồng hồ cũ hay tạo chu kỳ mới.
Báo cáo dùng lần resolution đầu tiên hay resolution cuối cùng.

Không nên để các quy tắc này chỉ tồn tại ngầm trong cấu hình phần mềm.

Khi nào SLA được pause và resume?

Đây là một trong những phần dễ tạo ra tranh luận nhất khi đánh giá SLA.

Hãy mở rộng với ví dụ sau:

first-response-time-va-resolution time — First Response Time vs Resolution Time

09:00: Ticket được tạo.
09:12: Kỹ thuật viên phản hồi.
09:30: Kỹ thuật viên yêu cầu người dùng cung cấp log.
10:00: Ticket chuyển sang trạng thái chờ người dùng.
13:00: Người dùng gửi log.
14:00: Sự cố được xử lý.

Thời gian thực tế từ khi tạo ticket đến khi resolved là 5 giờ.

Nhưng từ 10:00 đến 13:00, Helpdesk đang chờ thông tin cần thiết từ người dùng.

Nếu SLA đã quy định rõ thời gian chờ người dùng được pause, báo cáo có thể thể hiện:

First Response Time: 12 phút.
Tổng elapsed time: 5 giờ.
Waiting time: 3 giờ.
Resolution Time tính theo SLA: 2 giờ.

Đây không phải là cách “loại thời gian để làm đẹp báo cáo”. Pause SLA là một cơ chế hợp lệ nếu điều kiện được định nghĩa trước và áp dụng nhất quán.

Atlassian mô tả rõ SLA có thể thiết lập các điều kiện start, pause và stop; một ví dụ pause được hãng đưa ra là khi đội hỗ trợ đang chờ khách hàng cung cấp thêm thông tin.

Vấn đề phát sinh khi trạng thái “Pending” hoặc “Waiting” được sử dụng mà doanh nghiệp không biết:

Vì sao ticket được pause.
Ai chuyển trạng thái.
Bao nhiêu thời gian đã được loại khỏi SLA.
Khi nào đồng hồ bắt đầu chạy lại.

Nếu nhà cung cấp có thể pause ticket mà không có quy tắc rõ ràng, tỷ lệ đạt SLA có thể cao nhưng không còn phản ánh chính xác hiệu quả hỗ trợ.

Vì sao đạt First Response SLA nhưng người dùng vẫn thấy hỗ trợ chậm?

Hãy hình dung hai Helpdesk cùng tiếp nhận một ticket lúc 09:00.

Helpdesk A

Phản hồi: 09:05.
Resolution: 16:00.

Helpdesk B

Phản hồi: 09:20.
Resolution: 10:30.

Nếu chỉ nhìn First Response Time, Helpdesk A có vẻ tốt hơn.

Nhưng với một nhân viên đang không thể đăng nhập vào hệ thống làm việc, kết quả xử lý lúc 10:30 có thể quan trọng hơn rất nhiều so với việc nhận được câu trả lời lúc 09:05 rồi tiếp tục chờ đến cuối ngày.

Điều này không có nghĩa First Response Time không quan trọng.

Phản hồi sớm giúp:

Xác nhận yêu cầu đã được tiếp nhận.
Thu thập thêm thông tin để phân loại ticket.
Xác định priority.
Giảm tình trạng người dùng gửi lại cùng một yêu cầu qua nhiều kênh.
Khởi động quá trình escalation nếu cần.

Nhưng First Response Time không nên trở thành mục tiêu độc lập đến mức đội Helpdesk tối ưu cho việc trả lời nhanh thay vì giải quyết vấn đề.

Dữ liệu Freshservice Benchmark 2025 cũng tách riêng First Response SLA Rate và Resolution SLA Rate, thay vì coi một chỉ số có thể đại diện cho chỉ số còn lại. Báo cáo này dựa trên hệ sinh thái Freshservice nên không nên sử dụng hoàn toàn các số liệu từ báo cáo như một quy chuẩn bắt buộc cho mọi doanh nghiệp; giá trị ở đây nằm ở cách hai loại SLA được theo dõi riêng.

Vì vậy, đối với dịch vụ IT Helpdesk cho doanh nghiệp, doanh nghiệp nên đánh giá toàn bộ vòng đời ticket: tiếp nhận, phân loại, xử lý, escalation, phối hợp các bên liên quan và resolution; thay vì chỉ hỏi nhà cung cấp phản hồi nhanh đến đâu.

IT Support là gì? Vai trò, công việc và checklist cho doanh nghiệp

Một báo cáo SLA minh bạch nên thể hiện những gì?

Tỷ lệ “98% ticket đạt SLA” nghe có vẻ rõ ràng, nhưng con số đó chưa đủ để đánh giá nếu doanh nghiệp không biết SLA được tính như thế nào.

Một báo cáo liên quan đến First Response Time và Resolution Time nên làm rõ ít nhất:

Định nghĩa First Response Time: phản hồi nào được tính là phản hồi đầu tiên.
Định nghĩa Resolution Time: điều kiện nào được xem là đã giải quyết.
Support hours: SLA chạy 24/7 hay theo giờ làm việc.
Priority: mục tiêu có khác nhau giữa các mức độ ưu tiên hay không.
Pause reason: trường hợp nào được phép tạm dừng đồng hồ.
Paused duration: tổng thời gian đã được loại khỏi phép tính.
Reopen rule: ticket mở lại được tính tiếp hay tạo chu kỳ mới.
SLA met/breached: ticket đạt hoặc vi phạm mục tiêu nào.

Cần đặc biệt thận trọng với một tỷ lệ tổng hợp duy nhất như:

SLA Compliance = 98%

Hai nhà cung cấp cùng báo cáo 98% chưa chắc đang cung cấp cùng một mức dịch vụ.

Một bên có thể đo chủ yếu First Response. Bên còn lại đo cả Resolution. Một bên chạy đồng hồ 24/7. Bên khác chỉ tính business hours. Một bên cho pause khi chờ khách hàng nhưng hiển thị rõ thời gian pause; bên khác chỉ đưa ra kết quả cuối cùng.

Vì vậy, thứ cần thống nhất trước tiên không phải là “bao nhiêu phần trăm ticket đạt SLA”, mà là: SLA đang đo điều gì và đo theo quy tắc nào?

Chỉ sau khi chuẩn hóa định nghĩa, doanh nghiệp mới có cơ sở để so sánh hiệu quả giữa các giai đoạn, các nhóm hỗ trợ hoặc các nhà cung cấp.

Chuẩn hóa IT Helpdesk trước khi SLA trở thành một con số hình thức

Nếu yêu cầu IT vẫn đang đi qua email cá nhân, chat hoặc nhiều đầu mối; ticket khó xác định người chịu trách nhiệm; hoặc báo cáo SLA không cho biết rõ thời gian phản hồi và xử lý được tính như thế nào, vấn đề không còn nằm ở một KPI riêng lẻ mà nằm ở cách Helpdesk đang được vận hành.

IPSIP Việt Nam cung cấp dịch vụ IT Helpdesk và IT Support theo mô hình Remote và Onsite, có thể vận hành Helpdesk hoặc phối hợp cùng đội IT nội bộ. Yêu cầu được ghi nhận trên hệ thống ticket, phân loại theo mức độ ưu tiên và theo dõi theo SLA trong phạm vi hai bên thống nhất.