AI đọc đúng email đổi địa chỉ giao hàng nhưng cập nhật nhầm hồ sơ vì khách có hai mã đơn gần giống nhau. Tác vụ vẫn mang trạng thái “hoàn thành”. Theo dõi hệ thống có chạy hay không sẽ bỏ qua lỗi này.
Đội cần kiểm tra dữ liệu bắt buộc, quyền hành động, trường hợp chuyển người và cách đưa lỗi mới trở lại bộ kiểm thử.
Những gì thường thay đổi sau khi phát hành
Dữ liệu thực tế khác dữ liệu thử
Khách có thể gửi ảnh qua Zalo, trả lời chuỗi email cũ hoặc dùng cách viết chưa có trong bộ mẫu. CRM cũng thay đổi khi đội thêm trường và trạng thái.
Chính sách và cấu hình tiếp tục thay đổi
Bảng giá, prompt, model và quyền công cụ đều có thể đổi. Gắn phiên bản giúp tìm thời điểm và nguyên nhân phát sinh lỗi.
Chất lượng phải gắn với một quyết định vận hành
Không có một chỉ số chung cho mọi quy trình. Với phân loại email, hãy theo dõi yêu cầu bị gán sai và trường hợp cần chuyển người. Với báo giá, dữ liệu khách hàng, điều khoản, mức giảm giá và trạng thái duyệt quan trọng hơn cách diễn đạt.
Trước khi tạo báo cáo, hãy chốt các kết quả có thể quan sát:
- Trường bắt buộc bị thiếu hoặc lấy sai nguồn.
- Hành động vượt quyền, chẳng hạn gửi email khi mới được phép tạo nháp.
- Tác vụ chuyển sai người hoặc thiếu dữ liệu để xử lý tiếp.
- Kết quả bị nhân viên sửa trước khi dùng.
- Trường hợp hoàn thành kỹ thuật nhưng không đạt yêu cầu nghiệp vụ.
- Thời gian ngoại lệ nằm chờ trước khi có người xác nhận.
Mỗi tín hiệu phải dẫn tới một hành động: sửa dữ liệu, điều chỉnh quy tắc, giới hạn quyền hoặc bổ sung mẫu kiểm thử.
Quy trình giám sát chất lượng sau phát hành
1. Gắn phiên bản cho thành phần có thể thay đổi
Lưu model, prompt, tài liệu, quy tắc và cấu hình công cụ cùng mỗi tác vụ để truy ngược khi có lỗi.
2. Lấy mẫu theo tác vụ và mức hậu quả
Tách mẫu theo kênh vào, loại yêu cầu và hành động. Tác vụ liên quan đến tiền, dữ liệu cá nhân hoặc cam kết cần kiểm tra chặt hơn.
3. Kiểm tra kết quả và đường đi
Đối chiếu đầu vào, nguồn tham chiếu, công cụ đã gọi, trạng thái cuối và lý do chuyển người. Nội dung đúng vẫn là lỗi nếu gửi khi chưa được duyệt.
4. Phân loại lỗi theo nguyên nhân
Tách lỗi dữ liệu, quy tắc, quyền, công cụ và chính sách. Đừng sửa prompt cho vấn đề nằm ở CRM hoặc quy trình duyệt.
5. Đặt ngưỡng cảnh báo theo hậu quả
Chặn ngay hành động bị cấm hoặc nguy cơ lộ dữ liệu. Lỗi diễn đạt có thể xem theo đợt. Mỗi ngưỡng phải có người nhận và cách xử lý.
6. Đưa lỗi đã xác nhận vào bộ kiểm thử
Tạo mẫu tái hiện đã xóa dữ liệu nhạy cảm, rồi thêm vào bộ test hồi quy cho quy trình có AI trước khi phát hành bản sửa.
Lấy mẫu theo rủi ro thay vì chỉ xem tỷ lệ trung bình
Điểm chung có thể tốt dù nhóm yêu cầu quan trọng đang xử lý sai. Hãy giữ mẫu đại diện cho lưu lượng thường ngày và mẫu có chủ đích cho tình huống nhạy cảm hoặc vừa thay đổi.
Quy trình hỗ trợ có thể nhận nhiều câu hỏi về lịch nhưng ít yêu cầu hoàn tiền. Mẫu ngẫu nhiên dễ bỏ qua hoàn tiền, dù nhóm này cần xác minh chính sách và quyền quyết định. Ưu tiên hậu quả hơn tần suất.
Khi nhân viên sửa đầu ra, hãy ghi phần bị sửa và lý do để biết lỗi nằm ở dữ liệu, trạng thái, giọng điệu hay hành động.
Ranh giới giữa hệ thống giám sát và người phụ trách
Hệ thống tự động thực hiện
- Ghi phiên bản cấu hình và đường đi của tác vụ.
- Kiểm tra schema, trường bắt buộc, quyền công cụ và hành động bị cấm.
- Lấy mẫu, gom lỗi cùng nguyên nhân và gửi cảnh báo đúng tuyến.
- Dừng hoặc hạ quyền khi vi phạm điều kiện chặn.
Con người xác nhận
- Đánh giá trường hợp cần hiểu chính sách, ngữ cảnh khách hàng hoặc mức hậu quả.
- Quyết định khôi phục phiên bản, giới hạn phạm vi hoặc tiếp tục theo dõi.
- Sửa dữ liệu và quy trình nghiệp vụ khi nguyên nhân không nằm ở model.
- Chấp thuận việc mở thêm quyền sau khi dữ liệu vận hành đủ ổn định.
Cảnh báo phải dẫn đến cách xử lý đã định nghĩa
Mỗi cảnh báo cần có tác vụ gốc, phiên bản cấu hình, mức ảnh hưởng, hành động đang bị chặn và người có quyền quyết định.
Việc cần xử lý thủ công nên đi vào hàng chờ ngoại lệ, không nằm rải rác trong email. Nếu lỗi lặp lại, hãy xem form, tài liệu, trạng thái CRM và quyền trước khi chỉnh AI.
Không khôi phục phiên bản chỉ vì một chỉ số dao động nhẹ. Lỗi có thể đến từ dữ liệu mới hoặc cách sử dụng. Hãy dựa trên điều kiện đã chốt, nhất là với tiền, quyền truy cập và dữ liệu khách hàng.
Duy trì nhịp xem xét theo tốc độ thay đổi
Sau khi đổi model, prompt, tài liệu hoặc quyền công cụ, đội cần xem mẫu thường xuyên. Khi ổn định, có thể giảm nhịp nhưng vẫn giữ cảnh báo rủi ro cao.
Buổi xem xét tập trung vào lỗi mới và nguyên nhân lặp lại. Đầu ra là quyết định cụ thể: thêm mẫu, sửa dữ liệu, đổi quy tắc, đổi người duyệt hoặc giữ nguyên.
Dịch vụ AI Agent Coaching của Auranium hỗ trợ đội chọn quy trình, đặt tiêu chí chất lượng và xây cơ chế giám sát. Đội cần biết hệ thống sai ở đâu, ai xử lý và điều kiện nào phải chặn.