Khi nào nên dùng AI agent trong dịch vụ khách hàng?

Khách hỏi đơn hàng đang ở đâu. Nhân viên mở trang quản lý, tìm mã, kiểm trạng thái rồi nhắn lại. Mười phút sau, một người khác hỏi gần giống vậy. Trong tình huống giả định của cửa hàng do An phụ trách, nhóm bắt đầu nghĩ tới AI agent. Nhưng câu tiếp theo khó hơn nhiều: nếu khách muốn đổi địa chỉ hoặc hoàn tiền thì hệ thống được làm đến đâu?

AI agent trong dịch vụ khách hàng chỉ đáng thử khi công việc cần làm đã rõ, dữ liệu đủ tin cậy và quyền hành động được giới hạn. Bạn nên chọn một yêu cầu nhỏ có thể kiểm được kết quả. Sau đó mới quyết định có nên mở rộng, dựa trên việc khách thực sự được hỗ trợ ra sao.

Trước hết, vẽ đường đi của một yêu cầu

An lấy một yêu cầu tra đơn làm mẫu. Khách cung cấp thông tin, hệ thống xác định đúng đơn, lấy trạng thái và diễn đạt câu trả lời. Nếu không tìm thấy hoặc thông tin không khớp, yêu cầu được chuyển cho nhân viên. Vẽ các bước ra giấy giúp nhóm thấy phần nào đã có cách làm rõ.

Phân biệt câu trả lời từ dữ liệu có sẵn với hành động làm thay đổi dữ liệu. Đọc trạng thái đơn khác với sửa địa chỉ. Đề xuất hoàn tiền khác với thực hiện hoàn tiền. Nếu gom tất cả thành “hỗ trợ khách”, nhóm rất dễ cấp một quyền rộng hơn nhu cầu ban đầu.

Anthropic phân biệt quy trình định sẵn và agent theo mức linh hoạt trong cách chọn bước làm. Điều này gợi một câu hỏi thực tế: yêu cầu của cửa hàng có thật sự cần hệ thống tự chọn nhiều bước không? Một luồng tra cứu rõ ràng có thể giải quyết bằng cách đơn giản hơn.

An ghi rõ ai chịu trách nhiệm cho từng phần: nguồn trạng thái, quy tắc trả lời và xử lý khi không rõ. Agent không nên trở thành nơi che đi những khoảng trống của quy trình. Nếu hai nhân viên đang trả lời khác nhau vì chính sách chưa thống nhất, cần xử lý chuyện đó trước.

Chọn việc nhỏ mà khách thường phải chờ

Nhóm bắt đầu từ những yêu cầu lặp lại có dữ liệu và câu trả lời kiểm được. Trong ví dụ này, tra trạng thái đơn là một ứng viên. Điều đó không có nghĩa mọi cửa hàng nên chọn cùng việc. Hãy nhìn lịch sử yêu cầu của chính nhóm để biết chỗ khách đang chờ vì thao tác nào.

Đặt phạm vi thử thật cụ thể. Agent chỉ trả lời trạng thái cho loại đơn được hỗ trợ, dựa trên nguồn đã chỉ định. Nó không tự đoán ngày giao khi dữ liệu chưa có. Nếu cần diễn giải trạng thái khó hiểu, nhóm cung cấp cách diễn đạt đã kiểm thay vì để hệ thống tự hứa với khách.

Chuẩn bị vài yêu cầu có thông tin thiếu hoặc sai, không chỉ những câu hỏi đẹp trong buổi demo. Khách có thể gửi nhầm mã, gõ thiếu ký tự hoặc hỏi về đơn của người khác. Quy trình xác minh phải do hệ thống và chính sách truy cập kiểm soát, không dựa vào việc mô hình thấy lời kể nghe có vẻ hợp lý.

Trong giai đoạn đầu, nhân viên có thể xem câu trả lời đề xuất trước khi gửi. Cách đặt người kiểm ở đúng bước giúp nhóm quan sát lỗi với phạm vi nhỏ. Đồng thời ghi công kiểm thực tế, vì phần việc này cũng nằm trong chi phí phục vụ.

Khi nào agent nên dừng và gọi nhân viên?

An lập danh sách tình huống cần chuyển người: dữ liệu mâu thuẫn, không xác định được đơn, khách phản đối thông tin hoặc yêu cầu ngoài phạm vi. Mỗi tình huống có đường chuyển rõ. Câu “vui lòng liên hệ hỗ trợ” chưa đủ nếu khách đang ở chính kênh hỗ trợ và không biết làm gì tiếp.

Khi chuyển, gửi phần tóm tắt đã kiểm cùng dữ liệu liên quan cho nhân viên. Khách không nên phải kể lại mọi thứ chỉ vì hệ thống chạm giới hạn. Tuy nhiên, bản tóm tắt cần phân biệt lời khách cung cấp với thông tin đã tra được. Đừng biến một lời phàn nàn chưa xác minh thành kết luận trong hồ sơ.

Những hành động ảnh hưởng tiền hoặc dữ liệu cần điều kiện riêng. Trong thử nghiệm, An có thể giữ chúng ngoài quyền của agent. Nếu sau này mở thêm quyền, phải thiết kế kiểm tra, phê duyệt và ghi nhận phù hợp trước. Một prompt nhắc “hãy cẩn thận” không thay thế được giới hạn quyền trong phần mềm.

Khách cũng cần biết khi nào họ có thể gặp người hỗ trợ. Cách nói nên ngắn và đúng với khả năng của kênh đang dùng. Không hứa sẽ có nhân viên ngay nếu ngoài giờ và nhóm chưa có người trực. Thông tin chuyển tiếp rõ thường tốt hơn một chuỗi câu xin lỗi lặp lại.

Kiểm tra trước khi cho hệ thống quyền hành động

Nhóm thử bằng dữ liệu và môi trường phù hợp trước khi chạm đơn thật. Mỗi trường hợp ghi kết quả mong đợi, quyền được dùng và điều buộc phải dừng. Sau đó kiểm xem agent có lấy đúng dữ liệu, trả lời đúng và tôn trọng giới hạn hay không.

Thử cả lời nhắn cố yêu cầu bỏ qua quy tắc. Nội dung khách gửi là dữ liệu cần xử lý, không phải quyền để thay đổi cách hệ thống hoạt động. Bài về prompt injection giải thích vì sao việc tách chỉ dẫn và nội dung bên ngoài cần được xem xét ngay từ thiết kế.

Với thao tác có thể lặp lại, kiểm trường hợp khách bấm gửi hai lần hoặc hệ thống nhận lại cùng yêu cầu. Nhóm kỹ thuật cần bảo đảm cách xử lý phù hợp với hành động đó. Không nên để một lần thử lại vô tình tạo thêm yêu cầu hoặc thay đổi dữ liệu ngoài ý muốn.

Giữ ghi nhận đủ để điều tra lỗi theo quyền truy cập thích hợp. Cần biết yêu cầu nào dẫn tới nguồn dữ liệu và hành động nào. Đồng thời tránh gom thông tin riêng không cần thiết chỉ vì muốn lưu mọi thứ. Phần ghi log cũng cần người phụ trách và cách sử dụng rõ.

Đo xem khách có được phục vụ tốt hơn không

Thời gian trả lời nhanh chỉ là một phần. An còn xem câu trả lời có giải quyết đúng yêu cầu không, khách có phải hỏi lại không và có bị chuyển vòng quanh không. Một câu trả lời xuất hiện ngay nhưng sai đơn sẽ không giúp trải nghiệm tốt hơn.

So cùng loại yêu cầu trước và trong đợt thử, ghi rõ phạm vi. Nếu agent chỉ nhận câu dễ còn nhân viên xử lý câu khó, không thể nhìn số trung bình rồi kết luận bên nào tốt hơn. Cách đo hiệu quả AI cần tính cả công kiểm, sửa và xử lý sự cố.

Ai theo dõi agent sau khi đưa vào dùng?

Mỗi thay đổi nguồn dữ liệu hoặc quy tắc có thể ảnh hưởng câu trả lời. An chọn người phụ trách xem lỗi, cập nhật hướng dẫn và quyết định tạm dừng khi cần. Có nút dừng và cách chuyển về quy trình cũ sẽ giúp nhóm xử lý chủ động hơn.

Trong ví dụ này, thành công ban đầu có thể chỉ là giúp khách tra đúng trạng thái mà ít chờ hơn, với các trường hợp khó được chuyển rõ ràng. Đó đã là một mục tiêu đáng thử. Mở rộng quyền nên theo những gì nhóm đã kiểm chứng, từng việc một, thay vì theo cảm giác agent đang nói chuyện rất tự nhiên.