Cách biến phản hồi của nhân viên bán hàng thành bản sửa AI

Người vận hành không biết vấn đề nằm ở giọng nói, dữ kiện, nhu cầu hay quyền. Một người muốn ngắn hơn, người khác muốn giải thích thêm. Nếu gom tất cả thành yêu cầu chung, lần sửa sau có thể làm người này hài lòng nhưng gây lỗi cho người khác.

Hiểu lầm ở đây là nhân viên bấm không thích thì hệ thống sẽ tự hiểu và học đúng. Không nên giả định phản hồi tự thay đổi mô hình hay quy tắc. Đội ngũ cần biết phản hồi đi đến ai, được dùng ra sao và khi nào có kết luận.

Dùng một phiếu gồm đoạn đang có vấn đề, bối cảnh tối thiểu, nguồn dùng để đối chiếu và kết quả mong muốn. Không chép cả hồ sơ khách nếu chỉ cần kiểm một thông số sản phẩm. Che hoặc bỏ thông tin riêng không phục vụ việc sửa.

Ví dụ giả định: bản nháp gọi túi là chống nước, nhưng tài liệu chỉ nói chống bám nước nhẹ. Góp ý tốt chỉ đúng câu, dẫn đoạn nguồn và đề nghị bỏ lời khẳng định mạnh. Góp ý “viết tự nhiên hơn” không chỉ ra rủi ro này.

Nếu lỗi chỉ thuộc một hồ sơ, sửa dữ kiện của hồ sơ đó theo quyền. Nếu tài liệu nguồn sai, người giữ tài liệu phải xác nhận bản đúng. Nếu nguồn đúng nhưng AI vẫn hành xử sai, mới xem luật tạo câu, cách truy nguồn hoặc điều kiện chuyển người.

Một ngoại lệ được duyệt cho khách cụ thể không trở thành chính sách cho mọi người. Trước khi sửa quy tắc chung, người phụ trách phải ghi rõ phạm vi áp dụng và trường hợp không áp dụng.

Nhân viên gửi phiếu; người phụ trách phân loại; người có quyền duyệt cách sửa; người cấu hình thay đúng phần; người kiểm thử đối chiếu kết quả. Cuối cùng, người góp ý nhận phản hồi về điều đã sửa hoặc lý do chưa sửa.

Microsoft Research khuyến nghị hỗ trợ người dùng sửa lỗi và góp ý cụ thể. Trong shop, có thể áp dụng bằng một hàng chờ sửa ngắn, nhìn thấy người nhận và trạng thái. Đây là phương pháp đề xuất, không phải cam kết tính năng ATECH.

Chạy lại tình huống đã lỗi, một cách diễn đạt khác cùng ý và một tình huống gần giống nhưng cần đáp án khác. Ví dụ sửa cách mô tả khả năng chống nước của túi không được làm hệ thống bỏ mọi thông tin chăm sóc sản phẩm.

Lưu bản trước và sau, nguồn dùng, kết quả mong đợi và người xác nhận. Nếu lỗi cũ hết nhưng hệ thống bắt đầu tự hứa đổi trả, bản sửa chưa đạt. Nên trả về cấu hình đã biết hoặc giới hạn lại phần bị ảnh hưởng, rồi kiểm tiếp.

Khi thử Nhân sự số, Nhân viên số của A Tech Economy, đội bán hàng nên thống nhất một nơi nhận góp ý và một người chốt thay đổi. Cần xác minh công cụ đang dùng có lưu, phân loại và theo dõi phản hồi theo cách mong muốn hay không.

Con người đặt mục tiêu, cấp quyền, duyệt ngoại lệ và chịu trách nhiệm cuối. Đo số góp ý đã có kết luận, lỗi lặp lại và thời gian sửa theo mức ảnh hưởng. Không lấy số góp ý ít làm bằng chứng AI tốt: cũng có thể nhân viên không biết gửi hoặc thấy gửi không được hồi đáp.