Khách hàng đang cần được giúp ở đâu, và chatbot đã giúp được đến đâu?
Hơn 65 nghìn yêu cầu chăm sóc khách hàng có thể kể rất nhiều điều, nếu được đặt cạnh nhau đúng cách. Tôi xây dựng báo cáo VOC và hiệu suất chatbot trên Power BI để đội ngũ nhìn rõ khách hàng đang vướng điều gì, yêu cầu nào mất nhiều thời gian và lúc nào cần nhân viên tiếp nối cuộc hội thoại.
1. Khi nhiều cuộc liên hệ chưa tạo thành một bức tranh rõ ràng
Một khách hàng hỏi cách sử dụng ứng dụng tích điểm. Người khác gặp vấn đề với sản phẩm. Một cuộc trò chuyện được bot trả lời, cuộc tiếp theo cần nhân viên hỗ trợ. Với đội CSKH, từng việc đều cần xử lý; với người quản lý, câu hỏi còn là: vấn đề nào đang lặp lại nhiều nhất, và đội ngũ nên dành sức cho đâu?
Dự án kết nối hai góc nhìn: tiếng nói khách hàng qua các case khiếu nại, thắc mắc; và cách hệ thống phục vụ khách hàng qua hội thoại bot và nhân viên. Mục tiêu là giúp người xem đi từ một con số tổng đến nguyên nhân cụ thể, thay vì dừng ở việc đếm bao nhiêu yêu cầu đã đến.
2. Bắt đầu bằng những câu hỏi gần với công việc
Khách hàng chủ yếu cần giải đáp hay đang gặp vấn đề cần xử lý?
Nhóm nguyên nhân, địa bàn hoặc thời điểm nào tập trung nhiều yêu cầu?
Đóng case trong 24 giờ và đóng trong cùng ngày có đang bị hiểu là một chỉ số?
Bot đảm nhận được bao nhiêu hội thoại? Những cuộc kéo dài đang nằm ở bot hay nhân viên?
Có đủ đánh giá để kết luận khách hàng được hỗ trợ tốt hay chưa?
3. Hai luồng dữ liệu, hai đơn vị cần phân biệt
Một case là một yêu cầu CSKH; một conversation là một hội thoại. Tôi trình bày hai nhóm chỉ số riêng để người xem không cộng hai loại bản ghi thành “tổng khách hàng”. Số khách hàng cũng cần đọc riêng với số lượt liên hệ.
| Nguồn trong báo cáo | Nội dung khai thác | Câu hỏi được trả lời |
|---|---|---|
| Case, account và transaction | Mã case, loại yêu cầu, nguồn liên hệ, nhóm nguyên nhân, ngày mở và thời gian xử lý | Khách hàng vướng gì và đội CSKH xử lý ra sao? |
| Chat transcription | Người dùng, loại hội thoại, trạng thái kết thúc, kênh, khung giờ và đánh giá | Bot và nhân viên đang chia sẻ khối lượng công việc thế nào? |
| Ngày và địa bàn | Bảng ngày, tỉnh thành và khu vực | Vấn đề xuất hiện ở đâu và vào thời điểm nào? |
4. Từ dữ liệu đến một báo cáo có thể lần theo
Tệp Power BI thể hiện các nhóm bảng case, hội thoại, ngày, địa bàn và benchmark. Tôi tổ chức trải nghiệm đọc theo hai nhánh: VOC và chatbot, dùng các bộ lọc thời gian, loại yêu cầu, nguyên nhân, khu vực và kênh để thu hẹp câu hỏi.
Xác định đơn vị đếm: tách case, khách hàng, hội thoại và người dùng; giữ riêng các trạng thái bot, nhân viên và trạng thái kết thúc.
Đưa ngữ cảnh vào chỉ số: đọc số lượng cùng tỷ trọng, thời gian xử lý, ngày và địa bàn. Không đánh giá một nhóm chỉ bằng số yêu cầu lớn hay nhỏ.
Đi từ rộng đến sâu: trang tổng quan dẫn sang nhóm nguyên nhân, nguyên nhân phụ, tỉnh thành và bảng chi tiết theo thời gian.
Mở nhánh hiệu suất hội thoại: theo dõi tỷ lệ tự động, phần có nhân viên hỗ trợ, nhóm thời lượng, kênh và khung giờ.
Đối chiếu trước khi kết luận: kiểm tra bộ lọc, phần chưa phân loại và lượng đánh giá còn trống. Sơ đồ bên trên tóm tắt luồng phân tích này; không mô tả một hạ tầng đồng bộ tự động chưa được xác minh.
5. Điều gì hiện ra khi đặt các chỉ số cạnh nhau?
Phần lớn là thắc mắc, nhưng không thể bỏ qua phần chưa được phân loại
Bản VOC tổng hợp hiển thị khoảng 65,82 nghìn case và 42,59 nghìn khách hàng. Trong đó có 54.067 thắc mắc (82,14%) và 10.833 khiếu nại (16,46%). Biểu đồ còn một phần khoảng 0,92 nghìn, tương đương 1,4%, ngoài hai nhãn này. Giữ phần đó trong bức tranh giúp tránh tạo cảm giác dữ liệu đã được phân loại đầy đủ.
Nhóm Reward App nổi bật trên biểu đồ nguyên nhân: khoảng 47,66 nghìn thắc mắc và 9,24 nghìn khiếu nại. Đây là nơi đội ngũ có thể bắt đầu đọc sâu các nguyên nhân phụ, xem câu hỏi nào lặp lại và nội dung hướng dẫn nào cần rõ hơn. Khối lượng lớn là tín hiệu để ưu tiên điều tra, chưa đủ để kết luận ứng dụng có chất lượng kém.
“Trong 24 giờ” khác với “trong cùng ngày”
Báo cáo hiển thị thời gian xử lý trung bình 27,356 giờ, tỷ lệ đóng case trong 24 giờ 85,73% và tỷ lệ đóng trong cùng ngày 83,02%. Một yêu cầu mở cuối ngày và đóng sáng hôm sau có thể đạt chỉ số thứ nhất nhưng không đạt chỉ số thứ hai. Đặt hai chỉ số cạnh nhau giúp đội vận hành đọc đúng ý nghĩa thay vì sử dụng chúng thay thế cho nhau.
Bot tiếp nhận nhiều chưa có nghĩa là khách hàng đã hài lòng
Bản VOC tổng hợp ghi khoảng 154,74 nghìn hội thoại: 56,12% ở nhóm tự động và 43,88% ở nhóm chuyển đổi/hỗ trợ theo nhãn báo cáo. Đây là cách phân bổ hội thoại, không phải bằng chứng rằng bot đã giải quyết thành công từng nhu cầu.
Bản Human & Bot là một phạm vi xuất báo cáo khác: bảng tổng cộng ghi 64.326 hội thoại, gồm 31.873 bot session và 32.453 agent support. Trong nhóm hơn 60 phút, bảng ghi 27.051 hội thoại có nhân viên hỗ trợ và 897 bot session. Góc nhìn này gợi ý đội ngũ xem kỹ các cuộc kéo dài và cách ghi nhận trạng thái kết thúc, trước khi quy nguyên nhân cho năng suất nhân viên.
Đánh giá cũng là một khoảng trống đáng chú ý: bản Human & Bot hiển thị 6.931 OK, 45 NOT OK và khoảng 24,90 nghìn EMPTY trong nhóm bot. EMPTY là thiếu đánh giá; không nên coi đó là hài lòng, cũng không nên coi là không hài lòng.
6. Từ báo cáo đến việc cần làm tiếp
| Điểm cần nhìn sâu | Hướng hành động |
|---|---|
| Thắc mắc tập trung ở Reward App | Đọc các nguyên nhân phụ, ưu tiên hướng dẫn và câu trả lời cho những tình huống lặp lại. |
| Hội thoại kéo dài có nhân viên hỗ trợ | Kiểm tra thời gian chờ, chuyển giao, trạng thái kết thúc và đặc điểm của từng nhóm yêu cầu. |
| Nhiều đánh giá còn trống | Rà soát cách thu thập phản hồi để có cơ sở đánh giá chất lượng hỗ trợ. |
| Khối lượng thay đổi theo kênh và khung giờ | Dùng các trang phân tích kênh và thời gian để trao đổi về phân bổ nhân sự. |
Giá trị của sản phẩm là một đường đi rõ ràng từ “khách đang liên hệ nhiều” đến “nên mở nhóm dữ liệu nào để tìm vấn đề”. Báo cáo tạo cơ sở cho quyết định; tài liệu hiện có chưa chứng minh mức giảm chi phí, tăng hài lòng hay cải thiện thời gian xử lý sau triển khai.
7. Phạm vi và cách đọc tài liệu
Hai PDF bên dưới là hai bản xuất có tổng số khác nhau. Không ghép chúng thành một chuỗi trước–sau hoặc dùng chênh lệch để tuyên bố tăng trưởng. Một số chỉ số được làm tròn theo nghìn và phụ thuộc bộ lọc ở thời điểm xuất. Quy trình được dựng lại từ cấu trúc báo cáo và các trường quan sát được trong PBIX; chưa có căn cứ để khẳng định lịch refresh, câu lệnh ETL hay công thức bên trong mọi measure.
Công cụ: Power BI. Tài liệu minh hoạ đã gỡ logo; nội dung, nhãn kênh và số liệu báo cáo được giữ nguyên.
