Định tuyến yêu cầu bằng AI là việc dùng trí tuệ nhân tạo để hiểu yêu cầu viết tự do của người dùng rồi đưa họ tới đúng bộ phận, đúng biểu mẫu hoặc đúng quy trình, thay vì bắt họ tự biết mình cần tìm ở đâu. Nó giải quyết bài toán người hỏi không biết đặt câu hỏi cho ai, chứ không chỉ bài toán trả lời câu hỏi.
Ngày 3 tháng 10 năm 2026, chính quyền Mỹ đưa vào thử nghiệm America.gov, dịch vụ dùng các mô hình AI để giúp người dân tìm thông tin và thực hiện các thủ tục công. Người dùng mô tả nhu cầu bằng ngôn ngữ tự nhiên thay vì phải biết chính xác cơ quan hoặc biểu mẫu nào phụ trách. Bản tin cũng lưu ý rằng giá trị của AI trong dịch vụ công phụ thuộc vào việc thông tin có cập nhật và có phù hợp với từng trường hợp hay không. Bài này rút phần áp dụng được cho doanh nghiệp.
Vì sao khách không biết hỏi ai lại là vấn đề của doanh nghiệp?
Vì chi phí của việc đó đổ hết về phía doanh nghiệp, chỉ là nó không xuất hiện thành một dòng trong báo cáo nào nên ít khi được tính.
Khi một khách hàng gửi yêu cầu vào nhầm kênh hoặc nhầm bộ phận, chuỗi việc phát sinh gồm: người nhận đọc rồi chuyển tiếp, người tiếp theo đọc lại từ đầu, khách phải kể lại câu chuyện lần hai, và thời gian xử lý kéo dài thêm vài giờ tới vài ngày. Với doanh nghiệp nhận vài chục yêu cầu mỗi ngày, phần hao hụt này cộng dồn thành khối lượng công việc đáng kể.
Nguyên nhân gốc thường không phải khách hàng thiếu hợp tác, mà là cách doanh nghiệp tổ chức thông tin phản ánh sơ đồ phòng ban của mình chứ không phản ánh cách khách mô tả vấn đề. Khách nói rằng hàng về bị móp, còn doanh nghiệp chia thành bộ phận vận chuyển, bộ phận đổi trả và bộ phận chất lượng.
Định tuyến khác trả lời câu hỏi ở chỗ nào?
Hai việc này hay bị gộp làm một khi doanh nghiệp triển khai trợ lý ảo, và việc gộp đó làm cả hai cùng kém đi. Tách rõ ra giúp đặt kỳ vọng và đo lường đúng.
| Tiêu chí | Trả lời câu hỏi | Định tuyến yêu cầu |
|---|---|---|
| Kết quả mong muốn | Khách có thông tin cần tìm | Khách tới đúng nơi xử lý được việc |
| Cần dữ liệu gì | Tài liệu nội dung đầy đủ | Bản đồ quy trình và phân công |
| Hậu quả khi sai | Khách nhận thông tin sai | Khách mất thêm một vòng chờ |
| Đo bằng | Tỷ lệ trả lời đúng | Tỷ lệ chuyển đúng ngay lần đầu |
| Mức khó | Cao, cần nội dung chính xác | Thấp hơn, chỉ cần phân loại đúng |
Hàng cuối là tin tốt cho doanh nghiệp mới bắt đầu. Phân loại một yêu cầu vào đúng nhóm dễ hơn nhiều so với việc trả lời đúng nội dung yêu cầu đó, nên định tuyến là chỗ nên triển khai trước nếu bạn muốn thấy kết quả sớm mà rủi ro thấp.
Dữ liệu cập nhật quan trọng hơn mô hình ở chỗ nào?
Một hệ thống định tuyến chạy trên sơ đồ phân công đã lỗi thời sẽ chuyển yêu cầu tới một bộ phận không còn phụ trách việc đó, và cách diễn đạt trôi chảy của nó làm người dùng tin rằng mình đã được hướng dẫn đúng.
Đây là dạng lỗi khó phát hiện nhất vì hệ thống không báo lỗi. Yêu cầu vẫn được tiếp nhận, vẫn có người trả lời, chỉ là người đó không phải người xử lý được việc. Khách hàng chịu thêm một vòng chờ, còn báo cáo nội bộ vẫn ghi nhận là đã tiếp nhận thành công.
Cách phòng là gắn chu kỳ rà soát bản đồ định tuyến vào đúng nhịp thay đổi tổ chức của doanh nghiệp, chứ không rà theo lịch cố định. Mỗi lần có người mới, người nghỉ, đổi phân công hoặc thêm dòng sản phẩm thì bản đồ cần được cập nhật trong cùng tuần đó.
Dựng bản đồ yêu cầu của doanh nghiệp thế nào?
Bản đồ này là tài sản quan trọng hơn cả công cụ, và nó dựng được từ dữ liệu bạn đã có mà không cần phỏng đoán.
- Lấy hai trăm yêu cầu gần nhất. Từ hộp thư, tin nhắn và nhật ký cuộc gọi, không lọc trước.
- Nhóm theo cách khách mô tả, không theo phòng ban. Đây là bước quan trọng nhất và cũng dễ làm sai nhất.
- Đếm số lượng mỗi nhóm. Thường vài nhóm đầu chiếm phần lớn khối lượng, và đó là nơi đáng tự động hoá trước.
- Ghi rõ ai xử lý và cần thông tin gì. Mỗi nhóm cần biết đích đến và các trường dữ liệu phải thu thập ngay từ đầu.
- Đánh dấu nhóm cần người thật ngay. Khiếu nại, sự cố khẩn, yêu cầu liên quan tới tiền.
Bước bốn có giá trị vượt ngoài việc định tuyến. Khi bạn biết mỗi nhóm yêu cầu cần những thông tin gì, hệ thống có thể hỏi đủ ngay từ lượt đầu, và người xử lý không phải quay lại hỏi thêm. Riêng việc này thường rút ngắn thời gian xử lý nhiều hơn phần định tuyến.
Khi yêu cầu không khớp nhóm nào thì xử lý ra sao?
Đây là tình huống quyết định chất lượng của cả hệ thống, vì cách xử lý nhóm còn lại phản ánh triết lý thiết kế rõ hơn cách xử lý nhóm phổ biến.
Lựa chọn sai là ép yêu cầu vào nhóm gần đúng nhất. Khi đó hệ thống đạt chỉ số phân loại cao nhưng khách bị đẩy tới sai chỗ, và chi phí của sai sót này cao hơn hẳn chi phí của việc thừa nhận không phân loại được.
Lựa chọn đúng là có một nhóm dành riêng cho các yêu cầu không rõ, chuyển thẳng cho người thật, và ghi lại chúng thành danh sách. Danh sách đó chính là nguồn để mở rộng bản đồ ở lần cập nhật sau, nên nó là dữ liệu có giá trị chứ không phải dấu hiệu thất bại.
Đo chất lượng định tuyến bằng chỉ số nào?
Bốn chỉ số dưới đây lấy được từ chính hệ thống tiếp nhận yêu cầu, và chúng đo đúng thứ khách hàng cảm nhận được.
| Chỉ số | Ý nghĩa |
|---|---|
| Tỷ lệ chuyển đúng ngay lần đầu | Chỉ số chính, đo trực tiếp mục đích của hệ thống |
| Số lần một yêu cầu bị chuyển tiếp | Mỗi lần chuyển là một vòng chờ cho khách |
| Tỷ lệ yêu cầu không phân loại được | Nên có, nếu bằng không thì hệ thống đang ép nhóm |
| Số trường thông tin phải hỏi lại | Đo chất lượng của bước thu thập ban đầu |
Chỉ số thứ ba cần được đọc ngược với trực giác thông thường. Một hệ thống báo rằng nó không phân loại được khoảng một phần mười số yêu cầu thường đáng tin hơn một hệ thống báo rằng nó phân loại được tất cả. Lý do tương tự như cách đánh giá các nhãn tự động khác, được bàn trong bài nhãn đã kiểm chứng bởi AI đáng tin tới đâu.
Vì sao nên nói rõ hệ thống đang ở giai đoạn thử nghiệm?
Dịch vụ America.gov được công bố rõ là đang trong giai đoạn thử nghiệm và chưa có đầy đủ thông tin về độ chính xác. Cách làm này đáng học, và lý do mang tính vận hành chứ không chỉ là sự trung thực.
Khi người dùng biết hệ thống đang chạy thử, họ phản hồi khi thấy sai thay vì âm thầm bỏ đi, và chính những phản hồi đó là nguồn dữ liệu để sửa. Ngược lại, một hệ thống được giới thiệu như đã hoàn chỉnh sẽ nhận được ít phản hồi hơn, trong khi số lỗi thì không ít đi.
Cách làm gọn là một dòng ngắn ở đầu, kèm một nút gửi phản hồi luôn hiển thị. Không cần xin lỗi trước hay giải thích dài, chỉ cần nói rõ và cho người dùng đường báo lại.
Định tuyến tốt tiết kiệm được bao nhiêu?
Phần tiết kiệm của việc định tuyến đúng thường bị đánh giá thấp vì nó phân tán ra nhiều người và không hiện thành một khoản chi nào. Công thức dưới đây cho bạn một con số để so với chi phí triển khai.
Lấy số yêu cầu nhận mỗi tháng nhân với tỷ lệ đang bị chuyển nhầm, ra số lượt chuyển nhầm. Mỗi lượt chuyển nhầm tốn thời gian của ít nhất hai người: người nhận đầu tiên đọc rồi chuyển, và người tiếp theo đọc lại từ đầu. Nhân số lượt với tổng thời gian đó rồi quy ra tiền theo chi phí nhân sự, bạn có phần tiết kiệm trực tiếp.
Nhưng phần lớn giá trị lại nằm ở khoản không tính được bằng cách trên: thời gian chờ của khách hàng. Một yêu cầu bị chuyển hai lần có thể kéo dài từ nửa ngày thành hai ngày, và với các tình huống khách đang cân nhắc mua hoặc đang bực bội thì độ trễ đó quyết định kết quả nhiều hơn chất lượng câu trả lời cuối cùng.
Vì vậy nên đo thêm một chỉ số nữa song song: thời gian từ lúc khách gửi yêu cầu tới lúc người xử lý được việc thật sự bắt đầu xử lý. Con số này thường gây bất ngờ hơn mọi con số khác trong báo cáo chăm sóc khách hàng.
Những sai lầm nào hay gặp khi triển khai?
Năm sai lầm dưới đây xuất hiện ở phần lớn lần triển khai đầu tiên, và cả năm đều phòng được bằng quyết định từ giai đoạn thiết kế.
- Dựng bản đồ theo sơ đồ phòng ban. Khách không biết và không cần biết doanh nghiệp chia bộ phận thế nào.
- Bắt khách chọn từ danh sách dài. Nếu vẫn bắt chọn menu nhiều lớp thì công cụ chưa giải quyết được gì.
- Không có đường tới người thật. Luôn cần, và không nên ẩn sau nhiều lượt hội thoại.
- Triển khai cùng lúc cho mọi loại yêu cầu. Nên bắt đầu từ ba nhóm phổ biến nhất rồi mở rộng.
- Không ai phụ trách cập nhật bản đồ. Hệ thống sẽ xuống cấp lặng lẽ trong vài tháng.
Sai lầm cuối cùng là sai lầm làm hỏng nhiều dự án nhất, vì nó không gây hậu quả ngay mà tích tụ dần. Cách phòng là gán việc cập nhật cho một vai trò cụ thể và đưa nó vào danh sách công việc định kỳ như các việc vận hành khác. Cách tổ chức tiếp nhận yêu cầu trên nhiều kênh được bàn trong bài chăm sóc khách hàng đa kênh.
Bước tiếp theo nên làm gì?
Việc nên làm trong tuần này là lấy hai trăm yêu cầu gần nhất và nhóm chúng theo cách khách mô tả. Kết quả thường cho thấy ba tới năm nhóm chiếm phần lớn khối lượng, và đó là phạm vi đủ nhỏ để triển khai thử mà vẫn tạo ra khác biệt đo được.
Song song, hãy đếm xem trung bình một yêu cầu bị chuyển tiếp bao nhiêu lần trước khi tới đúng người. Con số này là mốc so sánh cho mọi cải tiến về sau.
Cách dựng một hệ thống tiếp nhận có phân loại, có thu thập đủ thông tin từ lượt đầu và có quy tắc chuyển người thật được trình bày trong giải pháp chăm sóc khách hàng bằng AI.
Đội ngũ InCard có thể cùng bạn dựng bản đồ yêu cầu từ dữ liệu thật và chỉ ra nhóm nào nên tự động hoá trước. Bạn có thể đặt lịch demo để làm việc này trên chính hộp thư của mình.
