Trợ lý ảo là phần mềm nhận yêu cầu bằng ngôn ngữ tự nhiên rồi thực hiện công việc thay người dùng, như tra cứu dữ liệu, tạo bản ghi, đặt lịch hay tổng hợp thông tin từ nhiều hệ thống. Khác với chatbot, vốn chủ yếu trả lời câu hỏi trong một cuộc trò chuyện, trợ lý ảo được nối vào các hệ thống nghiệp vụ nên nó tạo ra thay đổi thật chứ không chỉ trả về chữ.
Bài này phân biệt trợ lý ảo với chatbot, nêu những việc nó làm được cho khách và cho nội bộ, liệt kê bốn thứ cần chuẩn bị trước, và ba rủi ro nên chặn ngay từ khi thiết kế.
Trợ lý ảo khác chatbot ở những điểm nào?
Ranh giới giữa hai khái niệm này đã mờ đi trong vài năm gần đây, nhưng vẫn có ba điểm khác nhau rõ ràng và chúng ảnh hưởng trực tiếp tới chi phí triển khai.
| Tiêu chí | Chatbot | Trợ lý ảo |
|---|---|---|
| Kết quả tạo ra | Một câu trả lời trong cửa sổ trò chuyện | Một hành động trong hệ thống: tạo phiếu, đặt lịch, cập nhật đơn |
| Phạm vi kết nối | Thường nối vào kho tài liệu và một vài nguồn dữ liệu | Nối vào nhiều hệ thống nghiệp vụ, có quyền ghi chứ không chỉ đọc |
| Cách đo thành công | Tỷ lệ câu trả lời đúng, tỷ lệ cuộc tự xử lý trọn vẹn | Số việc hoàn thành trọn vẹn, tỷ lệ phải làm lại bằng tay |
| Rủi ro chính | Trả lời sai thông tin | Thao tác sai trên dữ liệu thật, khó hoàn tác |
Dòng cuối là điểm quan trọng nhất khi cân nhắc. Một chatbot trả lời sai gây hiểu nhầm và bạn đính chính được. Một trợ lý ảo huỷ nhầm đơn hàng thì hậu quả đã xảy ra trước khi ai kịp phát hiện, nên phần phân quyền và xác nhận phải được thiết kế trước phần trò chuyện.
Trợ lý ảo làm được việc gì cho khách hàng?
Ở phía khách, giá trị nằm ở chỗ khách nói ra nhu cầu bằng lời của họ và việc được xử lý ngay, thay vì phải điền biểu mẫu hoặc chờ nhân viên rảnh.
- Tra cứu trạng thái. Kiểm tra đơn hàng, lịch hẹn, hạn bảo hành mà không cần khách nhớ mã hay đăng nhập qua nhiều lớp.
- Đặt và đổi lịch. Khách nói thời gian mong muốn, hệ thống đối chiếu lịch trống rồi xác nhận. Đây là nhóm việc có quy tắc rõ ràng nên tỷ lệ thành công cao.
- Tiếp nhận yêu cầu ngoài giờ. Ghi lại nội dung, phân loại mức độ khẩn, tạo phiếu cho bộ phận phụ trách và báo lại cho khách khi nào sẽ có người liên hệ.
- Hướng dẫn theo bước. Dẫn khách qua một quy trình có thứ tự, và biết khách đang dừng ở bước nào để tiếp tục đúng chỗ ở lần sau.
Việc thứ ba thường mang lại thay đổi nhìn thấy sớm nhất. Yêu cầu đến ngoài giờ mà không ai tiếp nhận là chỗ rò rỉ âm thầm, vì nó không để lại dấu vết nào trong báo cáo, khách chỉ đơn giản là không quay lại.
Trợ lý ảo hỗ trợ được gì cho nội bộ?
Phần dùng cho nội bộ thường dễ triển khai hơn phần dùng cho khách, vì người dùng là nhân viên đã hiểu nghiệp vụ và sai sót được phát hiện nhanh hơn.
- Tra cứu thông tin nghiệp vụ. Chính sách chiết khấu cho nhóm khách này là bao nhiêu, quy trình đổi hàng hỏng ra sao. Nhân viên mới tiết kiệm được rất nhiều thời gian hỏi người cũ.
- Chuẩn bị trước cuộc gặp. Tổng hợp lịch sử trao đổi với một khách thành bản tóm tắt ngắn, để người bán không phải đọc lại toàn bộ ghi chú.
- Nhập liệu bằng lời. Nhân viên đọc lại nội dung cuộc gặp, hệ thống tạo bản ghi có cấu trúc. Cách này giải quyết đúng lý do khiến dữ liệu hay bị bỏ trống.
- Nhắc việc theo ngữ cảnh. Không phải nhắc theo lịch cố định mà nhắc dựa trên trạng thái thật, ví dụ báo giá đã gửi mà chưa có phản hồi sau một khoảng thời gian.
Việc thứ ba đáng chú ý vì nó tấn công đúng nguyên nhân gốc. Dữ liệu thiếu thường không phải do nhân viên lười mà do việc nhập diễn ra ở nơi khác chỗ làm việc, và đọc bằng lời thì rào cản đó biến mất.
Cần chuẩn bị bốn thứ gì trước khi triển khai?
Phần lớn dự án trợ lý ảo gặp khó không phải vì công nghệ mà vì thiếu bốn thứ dưới đây. Chuẩn bị trước sẽ rút ngắn thời gian triển khai hơn mọi lựa chọn kỹ thuật.
- Danh sách việc cụ thể, không phải mục tiêu chung. Hỗ trợ khách tốt hơn là một mong muốn, còn tra cứu trạng thái đơn hàng theo số điện thoại mới là một việc triển khai được. Hãy liệt kê từ năm tới mười việc như vậy.
- Dữ liệu ở nơi truy cập được. Nếu thông tin đơn hàng nằm trong một tệp trên máy của một người, trợ lý ảo không đọc được. Đây là rào cản thực tế hay gặp nhất.
- Quy tắc rõ ràng cho từng việc. Đổi lịch được trước bao lâu, trường hợp nào phải có người duyệt, giới hạn nào không được vượt. Quy tắc mơ hồ trong đầu người quản lý thì hệ thống không thực hiện được.
- Người chịu trách nhiệm cập nhật. Chính sách thay đổi thì ai sửa, sửa ở đâu. Không có người này, hệ thống sẽ trả lời theo quy định cũ sau vài tháng.
Thứ tự quan trọng: làm xong bốn việc này rồi mới chọn công cụ. Làm ngược lại thì bạn sẽ mua một hệ thống có nhiều tính năng nhưng không nối được vào dữ liệu của mình.
Ba rủi ro nào cần chặn ngay từ đầu?
Vì trợ lý ảo có quyền thao tác chứ không chỉ trả lời, các rủi ro của nó nặng hơn và cần được xử lý ở khâu thiết kế chứ không phải khâu vận hành.
- Thao tác sai trên dữ liệu thật. Cách chặn là phân quyền theo việc chứ không theo hệ thống: trợ lý được tạo phiếu nhưng không được xoá, được đổi lịch nhưng không được huỷ đơn. Mọi việc khó hoàn tác đều phải có bước xác nhận của người.
- Lộ thông tin giữa các nhóm. Khi trợ lý đọc được nhiều nguồn, nó có thể vô tình ghép thông tin của khách này trả lời cho khách khác. Phân quyền phải áp dụng ở tầng dữ liệu, không chỉ ở tầng câu trả lời.
- Không có dấu vết để truy lại. Mọi hành động phải được ghi nhật ký gồm ai yêu cầu, hệ thống làm gì, vào lúc nào. Không có nhật ký thì khi xảy ra sự cố bạn không tìm được nguyên nhân.
Một nguyên tắc dễ nhớ khi thiết kế: việc nào sửa lại được trong vài phút thì cho phép tự động, việc nào sửa lại mất nhiều công hoặc ảnh hưởng tới tiền thì bắt buộc có người xác nhận.
Trợ lý ảo có những giới hạn nào ở thực tế Việt Nam?
Ngoài các rủi ro về quyền hạn, còn bốn giới hạn thực tế mà bạn nên thử trước khi cam kết ngân sách lớn.
- Dữ liệu không đồng nhất. Cùng một khách xuất hiện dưới nhiều cách viết tên trong các hệ thống khác nhau. Trợ lý ảo sẽ không nhận ra đó là một người, và kết quả tra cứu sẽ thiếu.
- Hệ thống cũ không có cách kết nối. Nhiều phần mềm đang dùng không cung cấp cách cho bên ngoài đọc ghi dữ liệu. Khi đó chi phí thật nằm ở việc kết nối chứ không ở trợ lý.
- Cách nói không dấu và viết tắt. Nhân viên gõ nhanh trong lúc bận, khách nhắn tin bằng từ viết tắt riêng. Cần thử trên chính ngôn ngữ thật của người dùng, không thử bằng câu mẫu.
- Yêu cầu nhiều ý trong một câu. Người Việt hay gộp nhiều việc vào một tin nhắn. Hệ thống dễ chỉ làm ý đầu rồi coi như xong.
Giới hạn thứ hai quyết định phần lớn chi phí và thường bị phát hiện muộn. Nên hỏi ngay từ buổi làm việc đầu tiên rằng các hệ thống đang dùng có cách kết nối hay không, trước khi bàn tới bất cứ tính năng nào.
Khi nào nên chọn chatbot thay vì trợ lý ảo?
Không phải nhu cầu nào cũng cần tới một hệ thống có quyền thao tác. Chọn đúng mức độ giúp bạn triển khai nhanh hơn và chịu ít rủi ro hơn.
Nên chọn giải pháp trả lời câu hỏi đơn thuần khi phần lớn tin nhắn đến là hỏi thông tin cố định, khi bạn chưa có hệ thống dữ liệu tập trung, hoặc khi mục tiêu trước mắt là giảm tải cho đội trực kênh. Cách phân biệt và các tiêu chí kiểm tra được trình bày kỹ trong bài về chatbot AI và chatbot kịch bản.
Nên chọn trợ lý ảo khi công việc lặp lại của bạn là thao tác chứ không phải trả lời, khi dữ liệu đã nằm ở nơi truy cập được, và khi bạn chấp nhận đầu tư cho phần phân quyền và nhật ký. Ranh giới thực dụng là hỏi xem người dùng cần một câu trả lời hay cần một việc được làm xong.
Đo hiệu quả của trợ lý ảo bằng cách nào?
Vì trợ lý ảo tạo ra hành động chứ không chỉ câu trả lời, cách đo cũng phải khác. Đếm số lượt trò chuyện gần như không nói lên điều gì về giá trị thật.
- Tỷ lệ việc hoàn thành trọn vẹn. Số yêu cầu được xử lý xong mà không phải làm lại bằng tay, chia cho tổng số yêu cầu đã nhận. Đây là chỉ số cốt lõi.
- Tỷ lệ phải sửa sau. Số bản ghi do hệ thống tạo mà sau đó nhân viên phải chỉnh lại. Con số này cao nghĩa là quy tắc chưa đủ rõ chứ không phải mô hình yếu.
- Thời gian từ lúc nhận yêu cầu tới lúc xong. So với cách làm cũ trên cùng loại việc, đây là con số dễ giải thích nhất với người quản lý.
- Số lần phải can thiệp khẩn. Mỗi lần người phải dừng hệ thống lại để sửa là một tín hiệu cần xem lại phạm vi quyền đã cấp.
Nên lấy mốc trước khi triển khai. Đo thời gian và số bước của cách làm hiện tại trong một tuần, rồi so lại sau khi chạy. Không có mốc thì mọi con số về sau đều không trả lời được câu hỏi việc này có đáng hay không.
Nên bắt đầu triển khai từ đâu?
Bốn giai đoạn dưới đây trải trong khoảng ba tháng, và mỗi giai đoạn đều cho kết quả dùng được trước khi sang giai đoạn sau.
- Chọn một việc duy nhất. Việc lặp lại nhiều nhất, có quy tắc rõ nhất và ít rủi ro nhất. Thường là tra cứu trạng thái hoặc đặt lịch.
- Chạy nội bộ trước. Cho nhân viên dùng trong vài tuần. Họ phát hiện lỗi nhanh hơn và việc sửa không ảnh hưởng tới khách.
- Mở cho một nhóm khách nhỏ. Đọc lại toàn bộ hội thoại hàng ngày trong hai tuần đầu, và giữ đường chuyển sang người thật thật rõ ràng.
- Thêm việc thứ hai. Chỉ khi việc thứ nhất đã chạy ổn định và bạn đã có số liệu để so.
Phần kỹ thuật của việc nối vào website và các kênh nhắn tin được trình bày trong bài về cách tạo chatbot cho từng kênh, dùng được cho cả trợ lý ảo vì lớp kết nối kênh là như nhau.
Nhóm công cụ mới nhất đi xa hơn một bước nữa: chúng không chỉ trả lời mà còn tự thao tác trong phần mềm thay người dùng. Phần việc nào giao được cho chúng và phần nào vẫn phải giữ người quyết định được trình bày trong bài agent AI thao tác máy tính.
Một bước tiến xa hơn trợ lý ảo là AI Agent: không chỉ trả lời mà còn tự thực hiện việc trên hệ thống được cấp quyền. Xem thêm ở bài AI Agent là gì.
Bước tiếp theo nên làm gì?
Nếu bạn đã liệt kê được vài việc lặp lại và biết dữ liệu của chúng nằm ở đâu, việc còn lại là kiểm tra xem các hệ thống hiện có nối được với nhau hay không. Câu trả lời cho việc đó quyết định phạm vi và chi phí nhiều hơn mọi yếu tố khác.
Với các yêu cầu đến qua điện thoại, lớp tiếp nhận thường là tổng đài ảo đứng trước, rồi mới tới phần xử lý nghiệp vụ phía sau. Hai lớp này nên được thiết kế cùng nhau để cuộc gọi không bị đứt đoạn giữa chừng.
Đội ngũ InCard có thể cùng bạn rà lại một việc cụ thể của doanh nghiệp mình, xem nó tự động hoá được tới đâu và chỗ nào bắt buộc phải giữ người. Bạn có thể đặt lịch demo để cùng đi qua một quy trình có thật từ đầu tới cuối.
