Cách tạo Báo cáo Thời gian Phản hồi Đầu tiên: Hướng dẫn Đầy đủ

Powerdrill Bloom·11 tháng 9, 2026

Thời gian phản hồi đầu tiên là khoảng thời gian khách hàng phải chờ đợi từ lúc gửi ticket cho đến khi nhận được phản hồi đầu tiên từ con người. Báo cáo thời gian phản hồi đầu tiên theo dõi thời gian chờ đợi đó qua các tuần, được phân chia theo trung vị và phân vị thứ 90 thay vì theo số trung bình. Bạn có thể xây dựng báo cáo này từ một tệp xuất dữ liệu ticket với hai mốc thời gian, và toàn bộ quá trình chỉ mất một câu lệnh hoặc ba công thức.

Việc đo lường rất đơn giản. Nhưng việc báo cáo lại là nơi các đội ngũ dễ tự đánh lừa bản thân một cách âm thầm, bởi vì cả chỉ số thống kê mặc định và hàm phân vị mặc định đều che giấu những khách hàng phải chờ đợi lâu nhất.

Ý nghĩa của thời gian phản hồi đầu tiên và cách tính toán

Thời gian phản hồi đầu tiên (FRT) là khoảng thời gian trôi qua giữa lúc ticket được gửi đến và phản hồi đầu tiên của nhân viên hỗ trợ cho khách hàng. Công thức tính rất đơn giản như sau:

Thời gian phản hồi đầu tiên = mốc thời gian của phản hồi đầu tiên từ con người − mốc thời gian tạo ticket

Hai quyết định sau đây sẽ biến công thức một dòng đó thành một thứ mà cả đội ngũ thực sự có thể đồng thuận.

Thư xác nhận tự động có được tính không? Câu trả lời là không nên. Một phản hồi tự động với nội dung "chúng tôi đã nhận được tin nhắn của bạn" không phải là câu trả lời cho câu hỏi. Việc tính cả phản hồi này sẽ tạo ra một biểu đồ đẹp mắt nhưng lại khiến khách hàng không hài lòng. Đây thường là một sai sót vô ý chứ không phải là sự lừa dối, và đó là cách phổ biến nhất khiến chỉ số FRT bị thổi phồng.

Đồng hồ có chạy qua đêm không? Theo thời gian lịch thông thường, một ticket gửi vào tối thứ Sáu và được trả lời vào sáng thứ Hai là một thất bại kéo dài 60 giờ. Nhưng theo giờ làm việc, thời gian đó có thể chưa đầy một giờ. Không có cách tính nào là sai. Việc bạn đưa ra một con số trong khi đồng nghiệp của bạn lại đưa ra con số kia chính là nguồn cơn của những cuộc tranh cãi.

FRT trung bình là quyết định thứ ba, và là quyết định mà hầu hết các công cụ đều tự động đưa ra thay bạn. Thời gian phản hồi thường bị lệch phải: hầu hết các ticket được trả lời nhanh chóng và một nhóm nhỏ còn lại phải chờ đợi rất lâu. Số trung bình cộng sẽ bị kéo lệch vào một phạm vi mà hầu như không khách hàng nào thực sự trải qua. Thay vào đó, hãy báo cáo chỉ số trung vị và phân vị thứ 90.

Những gì bạn cần chuẩn bị trước khi bắt đầu

Một tệp xuất dữ liệu ticket với mỗi hàng đại diện cho một cuộc hội thoại.
Hai mốc thời gian: thời điểm ticket được gửi đến và thời điểm nhân viên phản hồi lần đầu tiên.
Một định nghĩa rõ ràng về "phản hồi đầu tiên" loại trừ các thư xác nhận tự động và ghi chú nội bộ.
Giờ hỗ trợ của bạn, nếu bạn dự định báo cáo theo giờ làm việc.
Một quy tắc về lượng dữ liệu tối thiểu, để những tuần có quá ít ticket không tạo ra những số liệu vô nghĩa nhưng trông có vẻ đáng tin cậy.

Hãy quyết định ba yếu tố cuối cùng trước khi bạn xây dựng bất kỳ thứ gì. Việc thay đổi chúng sau này sẽ làm mất giá trị của tất cả các tuần trước đó trên biểu đồ, và một đường xu hướng được xây dựng trên một định nghĩa liên tục thay đổi còn tệ hơn là không có đường xu hướng nào.

Cách xây dựng báo cáo trong bảng tính

Tùy chọn 1: Chuyển đổi hai mốc thời gian thành một khoảng thời gian

Lấy mốc thời gian phản hồi đầu tiên trừ đi mốc thời gian ticket được gửi đến và định dạng kết quả dưới dạng giờ. Đó là thời gian phản hồi đầu tiên thô cho mỗi ticket, tính theo thời gian lịch thông thường.

Nếu bạn cần tính theo giờ làm việc, hàm NETWORKDAYS.INTL thường là điểm khởi đầu quen thuộc. Tài liệu hướng dẫn của Microsoft mô tả rất chính xác về kết quả trả về của hàm này. Hàm này cung cấp "số ngày làm việc trọn vẹn giữa hai ngày", sử dụng các tham số để xác định ngày nào được tính là ngày cuối tuần. Các ngày cuối tuần và bất kỳ ngày nào được chỉ định trong đối số ngày lễ "sẽ không được coi là ngày làm việc."

Hãy lưu ý cụm từ "ngày làm việc trọn vẹn". Hàm này trả về kết quả theo ngày chứ không phải theo giờ, vì vậy thời gian chờ đợi bốn giờ và bảy giờ trong cùng một ca làm việc sẽ hiển thị giống hệt nhau. Các khoảng thời gian ngắn hơn một ngày cần một cấu trúc kết hợp giữa số ngày làm việc với phần thời gian còn lại trong ngày. Đó là lý do tại sao việc báo cáo theo giờ làm việc là cả một dự án phức tạp chứ không chỉ đơn thuần là một công thức.

Tùy chọn 2: Tính toán trung vị và phân vị thứ 90

Hàm MEDIAN cung cấp cho bạn thời gian chờ đợi điển hình. Đối với nhóm khách hàng phải chờ lâu nhất (phần đuôi), Excel cung cấp hai hàm phân vị, và đây là lúc cùng một dữ liệu có thể cho ra hai kết quả khác nhau.

Hàm PERCENTILE.EXC chấp nhận giá trị k "trong khoảng từ 0 đến 1, không bao gồm hai đầu mút." Tài liệu hướng dẫn của hàm này nêu rõ rằng "nếu k không phải là bội số của 1/(n + 1), PERCENTILE.EXC sẽ nội suy để xác định giá trị tại phân vị thứ k." Hàm PERCENTILE.INC chấp nhận k "trong khoảng từ 0 đến 1, bao gồm cả hai đầu mút," và thực hiện nội suy khi k "không phải là bội số của 1/(n - 1)."

Mẫu số khác nhau, cách nội suy khác nhau, dẫn đến kết quả p90 khác nhau. Không có hàm nào sai cả. Đó chỉ là hai quy ước khác nhau, và một báo cáo âm thầm thay đổi giữa hai hàm này thực chất đang phản ánh sự thay đổi trong công thức của bạn chứ không phải tình trạng thực tế của hàng đợi.

Phiên bản loại trừ (exclusive) có một điểm hạn chế nghiêm ngặt hơn. Tài liệu hướng dẫn của nó cảnh báo rằng "nếu không thể nội suy cho phân vị k đã chỉ định, Excel sẽ trả về lỗi #NUM!." Vào một tuần có ít dữ liệu, chỉ với một vài ticket trong hàng đợi, chỉ số p90 có thể đơn giản là không thể tính toán được.

Tùy chọn 3: Trình bày báo cáo

Nhóm các ticket theo tuần. Đặt đường trung vị và đường p90 cạnh nhau dưới dạng hai đường biểu diễn, và thêm số lượng ticket dưới dạng biểu đồ cột phía sau chúng. Số lượng ticket không phải để trang trí. Nó giúp người đọc không đánh giá quá mức một sự gia tăng đột biến vốn chỉ được tạo nên từ mười một ticket.

Sau đó, hãy thêm một dòng văn bản nêu rõ loại đồng hồ thời gian và phương pháp tính phân vị đã sử dụng. Câu văn đó chính là yếu tố giúp một người không tham gia trực tiếp vẫn có thể tái lập lại báo cáo này vào quý tới.

Những điểm hạn chế khi sử dụng bảng tính

Không có bước nào trong ba bước trên là khó. Tuy nhiên, trở ngại là cả ba bước đều phải được thực hiện lại mỗi tuần, trên một tệp xuất dữ liệu mà tên các cột có thể thay đổi bất cứ khi nào có ai đó chỉnh sửa giao diện của hệ thống helpdesk.

Ba trở ngại cụ thể thường xuyên lặp lại.

Cột phản hồi hiếm khi sạch dữ liệu. Các thư xác nhận tự động, ghi chú nội bộ và phản hồi của nhân viên thường nằm chung trong một trường dữ liệu, vì vậy hàng đầu tiên không phải lúc nào cũng là câu trả lời đầu tiên từ con người. Việc phân tách chúng đòi hỏi sự đánh giá thủ công trên mỗi tệp xuất dữ liệu chứ không thể giải quyết bằng một công thức.

Các phân vị luôn đòi hỏi phải đưa ra quyết định trong mỗi lần tính. Chọn hàm nào, những tuần nào có đủ lượng dữ liệu, và hiển thị cái gì khi việc tính toán bị lỗi do hàng đợi có quá ít dữ liệu.

Giờ làm việc đòi hỏi phải bảo trì liên tục. Một khi bạn đã cam kết tính theo khung giờ hỗ trợ, mỗi ngày nghỉ lễ và mỗi lần thay đổi ca làm việc đều trở thành một tác vụ cần cập nhật trong bảng tính. Chỉ cần bỏ sót một chi tiết, số liệu của cả tuần sẽ bị sai lệch.

Kết quả là bạn có một báo cáo chỉ chính xác vào tuần nó được xây dựng, và sau đó số liệu sẽ dần dần bị sai lệch một cách âm thầm.

Cách tạo báo cáo thời gian phản hồi đầu tiên bằng AI

Bước 1: Tải lên tệp xuất dữ liệu ticket

Mở Powerdrill Bloom và tải tệp xuất dữ liệu trực tiếp từ hệ thống helpdesk của bạn lên. Excel, CSV, PDF và các định dạng tài liệu khác đều được hỗ trợ tải lên trong gói miễn phí, vì vậy bạn có thể tải tệp xuất dữ liệu thô lên ngay lập tức.

Tải lên tệp xuất dữ liệu ticket để xây dựng báo cáo thời gian phản hồi đầu tiên

Hãy giữ lại tất cả các cột mốc thời gian, kể cả các cột tự động. Bạn cần chúng để xác minh phản hồi nào được tính, và để thay đổi định nghĩa sau này mà không cần phải xuất lại dữ liệu.

Bước 2: Nêu rõ loại đồng hồ thời gian và các số liệu thống kê bạn muốn

Hãy mô tả phép đo bằng ngôn ngữ tự nhiên thay vì bằng các công thức. Chỉ rõ mốc thời gian nào bắt đầu tính giờ, phản hồi nào kết thúc việc tính giờ, và có tính những ngày cuối tuần hay không. Sau đó, yêu cầu tính toán trung vị và phân vị thứ 90 theo từng tuần, đi kèm với số lượng ticket tương ứng.

Hãy nêu rõ cả phương án xử lý cho những tuần có ít dữ liệu. Yêu cầu ẩn chỉ số phân vị nếu số lượng ticket dưới mức tối thiểu. Cách này tốt hơn nhiều so với việc để hiển thị một ô bị lỗi, hoặc một con số trông có vẻ chắc chắn nhưng thực chất chỉ được xây dựng từ bốn hàng dữ liệu.

Mỗi số liệu trả về đều đi kèm với các hàng dữ liệu gốc phía sau, nhờ đó một tuần có số liệu nghi vấn có thể được mở ra để kiểm tra trực tiếp thay vì phải tranh cãi.

Bước 3: Tạo báo cáo và lưu câu lệnh (prompt)

Yêu cầu hiển thị hai đường biểu diễn và một chuỗi cột trên trục thời gian theo tuần, cùng với một ghi chú nêu rõ quy ước phân vị nào đã được sử dụng. Sau đó, xuất báo cáo dưới dạng hình ảnh, trang tính hoặc trang trình bày.

Chọn chủ đề trang trình bày trong Powerdrill Bloom trước khi tạo báo cáo thời gian phản hồi đầu tiên và lưu câu lệnh

Vào tuần tới, bạn chỉ cần tải lên tệp xuất dữ liệu mới và chạy lại cùng một câu lệnh. Định nghĩa sẽ được giữ nguyên, và đó là cách duy nhất để việc so sánh giữa các tuần thực sự có ý nghĩa. Trang tạo biểu đồ từ Excel sẽ hướng dẫn trực tiếp quy trình vẽ biểu đồ này.

Những yếu tố cần có trong báo cáo thời gian phản hồi đầu tiên

Yếu tố	Lý do cần có	Hệ quả nếu thiếu yếu tố này
Đường trung vị	Thời gian chờ đợi điển hình của khách hàng	Số trung bình bị che lấp bởi các giá trị ngoại lai
Đường phân vị thứ 90	Trải nghiệm của một phần mười nhóm khách hàng phải chờ lâu nhất	Những điểm nghẽn nghiêm trọng ở phần đuôi vẫn bị che khuất
Biểu đồ cột số lượng ticket	Bối cảnh cho mọi sự biến động	Những tuần có ít dữ liệu dễ bị hiểu nhầm là xu hướng chung
Loại đồng hồ thời gian được nêu rõ	Giờ lịch thông thường hoặc giờ làm việc	Hai đội ngũ đưa ra các con số khác nhau
Phương pháp tính phân vị được nêu rõ	Khả năng tái lập	Cùng một tuần nhưng lại thay đổi giá trị giữa các lần tạo báo cáo khác nhau
Quy tắc lượng dữ liệu tối thiểu	Đảm bảo tính trung thực trên các phân khúc ít dữ liệu	Tránh các lỗi tính toán hoặc độ chính xác ảo
Phân tích chi tiết theo kênh	Nơi thực sự xảy ra tình trạng chậm trễ	Một hàng đợi kém hiệu quả sẽ kéo tụt toàn bộ chỉ số chung

Một ví dụ thực tế

Hãy lấy ví dụ một tuần có 240 ticket. Thời gian phản hồi đầu tiên trung bình là 5.1 giờ, trung vị là 1.4 giờ, và p90 là 19.7 giờ.

Cả ba con số trên đều chính xác. Nhưng số trung bình cộng lại là con số duy nhất không phản ánh đúng trải nghiệm của bất kỳ ai. Hầu hết khách hàng đều chờ đợi dưới 90 phút, và một phần mười nhóm khách hàng chậm nhất phải chờ gần như cả ngày. Nếu chỉ trình bày số trung bình, người đọc sẽ kết luận rằng hàng đợi này ở đâu cũng ở mức trung bình kém, trong khi thực tế nó hoạt động rất nhanh nhưng lại có một phần đuôi rất tệ. Cách khắc phục cho một phần đuôi tệ hoàn toàn khác với cách khắc phục cho một hàng đợi chậm chạp. Đó là lý do tại sao sự khác biệt này xứng đáng được thể hiện bằng một biểu đồ thay vì chỉ một ô dữ liệu duy nhất.

Phân khúc dữ liệu mà không làm hỏng báo cáo

Câu hỏi hiển nhiên tiếp theo là kênh hoặc hàng đợi nào chậm nhất. Việc chia nhỏ theo phân khúc rất hữu ích, nhưng đó cũng là cách nhanh nhất khiến báo cáo đưa ra thông tin sai lệch.

Hai quy tắc sau sẽ giúp báo cáo luôn trung thực. Chỉ thực hiện phân tách ở những nơi lượng dữ liệu hàng tuần duy trì trên mức tối thiểu của bạn, và giữ lại đường biểu diễn tổng thể trên biểu đồ để người đọc có một mốc cơ sở để so sánh. Một hàng đợi chỉ có chín ticket mỗi tuần xứng đáng được xem xét theo tháng chứ không phải theo tuần.

Nếu việc phân tách dữ liệu quan trọng hơn xu hướng, một bảng nhỏ hiển thị trung vị và p90 cho mỗi hàng đợi sẽ mang lại nhiều thông tin hữu ích hơn là năm đường biểu diễn chồng chéo lên nhau.

Cách cải thiện thời gian phản hồi đầu tiên

Báo cáo chỉ thực sự có giá trị nếu nó chỉ ra được hướng giải quyết. Có bốn đòn bẩy thường xuyên xuất hiện, và báo cáo sẽ cho bạn biết bạn cần sử dụng đòn bẩy nào.

Một phần đuôi tệ đi kèm với một trung vị tốt thường phản ánh vấn đề về thời gian trực hỗ trợ chứ không phải tốc độ xử lý. Các ticket gửi đến ngoài giờ làm việc, hoặc nằm trong hàng đợi chỉ có một chuyên gia phụ trách, sẽ phải nằm chờ cho đến khi có người làm việc trở lại. Hãy xem xét khung giờ gửi ticket trong ngày trước khi đánh giá hiệu suất của nhân viên.

Chỉ số trung vị tăng lên trong khi lượng dữ liệu không đổi thường có nghĩa là hàng đợi đang phải tiếp nhận một loại ticket mới mà chưa ai có sẵn biểu mẫu hướng dẫn. Việc phân tích chi tiết theo kênh sẽ làm rõ điều này.

Chỉ số trung vị tăng đi kèm với lượng dữ liệu tăng là một vấn đề về nhân sự, và các cột biểu thị số lượng ticket chính là minh chứng rõ ràng nhất.

Một báo cáo không có biến động nhưng không ai tin tưởng là do vấn đề về định nghĩa. Hãy công bố loại đồng hồ thời gian và phương pháp tính phân vị ngay ở phần đầu báo cáo, và mọi cuộc tranh cãi sẽ chấm dứt.

Để có được góc nhìn về số lượng và trạng thái đi kèm với báo cáo này, hãy xem các hướng dẫn của chúng tôi về báo cáo ticket hỗ trợ và báo cáo CSAT. Trang chatbot dịch vụ khách hàng sẽ đề cập đến khía cạnh giảm tải cho cùng một hàng đợi đó.

Thế nào là một mục tiêu tốt

Các đội ngũ thường thiết lập mục tiêu thời gian phản hồi đầu tiên trước khi họ có được biểu đồ phân phối dữ liệu, đó là lý do tại sao các mục tiêu thường trở nên vô nghĩa hoặc không thể đạt được.

Hãy đặt hai con số thay vì một, và công bố cả hai. Một mục tiêu trung vị mô tả trải nghiệm thông thường, và một mục tiêu p90 mô tả trải nghiệm tồi tệ nhất mà bạn sẵn sàng chấp nhận. Một đội ngũ có trung vị là 1.4 giờ và p90 là 19.7 giờ đang gặp vấn đề ở phần đuôi. Một mục tiêu duy nhất là hai giờ sẽ hoàn toàn không thể làm nổi bật được vấn đề này.

Sau đó, hãy nêu rõ loại đồng hồ thời gian bên cạnh mục tiêu. "Hai giờ" theo giờ làm việc và "hai giờ" theo giờ lịch thông thường là hai lời hứa hoàn toàn khác nhau. Đội ngũ hỗ trợ và ban lãnh đạo sẽ tự động hiểu theo cách có lợi nhất cho góc nhìn của họ.

Các sai lầm phổ biến

Báo cáo số trung bình cộng. Đây là chỉ số thống kê gần như chắc chắn sẽ gây hiểu lầm đối với một phân phối lệch phải, và nó lại là mặc định trong hầu hết các công cụ bảng tính.

Tính thư phản hồi tự động là phản hồi đầu tiên. Đây là cách nhanh nhất để tạo ra một biểu đồ trông cực kỳ xuất sắc nhưng lại không trùng khớp với trải nghiệm thực tế của bất kỳ ai.

Thay đổi các hàm phân vị giữa quý. Nếu chỉ số p90 của bạn được cải thiện đúng vào tuần có ai đó chỉnh sửa công thức, thì thực chất bạn chỉ đang đo lường sự thay đổi của công thức đó mà thôi.

Lẫn lộn giữa giờ lịch thông thường và giờ làm việc. Một ngày cuối tuần tính theo giờ lịch thông thường là 48 giờ thất bại. Nhưng theo giờ làm việc, nó có thể bằng không. Hãy chọn một cách tính và dán nhãn rõ ràng cho nó.

Bỏ chuỗi số lượng ticket để giảm bớt sự lộn xộn. Các cột biểu thị số lượng chính là lý do giúp bất kỳ ai cũng có thể phân biệt được một sự suy giảm thực sự với một tuần ít việc.

Báo cáo mục tiêu mà không có biểu đồ phân phối. Một con số duy nhất kiểu "chúng tôi đã đạt mốc hai giờ" không cho người đọc biết bất cứ điều gì về những khách hàng đã phải chờ đợi tới chín giờ.

Kết luận

Một báo cáo thời gian phản hồi đầu tiên rất xứng đáng được xây dựng một cách bài bản vì đây là một trong số ít các chỉ số hỗ trợ mà khách hàng thực sự cảm nhận được. Hai đường biểu diễn, một chuỗi cột, một loại đồng hồ thời gian được nêu rõ và một quy ước phân vị rõ ràng sẽ đánh bại bất kỳ bảng điều khiển nào chỉ hiển thị một số trung bình duy nhất.

If rebuilding it every week is what stops you, move the definition into a saved prompt and regenerate it from each new export. Hãy dùng thử Powerdrill Bloom với tệp xuất dữ liệu ticket của tháng trước để thấy được cả đường trung vị và phần đuôi trên cùng một trục tọa độ.

Các câu hỏi thường gặp

Thời gian phản hồi đầu tiên trong dịch vụ khách hàng là gì?

Đó là khoảng thời gian trôi qua từ khi ticket của khách hàng được gửi đến cho đến khi nhận được phản hồi đầu tiên từ nhân viên hỗ trợ. Các thư xác nhận tự động thường bị loại trừ, vì chúng không trả lời câu hỏi của khách hàng.

Công thức tính thời gian phản hồi đầu tiên là gì?

Lấy mốc thời gian của phản hồi đầu tiên từ con người trừ đi mốc thời gian tạo ticket. Đối với phiên bản tính theo giờ làm việc, hãy bắt đầu từ hàm NETWORKDAYS.INTL (hàm trả về số ngày làm việc trọn vẹn và cho phép bạn xác định các ngày cuối tuần cũng như ngày lễ), sau đó cộng thêm phần thời gian còn lại trong ngày.

Báo cáo thời gian phản hồi đầu tiên nên sử dụng số trung bình hay trung vị?

Nên sử dụng trung vị, đi kèm với phân vị thứ 90 bên cạnh. Thời gian phản hồi thường bị lệch phải, vì vậy một số lượng nhỏ các ticket bị xử lý rất chậm sẽ kéo số trung bình cộng về phía một giá trị mà thực tế rất ít khách hàng trải qua.

Sự khác biệt giữa PERCENTILE.EXC và PERCENTILE.INC là gì?

Chúng sử dụng các quy tắc nội suy khác nhau. Hàm PERCENTILE.EXC thực hiện nội suy khi k không phải là bội số của 1/(n + 1) và chỉ chấp nhận giá trị k nằm trong khoảng từ 0 đến 1 (không bao gồm hai đầu mút). Hàm PERCENTILE.INC sử dụng 1/(n - 1) và chấp nhận cả giá trị 0 và 1.

Tại sao chỉ số p90 của tôi lại trả về lỗi #NUM!?

Hàm PERCENTILE.EXC trả về lỗi đó khi mảng dữ liệu bị trống, hoặc khi k bằng hoặc nằm ngoài giới hạn từ 0 đến 1. Hàm này cũng trả về lỗi khi không thể nội suy cho phân vị mà bạn yêu cầu, đây chính là điều thường xảy ra vào những tuần có quá ít dữ liệu.