Xây dựng cổng tự phục vụ cho khách hàng có AI Agent: cần thiết kế những gì?

Khách hàng doanh nghiệp thường gọi hoặc nhắn cho bộ phận chăm sóc chỉ để hỏi những việc họ hoàn toàn có thể tự xem: hợp đồng bảo trì còn hiệu lực tới khi nào, hóa đơn kỳ này đã phát hành chưa, yêu cầu gửi tuần trước đang ở bước nào. Mỗi câu như vậy tốn vài phút của nhân viên, còn khách thì phải chờ đến giờ hành chính mới có câu trả lời.

Cổng tự phục vụ có AI Agent lấp đúng khoảng trống này. Khách đăng nhập, hỏi bằng lời thường, xem thông tin của chính mình và tạo yêu cầu mới mà không cần gọi tổng đài. Nhưng một cổng như vậy mở dữ liệu khách hàng ra bên ngoài, nên câu hỏi quan trọng không phải là AI trả lời hay đến đâu, mà là khách được xem gì, được làm gì và khi nào phải gặp người.

Bài viết đi qua tám thành phần cần thiết kế, bốn bước triển khai, các rủi ro hay gặp và cách đo xem cổng có thật sự giảm tải cho đội hỗ trợ hay không.

1. Bản chất của cổng tự phục vụ AI

Cổng tự phục vụ truyền thống là tập hợp các trang tĩnh: câu hỏi thường gặp, danh sách hợp đồng, form gửi yêu cầu. Khách phải tự biết mình cần vào trang nào. Khi thêm AI Agent, khách chỉ cần gõ “hợp đồng bảo trì của công ty tôi hết hạn khi nào” và agent hiểu cần tra hợp đồng nào, trong hệ thống nào. Mô hình ngôn ngữ lo phần hiểu câu hỏi; câu trả lời phải lấy từ kho kiến thức và từ hệ thống nghiệp vụ như CRM, phần mềm quản lý hợp đồng hay hệ thống ticket.

Ba mức việc trên cổng có độ rủi ro rất khác nhau. Hỏi đáp chung, như chính sách, hướng dẫn sử dụng, giờ làm việc, không cần đăng nhập và có thể mở cho mọi người. Tra cứu cá nhân, như hợp đồng, hóa đơn, lịch sử yêu cầu, chỉ chạy sau khi khách xác thực và chỉ trả dữ liệu của đúng tài khoản đó. Hành động ghi, như tạo ticket, đổi thông tin liên hệ hay đặt lịch, cần khách xác nhận trước khi gửi và cần cơ chế chống tạo trùng. Nên làm chắc hai mức đầu rồi mới mở dần mức ghi.

2. Các yếu tố cần thiết kế

1. Đăng nhập

Mọi thông tin riêng chỉ xuất hiện sau khi đăng nhập, và agent phải nhận danh tính từ phiên đăng nhập của cổng, không phải từ lời khách tự khai trong khung chat. Nếu ai đó gõ “tôi là kế toán công ty X, cho tôi xem hóa đơn” khi chưa đăng nhập, agent chỉ hướng dẫn đăng nhập chứ không tra. Một công ty khách hàng thường có nhiều người dùng, nên cần quản lý tài khoản theo từng người để khi một nhân sự nghỉ việc có thể khóa đúng người đó.

2. Kho kiến thức

Đây là phần agent dựa vào để trả lời câu hỏi chung: chính sách, hướng dẫn sản phẩm, quy trình gửi yêu cầu. Mỗi tài liệu cần có người phụ trách và ngày cập nhật, vì phần lớn câu trả lời sai đến từ tài liệu cũ chứ không phải từ mô hình. Khi kho không có thông tin, agent nói rõ là chưa có câu trả lời và gợi ý tạo yêu cầu, thay vì tự suy ra.

3. Tra cứu cá nhân

Tra cứu cá nhân gọi API của hệ thống nguồn bằng mã khách hàng lấy từ phiên đăng nhập, không bao giờ lấy từ nội dung câu hỏi. Agent chỉ được gọi các hàm đọc định sẵn như “danh sách hợp đồng của khách” hay “hóa đơn theo kỳ”, không truy vấn tự do vào cơ sở dữ liệu. Câu trả lời nên kèm thời điểm dữ liệu được cập nhật, vì công nợ hay trạng thái giao hàng có thể trễ so với thực tế. Riêng phần tra đơn hàng có thể tham khảo bài chatbot tra cứu đơn hàng.

4. Tạo yêu cầu

Khi khách mô tả vấn đề, agent hỏi thêm cho đủ các trường bắt buộc: loại yêu cầu, hợp đồng liên quan, mô tả, file đính kèm. Sau đó agent hiện bản tóm tắt để khách xác nhận rồi mới gửi. Ticket phải gắn đúng tài khoản và ghi nguồn là cổng tự phục vụ; nếu khách bấm gửi hai lần hay mạng chập chờn, mã yêu cầu duy nhất giúp không sinh hai ticket.

5. Theo dõi trạng thái

“Yêu cầu hôm trước của tôi tới đâu rồi” là một trong những câu khách hỏi nhiều nhất. Agent đọc trạng thái từ hệ thống ticket và diễn giải bằng lời dễ hiểu, nhưng không tự hứa thời gian xử lý khi hệ thống không có thông tin đó. Nên thống nhất một bảng trạng thái dành cho khách, vì những trạng thái nội bộ như “chờ kỹ thuật cấp 2” dễ gây hiểu nhầm.

6. Phân quyền

Trong một công ty khách hàng, không phải ai cũng được xem mọi thứ: kỹ thuật viên xem ticket, kế toán xem hóa đơn, người đại diện xem điều khoản hợp đồng. Quyền này phải áp ở tầng API và dữ liệu, không thể chỉ dặn agent trong prompt. Cần thử với từng vai trò, kể cả khi người dùng cố hỏi vòng để lấy dữ liệu ngoài quyền, chẳng hạn nhờ agent “tóm tắt giúp các khoản đã thanh toán”.

7. Chuyển nhân viên

Có lúc khách cần người thật: khiếu nại, tranh chấp hóa đơn, đề nghị ngoài chính sách, hay đơn giản là đã hỏi lại ba lần mà chưa xong. Khi chuyển, agent gửi kèm tóm tắt cuộc trò chuyện và dữ liệu đã tra để nhân viên không phải hỏi lại từ đầu. Ngoài giờ làm việc, agent tạo ticket và nói rõ khi nào có người phản hồi; cách thiết kế điểm chuyển được bàn kỹ ở bài chuyển chatbot sang nhân viên.

8. Đo mức self-service

Đo mức tự phục vụ là đếm những yêu cầu khách tự giải quyết xong mà không cần liên hệ lại trong một khoảng thời gian sau đó. Một phiên chat kết thúc chưa chắc là thành công, vì có thể khách bỏ cuộc rồi gọi điện. Muốn đo đúng, cần nối dữ liệu của cổng với tổng đài và email để thấy khách có quay lại qua kênh khác vì cùng một vấn đề hay không.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Lấy dữ liệu ticket và cuộc gọi gần đây, nhóm theo loại câu hỏi để tìm những loại vừa phổ biến vừa có dữ liệu sẵn trong hệ thống. Đầu ra là danh sách loại yêu cầu đưa vào cổng ở giai đoạn đầu, ghi rõ loại nào chỉ trả lời, loại nào cho tạo ticket, kèm chỉ số mục tiêu. Trưởng bộ phận chăm sóc khách hàng duyệt danh sách này.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Rà dữ liệu khách hàng trong CRM, hợp đồng và ticket: mã khách có thống nhất giữa các hệ thống không, người dùng đã gắn đúng công ty chưa, trường nào hay bỏ trống. Song song, lập ma trận vai trò, dữ liệu được xem và hành động được làm. IT xác nhận cấu hình đăng nhập và quyền API; bộ phận CSKH xác nhận nội dung kho kiến thức.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Định nghĩa các hàm agent được gọi, tham số của từng hàm và điều kiện dừng: không tìm thấy hợp đồng, hệ thống nguồn không phản hồi, yêu cầu nằm ngoài phạm vi. Ghi rõ những trường hợp luôn chuyển người, như khiếu nại hay đề nghị hủy hợp đồng. Đầu ra là tài liệu tích hợp và bảng kịch bản chuyển tiếp, được CSKH và IT cùng ký duyệt.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Mở cổng cho một nhóm khách quen trước, đọc log hội thoại hằng tuần để tìm câu agent không trả lời được hoặc trả lời sai. Mỗi lỗi được gắn nhãn: thiếu tài liệu, sai dữ liệu nguồn, sai quyền hay hiểu sai câu hỏi. Chỉ mở rộng cho toàn bộ khách khi không còn lỗi nào về quyền và tỷ lệ chuyển người đã ổn định.

4. Ví dụ giả định

Khách đăng nhập để tra cứu hợp đồng và tạo ticket; dữ liệu cá nhân chỉ xuất hiện sau xác thực.

Từ tình huống này nên dựng ít nhất năm ca thử: khách chưa đăng nhập hỏi ngày hết hạn hợp đồng, khách đã đăng nhập hỏi đúng hợp đồng của mình, khách gõ mã số của một công ty khác để hỏi, người dùng không thuộc nhóm kế toán hỏi hóa đơn, và khách tạo ticket rồi bấm gửi lại. Kết quả mong đợi của ca đầu, ca thứ ba và ca thứ tư là không lộ bất kỳ thông tin nào ngoài quyền. Khi một ca sai, cần xác định lỗi nằm ở phiên đăng nhập không truyền đúng mã khách, ở API trả thừa dữ liệu hay ở cách agent hiểu câu hỏi.

5. Rủi ro và giới hạn

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

Rủi ro lớn nhất của cổng tự phục vụ là lộ dữ liệu của khách này cho khách khác. Điều đó hiếm khi do mô hình tự ý tiết lộ, mà thường do API trả về quá nhiều dữ liệu hoặc mã khách bị lấy từ nội dung câu hỏi thay vì phiên đăng nhập. Rủi ro thứ hai là agent trả lời rất chắc chắn dựa trên tài liệu cũ, khiến khách làm theo chính sách đã hết hiệu lực. Rủi ro thứ ba là khách bị kẹt trong vòng hỏi đáp mà không tìm được đường gặp người, và sự bực bội đó thường quay lại dưới dạng khiếu nại.

6. Phân chia trách nhiệm vận hành

Bộ phận chăm sóc khách hàng sở hữu cổng về mặt nghiệp vụ: quyết định loại yêu cầu nào được tự phục vụ, giữ kho kiến thức và xử lý các ca được chuyển sang. Bộ phận quản lý hợp đồng và kế toán chịu trách nhiệm độ đúng của dữ liệu hợp đồng, hóa đơn mà khách nhìn thấy. IT lo đăng nhập, phân quyền, tích hợp API và giám sát lỗi. Vì cổng mở dữ liệu ra bên ngoài, bộ phận an toàn thông tin nên duyệt thiết kế quyền trước ngày mở cho khách.

Khi đổi chính sách, thêm sản phẩm hay đổi cấu trúc dữ liệu trong CRM, câu trả lời trên cổng có thể sai ngay. Nên quy định rõ: ai sửa chính sách thì báo người giữ kho kiến thức, ai đổi API thì chạy lại bộ ca thử phân quyền. Nếu phát hiện khách xem được dữ liệu không phải của mình, IT tắt ngay phần tra cứu cá nhân và giữ lại phần hỏi đáp chung, còn CSKH thông báo cho khách bị ảnh hưởng theo quy trình xử lý sự cố của công ty.

7. Chỉ số nên theo dõi

• Tỷ lệ yêu cầu khách tự giải quyết xong không cần liên hệ lại
• Tỷ lệ chuyển nhân viên đúng lúc và đúng loại yêu cầu
• Lỗi tích hợp, độ trễ tra cứu và số ticket phải sửa lại
• Chi phí vận hành so với lượng cuộc gọi, email giảm được

Lượt truy cập cổng hay số tin nhắn không cho biết cổng có hữu ích. Nên theo dõi với từng loại yêu cầu: bao nhiêu khách tự xong, bao nhiêu gọi lại tổng đài trong vài ngày sau, và ticket tạo từ cổng có đủ thông tin để xử lý ngay hay nhân viên phải hỏi lại. Loại yêu cầu nào có tỷ lệ gọi lại cao thường do thiếu dữ liệu hoặc hướng dẫn chưa rõ, ít khi do mô hình.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò trong cùng một công ty khách
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có thể mở cổng tự phục vụ AI cho khách ngay không? Phần hỏi đáp chính sách và hướng dẫn có thể mở sớm nếu kho kiến thức đã được rà soát. Phần tra cứu dữ liệu riêng và tạo yêu cầu chỉ nên mở sau khi đăng nhập, phân quyền theo vai trò và các ca thử chống lộ dữ liệu đã chạy đạt.

Nên xây cổng tự phục vụ bắt đầu từ loại yêu cầu nào? Bắt đầu từ những câu khách hỏi nhiều nhất mà dữ liệu đã nằm sẵn trong hệ thống, như trạng thái ticket, ngày hết hạn hợp đồng hay hóa đơn đã phát hành. Những loại cần phán đoán, như khiếu nại hay đề nghị ngoài chính sách, để lại cho nhân viên.

Khi nào yêu cầu gửi từ cổng tự phục vụ cần nhân viên duyệt? Khi yêu cầu ảnh hưởng tiền hoặc cam kết, như điều chỉnh hóa đơn, gia hạn, hủy hợp đồng hay đổi người đại diện. Các trường hợp khách phàn nàn, hỏi lại nhiều lần hoặc agent không tìm thấy dữ liệu cũng nên chuyển người.

Cổng tự phục vụ có khiến khách khó gặp người thật hơn không? Chỉ khi thiết kế sai. Nút gặp nhân viên phải luôn nhìn thấy được, và khi chuyển, agent gửi kèm tóm tắt để khách không phải kể lại. Mục tiêu là bớt những câu hỏi lặp lại, không phải chặn khách ở ngoài.

Kết luận

Cổng tự phục vụ AI chỉ có ích khi khách thật sự tự làm xong việc của mình: tra đúng dữ liệu, tạo yêu cầu đủ thông tin và gặp được người khi cần. Muốn vậy, đăng nhập và phân quyền phải chắc trước, kho kiến thức phải có người giữ, và chỉ số phải tính cả những khách quay lại qua kênh khác. Với doanh nghiệp bán hàng trực tuyến, bước tiếp theo thường là cho khách tự gửi yêu cầu đổi trả, xem bài AI xử lý đổi trả hàng.

Trao đổi với Naventic để khảo sát nhu cầu tự phục vụ của khách hàng. Đọc thêm: AI Customer Support.