Tự động phân loại và ưu tiên yêu cầu khách hàng bằng AI
Playbook giúp đội sales và CSKH xác định ý định, mức độ khẩn và nhóm xử lý phù hợp cho yêu cầu khách hàng, từ đó thử nghiệm AI phân luồng có kiểm soát trước khi tự động hóa.
Khách hỏi báo giá, báo lỗi không đăng nhập được và phàn nàn về đơn hàng có thể cùng xuất hiện trong một buổi. Nếu đội chỉ xử lý theo thứ tự tin đến, một yêu cầu cần can thiệp sớm có thể bị xếp sau những câu hỏi đơn giản.
Giải pháp là biến inbox thành hàng đợi có phân loại và ưu tiên: AI đọc nội dung, xác định khách đang cần gì, đánh giá các tiêu chí đã định nghĩa và đề xuất chuyển đến đúng nhóm. Nhân viên vẫn kiểm tra, quyết định và xử lý yêu cầu.
Ticket routing là gì?
Ticket routing là phân loại rồi chuyển yêu cầu khách hàng đến đúng người hoặc nhóm phụ trách. Với đội sales và CSKH, “ticket” có thể là email, tin nhắn, nội dung biểu mẫu hoặc ghi chú từ cuộc gọi đã được nhập vào hệ thống.
Theo tài liệu của Anthropic, mô hình ngôn ngữ lớn có thể phù hợp hơn cách phân loại truyền thống khi:
Đội có ít dữ liệu đã gắn nhãn.
Danh mục yêu cầu thay đổi theo sản phẩm hoặc nhu cầu khách hàng.
Nội dung khách gửi là văn bản tự do, không có cấu trúc cố định.
Quy tắc phân loại cần hiểu ngữ nghĩa và ngữ cảnh, thay vì chỉ dò từ khóa.
Đội cần lý do dễ đọc để kiểm tra quyết định phân loại.
Có nhiều trường hợp mơ hồ hoặc nhiều ngôn ngữ.
Ví dụ, hai khách đều nói “cần hỗ trợ ngay”, nhưng hướng xử lý có thể khác:
Khách cần báo giá để trình duyệt: chuyển đến sales/báo giá.
Khách không truy cập được tài khoản: chuyển đến quản lý tài khoản hoặc kỹ thuật.
Khách báo đơn giao sai: chuyển đến đơn hàng hoặc khiếu nại.
Điểm quan trọng không phải để AI thay người trả lời, mà là giúp đội nhìn rõ yêu cầu nào thuộc ai và yêu cầu nào cần được xem sớm.
Bước 1: Hiểu cách đội đang chia việc
Trước khi đưa AI vào quy trình, hãy xem đội hiện phân luồng ticket như thế nào. Càng hiểu rõ cách nhân viên xử lý các tình huống thực tế, bạn càng dễ định nghĩa quy tắc cho hệ thống.
Hãy cùng quản lý sales, CSKH và vận hành trả lời các câu hỏi:
Tiêu chí nào quyết định SLA hoặc mức dịch vụ áp dụng?
Ticket được chuyển đến tuyến hỗ trợ, chuyên gia sản phẩm hay bộ phận nào?
Quy tắc tự động hiện có là gì và thường sai ở đâu?
Đội đang xử lý các ca mơ hồ như thế nào?
Những yếu tố nào ảnh hưởng đến thứ tự ưu tiên?
Khách hàng, SLA hoặc ngôn ngữ có làm thay đổi nơi nhận ticket không?
SLA là cam kết về mức dịch vụ, chẳng hạn thời hạn phản hồi hoặc xử lý. AI chỉ nên đề xuất ưu tiên sau khi đội đã thống nhất tiêu chí thế nào là bình thường, cần sớm hoặc khẩn.
Bước 2: Định nghĩa danh mục rõ ràng
Chất lượng phân luồng phụ thuộc trực tiếp vào độ rõ ràng của các nhãn. Danh mục càng mơ hồ, AI và cả nhân viên càng khó đưa ra quyết định nhất quán.
Tài liệu đưa ra các nhóm ý định tham khảo:
| Nhóm ý định | Ví dụ |
|---|---|
| Vấn đề kỹ thuật | Lỗi phần mềm, khả năng tương thích, hiệu năng |
| Quản lý tài khoản | Đặt lại mật khẩu, vấn đề truy cập tài khoản |
| Thanh toán | Hỏi về hóa đơn, thay đổi gói dịch vụ |
| Thông tin sản phẩm | Tính năng, giá, khả năng đáp ứng |
| Hướng dẫn sử dụng | Cách dùng, khắc phục sự cố, thực hành tốt |
| Phản hồi | Báo lỗi, đề xuất tính năng, góp ý |
| Khiếu nại | Phản ánh về sản phẩm hoặc dịch vụ |
| Đơn hàng | Trạng thái đơn, giao hàng, đổi trả, thay đổi đơn |
| Yêu cầu dịch vụ | Cài đặt, nâng cấp, bảo trì, hủy dịch vụ |
| Bảo mật | Quyền riêng tư dữ liệu, hoạt động đáng ngờ |
| Pháp lý và tuân thủ | Điều khoản, tài liệu pháp lý, câu hỏi quy định |
| Hỗ trợ khẩn | Sự cố nghiêm trọng hoặc vấn đề nhạy cảm về thời gian |
| Tích hợp và API | Hỗ trợ tích hợp, sử dụng API, tương thích bên thứ ba |
Không cần dùng toàn bộ danh mục này. Đội nên chọn các nhãn sát với công việc thực tế và viết mô tả ngắn cho từng nhãn.
Ngoài ý định, việc phân luồng có thể xét thêm:
Mức độ khẩn.
Loại khách hàng.
SLA áp dụng.
Ngôn ngữ.
Nhóm hoặc chuyên gia cần tiếp nhận.
Bước 3: Thiết kế đầu ra để nhân viên có thể hành động
Thay vì yêu cầu AI viết nhận xét dài, hãy yêu cầu đầu ra theo cấu trúc cố định. Nhân viên sẽ dễ kiểm tra và chuyển ticket hơn.
Bạn có thể dùng mẫu sau trong công cụ AI nội bộ hoặc trong luồng kết nối với hệ thống ticket/CRM:
text
Bạn là trợ lý phân loại yêu cầu khách hàng.
Đọc nội dung dưới đây và chỉ trả về theo mẫu:
Ý định: <một nhãn trong danh sách>
Nhóm xử lý: <một nhóm trong danh sách>
Độ khẩn: <bình thường/cần sớm/khẩn>
Cần người xem lại: <có/không>
Lý do: <một câu ngắn>
Thông tin còn thiếu: <nếu có>
Quy tắc:
Chỉ phân loại và đề xuất chuyển nhóm; không soạn câu trả lời gửi khách.
Chỉ dùng các nhãn và nhóm xử lý được cung cấp.
Nếu nội dung mơ hồ, nêu rõ thông tin còn thiếu thay vì tự suy đoán.
Với các yêu cầu về bảo mật, pháp lý, sự cố nghiêm trọng hoặc nhạy cảm về thời gian,
đánh dấu “Cần người xem lại: có”.
Danh sách ý định:
<hỏi giá/báo giá/thông tin sản phẩm/theo dõi đơn/đổi trả/thanh toán/
lỗi kỹ thuật/quản lý tài khoản/khiếu nại/bảo mật/pháp lý/khác>
Danh sách nhóm xử lý:
<sales/CSKH/kỹ thuật/kế toán/giao nhận/quản lý>
Nội dung khách gửi:
<dán nội dung đã được giảm bớt dữ liệu không cần thiết>
Mẫu này không thay thế quy trình nội bộ. Nó biến nội dung tự do thành thông tin mà nhân viên có thể rà soát trước khi tạo hoặc chuyển ticket.
Ví dụ: phân luồng yêu cầu báo giá
Giả sử khách gửi:
text
Bên tôi cần báo giá cho <sản phẩm> để trình duyệt.
Nếu có chính sách cho đại lý thì gửi giúp.
Một kết quả phân loại có thể là:
text
Ý định: báo giá
Nhóm xử lý: sales
Độ khẩn: bình thường
Cần người xem lại: có
Lý do: Khách yêu cầu báo giá và hỏi về chính sách dành cho đại lý.
Thông tin còn thiếu: số lượng dự kiến, địa điểm giao, thời hạn cần báo giá
Nhân viên sales nhận ticket có thể hỏi thêm các thông tin còn thiếu trước khi lập báo giá. Việc kiểm tra giá, điều kiện bán hàng và chính sách hiện hành vẫn thuộc trách nhiệm của người phụ trách.
Với một khiếu nại như:
text
Đơn của tôi giao không đúng như tư vấn. Tôi đã chờ rất lâu mà chưa ai giải quyết.
Hệ thống có thể gợi ý ý định khiếu nại hoặc đơn hàng, chuyển đến nhóm phù hợp và yêu cầu người phụ trách xem lại. AI có thể hỗ trợ tóm tắt nội dung, nhưng không nên tự kết luận trách nhiệm hay đưa ra cam kết với khách.
Bước 4: Kiểm thử trước khi tự động chuyển ticket
Đừng đánh giá hệ thống bằng vài ví dụ có vẻ đúng. Hãy dùng một tập ticket lịch sử đã được người có kinh nghiệm phân loại để kiểm tra kết quả.
Các tiêu chí nên theo dõi gồm:
Tính nhất quán: Ticket tương tự có được gắn nhãn ổn định theo thời gian không?
Khả năng thích nghi: Khi có loại yêu cầu mới, đội có thể cập nhật định nghĩa nhãn và kiểm tra lại hay không?
Xử lý đa ngôn ngữ: Độ chính xác có thay đổi đáng kể giữa các ngôn ngữ không?
Ca khó: AI xử lý thế nào với ticket mơ hồ, nhiều vấn đề trong một tin hoặc nội dung bất thường?
Thiên lệch: Các nhóm khách hàng khác nhau có nhận kết quả phân luồng nhất quán không?
Khả năng giải thích: Người nhận ticket có hiểu lý do AI đề xuất phân loại đó không?
Tài liệu nêu một số mốc tham khảo để thiết kế đánh giá: tính nhất quán từ 95% trở lên, độ chính xác ít nhất 80% cho các ca khó, và chênh lệch độ chính xác giữa các nhóm khách hàng trong khoảng 2–3%. Đây là mục tiêu tham khảo cho việc đo lường, không phải kết quả được bảo đảm cho mọi hệ thống.
Ở giai đoạn đầu, nên để AI gắn nhãn và đề xuất; nhân viên xác nhận trước khi chuyển việc. Chỉ nên cân nhắc tự động chuyển các trường hợp đơn giản khi kết quả kiểm thử cho thấy quy trình đủ ổn định.
Những ca nên có người xem lại
AI có thể hỗ trợ sắp xếp công việc, nhưng các trường hợp sau nên được nhân viên kiểm tra:
Khiếu nại cần xử lý cẩn trọng.
Vấn đề bảo mật hoặc báo cáo hoạt động đáng ngờ.
Câu hỏi pháp lý, điều khoản hoặc tài liệu pháp lý.
Sự cố nghiêm trọng hoặc vấn đề nhạy cảm về thời gian.
Nội dung mơ hồ, thiếu thông tin hoặc có nhiều yêu cầu lẫn nhau.
Các yêu cầu cần áp dụng chính sách, điều kiện dịch vụ hoặc thẩm quyền phê duyệt.
Khi thử nghiệm với ticket lịch sử hoặc đưa nội dung vào công cụ AI, chỉ nên cung cấp thông tin cần thiết cho việc phân loại. Có thể thay dữ liệu định danh bằng các biến như <mã khách>, <số đơn> hoặc <sản phẩm>.
Checklist triển khai
[ ] Đã thống nhất danh mục ý định và mô tả cho từng nhãn.
[ ] Đã xác định nhóm nhận việc, tiêu chí ưu tiên, SLA và các trường hợp cần xem lại.
[ ] Prompt yêu cầu AI chỉ dùng nhãn có sẵn, nêu lý do và thông tin còn thiếu.
[ ] Đã kiểm thử bằng ticket lịch sử được chuẩn bị cho mục đích đánh giá.
[ ] Có người chịu trách nhiệm xem các ticket thuộc nhóm “khác” hoặc “mơ hồ”.
[ ] Đã đo tính nhất quán, khả năng xử lý ca khó và kết quả theo ngôn ngữ hoặc nhóm khách hàng.
[ ] Chỉ tự động hóa từng phần sau khi quy trình đã được kiểm tra.
Một inbox tốt không nhất thiết ít tin hơn. Đó là inbox giúp mỗi người biết yêu cầu nào thuộc mình, việc nào cần xử lý trước và việc nào cần được con người xem xét kỹ.