Cách tính thời gian phản hồi đầu tiên cho tin nhắn khách
Muốn biết khách thật sự chờ bao lâu, shop phải chốt đúng mốc bắt đầu, mốc kết thúc và tách lời báo đã nhận khỏi câu trả lời hữu ích.
Trả lời ngắn: Cách tính thời gian phản hồi đầu tiên cho tin nhắn khách
Thời gian phản hồi đầu tiên bằng lúc có câu trả lời hữu ích trừ lúc khách gửi yêu cầu mới. Shop cần chốt cách xử lý ngoài giờ, tin trùng và hội thoại mở lại; không dùng lời tự động báo đã nhận làm mốc kết thúc nếu khách chưa biết câu trả lời hoặc bước tiếp theo.
Công thức thời gian phản hồi đầu tiên là gì?
Với một yêu cầu mới, lấy thời điểm câu trả lời hữu ích đầu tiên trừ thời điểm khách gửi. Câu trả lời hữu ích phải xác nhận đúng nhu cầu, cung cấp thông tin có căn cứ hoặc nói rõ bước tiếp theo và người xử lý.
Ví dụ minh họa: khách gửi lúc bắt đầu hội thoại; hệ thống báo đã nhận; nhân viên sau đó hỏi đúng thông tin còn thiếu. Mốc của nhân viên mới là phản hồi hữu ích đầu nếu lời tự động chưa giúp khách tiến thêm bước nào.
Đừng để một tin tự động biến thời gian chờ thật thành con số gần bằng không.
Cần lưu những mốc nào trong mỗi hội thoại?
Bốn mốc cơ bản đủ cho lượt đo đầu: khách gửi, hệ thống ghi nhận, người hoặc hệ thống gửi phản hồi hữu ích, và yêu cầu được khép. Nếu có chuyển người, lưu thêm thời điểm chuyển và thời điểm người mới nhận.
Dữ liệu nên giữ mã hội thoại thay vì nội dung riêng không cần thiết. Chỉ người có nhiệm vụ mới được xem phần nhạy cảm.
| Mốc | Dùng để đo | Lỗi hay gặp |
|---|---|---|
| Khách gửi | Điểm bắt đầu | Dùng giờ nhập lại thủ công |
| Đã ghi nhận | Tốc độ tiếp nhận | Gọi là đã giải quyết |
| Phản hồi hữu ích | Thời gian phản hồi đầu | Tính câu trả lời sai nguồn |
| Khép yêu cầu | Thời gian xử lý | Đóng khi khách chưa xác nhận |
Tin nhắn ngoài giờ nên tính thế nào?
Chọn một quy tắc và dùng nhất quán: đo theo thời gian thực để thấy trải nghiệm đầy đủ, hoặc đo theo giờ phục vụ để quản lý năng lực ca. Tốt nhất báo cả hai nếu tin ngoài giờ chiếm tỷ lệ đáng kể.
Microsoft mô tả điều kiện ngoài giờ và thông báo tự động trong xử lý hàng chờ. Nguyên tắc rút ra là phải công bố kỳ vọng rõ; không phải mọi shop đều cần hoạt động liên tục.
- Ghi rõ múi giờ.
- Ghi lịch nghỉ và ngày lễ.
- Không xóa tin ngoài giờ khỏi báo cáo tổng.
- Tách báo đã nhận khỏi câu trả lời hữu ích.
Khi nào được tính là một yêu cầu mới?
Khách gửi thêm thông tin trong cùng việc chưa khép không nên tạo một yêu cầu mới chỉ để làm số liệu đẹp. Ngược lại, một vấn đề khác xuất hiện sau khi việc cũ đã đóng có thể bắt đầu phép đo mới.
Hãy viết quy tắc cho hội thoại mở lại, tin trùng từ nhiều kênh, khách trả lời sau nhiều ngày và tin do nhân viên chủ động gửi. Hai người đọc cùng một ca phải đi đến kết quả gần nhau.
Báo cáo nào giúp thấy khách chờ lâu?
Đừng chỉ đưa một số trung bình. Hãy có số lượng yêu cầu, trung vị, nhóm chờ lâu, tỷ lệ đúng mục tiêu, kết quả theo kênh, theo ca và theo loại việc.
Google SRE lưu ý số trung bình có thể che phần đuôi chậm. Dù tài liệu nói về hệ thống máy tính, nguyên tắc phân phối thời gian vẫn hữu ích cho hàng chờ tin nhắn: cần nhìn cả trường hợp thường và trường hợp chờ lâu.
Có thể tự động đo mà vẫn giữ người kiểm soát không?
Công cụ có thể ghi mốc, nối sự kiện và tạo cảnh báo. Nhân sự số có thể hỗ trợ gợi ý đâu là phản hồi hữu ích, nhưng giai đoạn đầu cần người lấy mẫu kiểm tra vì một câu nhanh chưa chắc đúng nhu cầu.
Con người chốt định nghĩa, kiểm tra sai lệch, sửa dữ liệu và quyết định thay đổi ca trực. Không dùng chỉ số này để phạt cá nhân khi chưa kiểm soát loại việc, tải và chất lượng nguồn.
Một phép đo tốt giúp sửa hàng chờ; nó không biến mọi vấn đề thành lỗi của người trực.
Câu hỏi thường gặp
Tin nhắn báo đã nhận có tính là phản hồi đầu tiên không?
Chỉ nên tính là tiếp nhận. Nếu chưa trả lời nhu cầu hoặc nói bước tiếp theo, không nên gọi là phản hồi hữu ích.
Có loại trừ thời gian ngoài giờ không?
Có thể báo theo giờ phục vụ, nhưng nên giữ thêm số thời gian thực để không mất góc nhìn của khách.
Khách nhắn thêm nhiều tin liên tiếp thì tính sao?
Gom theo một yêu cầu đang mở. Không tạo phép đo mới cho từng dòng trong cùng vấn đề.
Thời gian nhanh có nghĩa chất lượng tốt không?
Không. Cần đo thêm đúng nguồn, đủ dữ kiện, đúng quyền, số lần sửa và kết quả của yêu cầu.
Thuộc cụm chủ đề: AI chăm sóc khách hàng. Xem các câu hỏi liên quan để đi từ khái niệm đến cách áp dụng.
Nguồn tham khảo
- Service Level Objectives — Google Site Reliability Engineering
- Manage overflow of work items in queues — Microsoft Learn
Bước tiếp theo
Chọn một quy trình đang gây tắc
ATE có thể cùng bạn bóc tách đầu việc, điểm cần người duyệt và cách đo thử nghiệm. Chưa cần bắt đầu bằng cả phòng ban.