Muốn biết AI có giúp chăm khách tốt hơn không, anh chị đo một bộ chỉ số trước và sau khi bật AI: thời gian phản hồi đầu, tỷ lệ tin được trả lời, số khách bị sót, số lần khách phải hỏi lại. Đo mốc trước 2–4 tuần, lấy số từ phần mềm và so cùng khung giờ.
Tôi định viết bài này dưới dạng một case study có số trước và sau của một khách hàng. Đến ngày 09/11/2026, chưa có khách nào đồng ý công bố số liệu, nên bài này không đưa con số trước và sau của bất kỳ công ty nào. Thay vào đó, tôi viết phần mà các bài case study thường bỏ qua: chọn chỉ số gì, đo mốc trước thế nào, lấy số ở đâu, và những bẫy khi so. Ví dụ minh hoạ là các lần đo nội bộ của chính đội tôi khi làm ZCRM, phần gọi Zalo và trợ lý giọng nói ZVoice. Đó là số đo nội bộ trên hệ thống của chúng tôi, không phải số của khách.
Vì sao phải đo trước khi bật AI
Sau khi bật một trợ lý AI, chủ doanh nghiệp thường hỏi nhân viên «có đỡ hơn không». Câu trả lời hầu như luôn là «đỡ hơn», vì cảm giác có công cụ mới đã đủ làm người ta thấy nhẹ việc. Cảm giác đó không trả lời được câu hỏi khách có được phục vụ tốt hơn không.
Không có mốc trước thì mọi con số sau đều không có nghĩa. Một con số thời gian phản hồi đầu chỉ tốt hay xấu khi đặt cạnh con số của chính đội đó trước khi có AI. Cũng không thể đo mốc trước sau khi đã bật AI, vì hành vi của đội đã thay đổi.
Chọn chỉ số gì
Công ty nhỏ nên chọn ba đến bốn chỉ số, không hơn. Nhiều chỉ số quá thì không ai đọc báo cáo. Dưới đây là các chỉ số tôi gợi ý, kèm cách hiểu cho đúng:
| Chỉ số | Đo cái gì | Khi nào nên chọn |
|---|---|---|
| Thời gian phản hồi đầu (FRT) | Từ lúc khách nhắn đến lúc có người hoặc bot trả lời lần đầu | Gần như luôn chọn, khách cảm nhận rõ nhất |
| Thời gian phản hồi lượt tiếp (NRT) | Thời gian chờ ở các lượt sau trong cùng cuộc trò chuyện | Khi khách hay hỏi qua lại nhiều lượt trước khi mua |
| Tỷ lệ phản hồi | Phần trăm phiên trò chuyện có người trả lời | Khi đội nhỏ, tin dồn vào giờ cao điểm |
| Số khách bị sót | Phiên quá hạn mà chưa ai trả lời | Khi nghi đang mất khách ngoài giờ |
| Số cuộc gọi lại | Khách phải gọi hoặc nhắn lại vì câu trả lời trước chưa đủ | Khi bot trả lời nhanh nhưng nghi trả lời chưa đúng |
| Điểm hài lòng (CSAT) | Điểm khách chấm sau khi phiên được giải quyết | Khi đã có khảo sát sau phiên và đủ người trả lời |
Nên luôn có ít nhất một chỉ số về tốc độ và một chỉ số về chất lượng. Chỉ đo tốc độ thì một bot trả lời nhanh mà sai vẫn trông như thành công.
Đo mốc trước 2–4 tuần thế nào
Chọn kỳ đo không có sự kiện lạ
Tránh tuần có khuyến mãi lớn, tuần nghỉ lễ, tuần có nhân viên mới vào. Nếu không tránh được, ghi lại sự kiện đó cạnh số đo. Hai tuần là tối thiểu, bốn tuần thì dễ thấy xu hướng hơn.
Chốt định nghĩa trước khi đo
Ghi ra giấy: giờ làm việc là mấy giờ đến mấy giờ, ngưỡng phản hồi đầu bao nhiêu phút thì tính là đạt, tin nào không cần trả lời (ví dụ khách gửi nhãn dán cảm ơn). Định nghĩa này phải giữ nguyên cho kỳ sau. Đổi định nghĩa giữa chừng là cách nhanh nhất để có kết quả «cải thiện» không có thật.
Không đổi hai thứ cùng lúc
Bật AI cùng tuần với tuyển thêm người hay đổi kịch bản bán hàng thì không tách được phần nào do AI. Nếu buộc phải đổi nhiều thứ, đổi lần lượt, mỗi lần cách nhau ít nhất một kỳ đo.
Lấy số ở đâu
Ghi tay trong bảng tính chỉ hợp với vài chục tin mỗi tuần. Từ vài trăm tin trở lên, số phải lấy từ phần mềm, nơi giờ khách nhắn và giờ trả lời được ghi tự động.
Trong ZCRM, mô-đun «CSKH – SLA & khảo sát» có báo cáo chăm khách với các cột tôi dùng để so trước và sau:
- FRT trung bình tách theo giờ làm việc, ngoài giờ, cuối tuần và lễ, kèm P90 trong ca, tức mức mà 90 phần trăm phiên nhanh hơn. P90 cho thấy phần khách chờ lâu mà trung bình che mất.
- SLA phản hồi đầu và SLA lượt tiếp theo: bao nhiêu phiên trong hạn, bao nhiêu quá hạn theo ngưỡng anh chị đặt.
- Tỷ lệ phản hồi, Bị sót và cột riêng Không cần phản hồi, cột này không cộng vào số bị sót.
- CSAT và tỷ lệ khách trả lời khảo sát.
- Các góc xem theo nick hoặc kênh, theo hạng khách, theo nhân sự, và nút xuất Excel để lưu số mốc.
Phần mềm khác có tên cột khác. Điều cần kiểm là phần mềm ghi được giờ khách nhắn, giờ trả lời đầu và ai trả lời. Zalo OA cũng có báo cáo vận hành nâng cao gồm thống kê chat và cuộc gọi, theo bảng so sánh gói trên zalo.solutions/oa/pricing (kiểm 09/11/2026), nhưng chỉ phủ tin vào OA, không phủ tin vào Zalo cá nhân của nhân viên.
Tình huống thật của chúng tôi: bốn lần số đo suýt dẫn sai
Các ví dụ dưới đây là đo nội bộ trên hệ thống của đội tôi, không phải số của khách. Tôi kể vì mỗi lần là một bẫy anh chị cũng sẽ gặp khi đo AI chăm khách.
Cuộc gọi tự cắt sau 15 giây chưa phải là rớt cuộc gọi
Ngày 06/11/2026, khi thử gọi Zalo từ ZCRM, cuộc gọi tự cắt sau khoảng 15 giây ở một cấu hình và khoảng 40 giây ở cấu hình khác. Đọc nhanh thì tưởng cuộc gọi rớt giữa chừng. Xem kỹ thì điện thoại chưa bao giờ vào trạng thái nghe được tiếng, hai con số đó là thời gian chờ kết nối hết hạn. Sau khi sửa, cuộc gọi kiểm dài 63 giây và hai bên nghe được nhau. Bài học: trước khi so một con số, phải biết nó đo cái gì.
Độ trễ 2,1 giây cần tách theo từng khâu
Ngày 08/11/2026, trợ lý giọng nói tự dựng của chúng tôi đo được độ trễ khoảng 2,1 giây từ lúc khách nói xong đến lúc bot bắt đầu đáp, qua đường mạng thật. Dịch vụ giọng nói thuê ngoài mà chúng tôi đang dùng đo được khoảng 1,8 đến 2 giây. Con số tổng không nói được phải sửa ở đâu. Tách ra từng khâu thì khâu chậm nhất là mô hình ngôn ngữ soạn câu trả lời, không phải khâu nghe hay khâu đọc. Với bot chat cũng vậy: thời gian phản hồi đầu chậm có thể do mô hình, do tài liệu nền quá dài, hoặc do bot chờ người duyệt.
Đo khi máy đang phục vụ người khác làm hỏng cả hai
Bản thử của trợ lý giọng nói chỉ nhận một cuộc gọi một lúc. Khi chúng tôi chạy khách giả lập để đo, cuộc gọi thật đến cùng lúc bị từ chối. Số đo lúc đó vừa sai cho bài đo, vừa làm hỏng cuộc gọi thật. Khi đo AI chăm khách, ghi rõ lúc đo có bao nhiêu khách đang chờ, và không chạy thử nghiệm tải trong giờ khách thật nhắn.
Nhanh chưa đủ, phải đo cả đúng
Khi so các mẫu đọc giọng, một mẫu thuộc dòng đọc nhanh của nhà cung cấp đọc sai khoảng 5,1 phần trăm ký tự trong bộ câu thử nội bộ của chúng tôi. Chúng tôi chuyển sang mẫu mới hơn của cùng nhà cung cấp vì khách nghe sai tên sản phẩm thì tốc độ không còn ý nghĩa. Với chăm khách bằng chữ, chỉ số tương ứng là số cuộc gọi lại và số phiên phải chuyển cho người.
Những bẫy khi so trước và sau
- Tin trả lời từ điện thoại không vào báo cáo. Nhân viên trả lời khách bằng Zalo trên điện thoại riêng thì phần mềm không biết ai trả lời. ZCRM tách các lượt này thành dòng «Không xác định (trả lời ngoài ZCRM)» và không cộng vào KPI nhân sự. Nếu kỳ sau nhân viên chuyển sang trả lời trong phần mềm nhiều hơn, số «cải thiện» một phần chỉ là do dữ liệu đầy đủ hơn.
- Kỳ chưa đóng. Phiên đang chờ chưa tới hạn chưa thể gọi là sót. Báo cáo ZCRM ghi riêng «đang chờ» cho kỳ đang chạy. So một kỳ đã đóng với một kỳ chưa đóng sẽ làm kỳ sau trông tốt hơn thật.
- Mốc tính khác nhau. Trong báo cáo ZCRM, CSAT tính theo giờ gửi khảo sát, các cột còn lại theo giờ mở phiên. Xuất số vào bảng tính thì giữ đúng mốc này.
- Chỉ nhìn trung bình. Bot trả lời ngay các câu dễ làm trung bình giảm mạnh, trong khi khách hỏi câu khó vẫn chờ lâu như cũ. Nhìn thêm P90.
- Trả lời chậm còn tốn tiền. Theo hướng dẫn các loại tin của Zalo OA, tin tư vấn gửi trong 48 giờ kể từ tương tác cuối của khách thì miễn phí, ngoài 48 giờ thì tính phí; bảng giá ghi 55 đồng mỗi tin sau khi hết hạn mức của gói (oa.zalo.me, kiểm 09/11/2026). Đo thêm tỷ lệ tin trả lời trong 48 giờ nếu anh chị chăm khách qua OA.
Mẫu kế hoạch đo trong tám tuần
| Tuần | Việc | Đầu ra |
|---|---|---|
| 0 | Chốt 3–4 chỉ số, giờ làm việc, ngưỡng đạt | Một trang định nghĩa |
| 1–3 | Đo mốc, chưa bật AI, ghi sự kiện bất thường | Tệp xuất số mốc |
| 4 | Bật AI cho một kênh hoặc một nhóm câu hỏi | Ghi ngày giờ bật và phạm vi |
| 5–7 | Đo cùng chỉ số, cùng định nghĩa | Tệp xuất số sau |
| 8 | So, đọc lại 20 phiên chậm nhất của mỗi kỳ | Kết luận giữ, sửa hay dừng |
Đọc lại các phiên chậm nhất là bước tôi thấy hay bị bỏ qua nhất. Số cho biết có vấn đề, đọc phiên mới cho biết vấn đề là gì. Cách ghi lại trước và sau theo từng bước như vậy tôi cũng dùng khi kể việc thiết kế lại website bằng Claude Design và khi viết case study làm ZaloCRM với Claude Code.
Điểm bất lợi của cách đo này
- Mất thời gian chờ. Hai đến bốn tuần đo mốc là hai đến bốn tuần chưa dùng AI. Chủ doanh nghiệp sốt ruột thường bỏ bước này.
- Công ty nhỏ ít dữ liệu. Vài chục phiên mỗi tuần thì một ngày bất thường đủ làm lệch kết quả. Kết luận nên dè dặt và nhìn nhiều kỳ.
- Không đo được hết giá trị. Khách quay lại mua sau ba tháng nhờ được trả lời chu đáo hôm nay không hiện trong báo cáo tám tuần.
- Phụ thuộc phần mềm. Đội trả lời khách rải rác trên nhiều điện thoại thì phần mềm không thấy hết, số đo thiếu một phần.
- Bài này chưa có số của khách. Tôi chỉ nêu được phương pháp và số đo nội bộ. Khi có khách đồng ý công bố, tôi sẽ bổ sung bằng một bài riêng. Bài case study startup Việt dùng Claude là ví dụ cách kể chi phí, anh chị nên đọc kèm phần phương pháp ở đây.
Câu hỏi thường gặp về đo hiệu quả AI chăm khách
Cần đo mốc trước bao lâu?
Tối thiểu hai tuần, nên là bốn tuần. Kỳ đo phải tránh tuần khuyến mãi lớn và tuần nghỉ lễ, hoặc ghi rõ các sự kiện đó cạnh số đo.
Nên chọn chỉ số nào nếu chỉ được chọn một?
Thời gian phản hồi đầu, kèm P90 chứ không chỉ trung bình. Nhưng tôi khuyên luôn có thêm một chỉ số chất lượng như số cuộc gọi lại, vì chỉ đo tốc độ thì bot trả lời nhanh mà sai vẫn trông như thành công.
Không có phần mềm chăm khách thì đo thế nào?
Ghi tay trong bảng tính: giờ khách nhắn, giờ trả lời đầu, ai trả lời. Cách này hợp với vài chục tin mỗi tuần. Nhiều hơn thì ghi tay sẽ thiếu và sai, nên chuyển sang phần mềm ghi tự động.
Có nên bật AI cho tất cả kênh cùng lúc không?
Không nên. Bật cho một kênh hoặc một nhóm câu hỏi trước, giữ phần còn lại như cũ để có nhóm so sánh trong cùng thời gian.
Bao giờ có số trước và sau của khách thật?
Khi khách đồng ý công bố. Đến ngày 09/11/2026 chúng tôi chưa có khách nào đồng ý, nên tôi không đưa số. Mọi con số trong bài này là đo nội bộ trên hệ thống của đội tôi.
Nguồn: số đo nội bộ của đội ZCRM ngày 06/11/2026 (gọi Zalo từ ZCRM) và 08/11/2026 (trợ lý giọng nói ZVoice); tên cột báo cáo lấy từ mô-đun CSKH – SLA & khảo sát của ZCRM; oa.zalo.me (tổng quan các loại tin nhắn OA) và zalo.solutions/oa/pricing, kiểm ngày 09/11/2026.
