Kết quả sau khi thiết kế lại cách khách tiếp cận câu trả lời

Dành cho: PM, PO, BA và engineer đang xây dựng hoặc chuẩn bị xây dựng sản phẩm có AI.

TL;DR

• Nỗi đau (Pain point): Doanh nghiệp đã có sẵn FAQ, Điều khoản sử dụng và đội CS đã trả lời cùng một nhóm câu hỏi hàng trăm lần, nhưng khách hàng vẫn liên tục liên hệ CS.
• Nguyên nhân cốt lõi: Khách hàng bắt đầu từ một tình huống cụ thể chứ không phải từ từ khóa, và họ cần sự chắc chắn rằng chính sách đó áp dụng đúng cho trường hợp của chính họ.
• Giải pháp (AI Chatbot): Đặt một lớp hội thoại lên trên kho kiến thức sẵn có để thông dịch ý định của khách, đồng thời tích hợp đường chuyển case mượt mà sang đội CS khi gặp vấn đề phức tạp.
• Kết quả thực tế: Sau 5 tháng go-live, tỷ lệ tự động hóa chăm sóc khách hàng tăng khoảng 1,4 lần.
• Nội dung bài viết: Chia sẻ góc nhìn Product Thinking của PM trong việc dịch chuyển câu hỏi từ “bot trả lời được gì” sang “khách còn cần liên hệ CS không”, kèm theo bộ khung chẩn đoán và hệ thống chỉ số đo lường thực tế.

Vấn đề: câu trả lời đã có sẵn nhưng câu hỏi vẫn lặp lại

Nền tảng có FAQ, Điều khoản sử dụng, hướng dẫn tải xuống và hướng dẫn thanh toán. Đội CS đã trả lời những câu hỏi này rất nhiều lần. Tuần sau, tháng sau, những câu hỏi gần giống vẫn quay lại hộp thư của CS.

Khi nhận vai trò PM của dự án AI Chatbot, tôi không bắt đầu bằng câu hỏi “AI trả lời được những gì”. Tôi bắt đầu bằng một câu hỏi khó chịu hơn: nếu doanh nghiệp đã có câu trả lời, vì sao khách hàng không tự lấy được nó? Đây cũng là câu hỏi gốc của mọi chiến lược tự phục vụ (self-service).

Một câu hỏi lặp lại nhiều lần không có nghĩa là cùng một khách hàng lặp lại

Đội CS nhìn thấy một công việc lặp. Khách hàng thì không. Khách A hỏi hôm nay, khách B hỏi tuần sau, khách C hỏi tháng sau, và với từng người, đó là lần đầu họ gặp vấn đề. Doanh nghiệp nhìn vào thì thấy một mô hình đã xuất hiện hàng trăm lần.

Vì vậy, nếu chỉ nhìn vào số lần câu hỏi lặp lại thì dễ kết luận rằng khách không chịu đọc FAQ. Tôi cho rằng kết luận đó đặt sai chỗ. Vấn đề nằm ở cách doanh nghiệp đưa thông tin đến khách và cách khách tiếp nhận nó. Khi xem lại các liên hệ gửi CS, tôi nhóm được bốn điểm mà ở đó khách bình thường sẽ bỏ việc tự tìm và chuyển sang hỏi CS. Không điểm nào trong bốn điểm này xuất phát từ việc khách lười hay kém.

Bốn cửa khiến khách hàng từ bỏ việc tự đọc FAQ (self-service) và rẽ sang hỏi CS

Tôi gọi bốn điểm đó là bốn cửa. Từ lúc có thắc mắc đến lúc tự giải quyết được, khách lần lượt đi qua từng cửa như sơ đồ dưới đây. Ở mỗi cửa, khách đều có thể rẽ sang CS. Chỉ khi đi hết bốn cửa, khách mới tự giải quyết được vấn đề mà không cần liên hệ CS.

Bảng dưới đây cho biết ở từng cửa khách đang nghĩ gì, và hướng xử lý nào nên thử trước.

Cửa 1. Hỏi CS luôn gần hơn tự đi tìm kiếm 

Khách gặp vấn đề thì có hai đường: mở FAQ, tìm kiếm, tự đọc và tự suy luận, hoặc bấm form liên hệ, gõ một câu rồi chờ. Đường thứ hai không đòi khách biết từ khóa hay biết câu trả lời nằm ở trang nào, nên phần lớn chọn đường này. Con người vốn nghiêng về cách ít tốn sức nhất.

Cửa 2. Khách hàng mở FAQ rồi cũng chỉ lướt qua

Nghiên cứu kinh điển về hành vi đọc trên web của Jakob Nielsen (Nielsen Norman Group, 1997) đã chỉ ra rằng: phần lớn người dùng chỉ lướt qua nội dung (scanning) chứ hiếm khi đọc từng từ. Các nghiên cứu eye-tracking tiếp theo (gần nhất là báo cáo tổng hợp hành vi người dùng trực tuyến năm 2023–2024 của NN/g) vẫn cho kết quả tương tự – chúng ta thường quét qua các khối chữ thay vì đọc kỹ. Giờ bạn hãy thử nhớ lại lần cuối mình đọc trọn vẹn một bản điều khoản sử dụng. So với việc phải căng mắt rà soát tài liệu dài dòng, việc gõ nhanh một câu hỏi để nhờ CS giải đáp nhẹ nhàng và nhanh chóng hơn nhiều.

Cửa 3. Đọc FAQ/ điều khoản sử dụng rồi nhưng vẫn không hiểu

Khách và doanh nghiệp đang nói hai thứ tiếng.

Khách hỏi: “Tôi tải ảnh này về làm website cho khách, có sao không?”.
FAQ viết “phạm vi sử dụng thương mại” và “điều kiện cấp phép”.
Khách đang kể một tình huống, còn FAQ trả lời bằng thuật ngữ của doanh nghiệp. Khách không tìm được câu trả lời cho tình huống của mình trong FAQ, nên rẽ sang hỏi CS.

Cửa 4. Khách hàng đã hiểu FAQ nhưng không chắc có đúng với mình không

Đây là cửa khó vượt nhất.
Khách hiểu chính sách, nhưng vẫn lo chi tiết riêng của mình sẽ làm kết quả khác đi. Khách không hỏi “chính sách là gì” mà hỏi “chính sách áp dụng cho tôi thế nào”. Khi liên quan đến tiền, tài khoản hay hoàn trả, nỗi lo này càng lớn. Khách muốn một người thật ghi nhận vấn đề của mình, và câu trả lời đó cũng là thứ khách có thể dựa vào nếu có sự cố. Với khách, độ tin cậy của câu trả lời quan trọng ngang với việc có câu trả lời.

Cả bốn cửa có một điểm chung: khách phản ứng như bất kỳ người dùng bình thường nào. Vì vậy hướng xử lý là thiết kế lại cách khách tiếp cận thông tin, không phải yêu cầu khách đọc kỹ hơn.
Hai phần sau sẽ trả lời hai câu hỏi: vậy logic search thông tin có thể giải quyết được đến cửa nào, và phần còn lại cần gì?

Vì sao không cải thiện cách search FAQ để khách tìm nhanh hơn?

Câu hỏi này hợp lý, và nhiều lúc Search chính là đáp án. Nếu khách biết mình cần tìm gì, biết từ khóa, và thông tin được tổ chức tốt, khách tự tìm được. “Làm sao đổi phương thức thanh toán?” là một ví dụ như vậy.

Search xử lý được cửa 2 và một phần cửa 1. Search không xử lý được cửa 3 và cửa 4. Search bắt đầu từ thứ khách nghĩ mình cần tìm, còn khách thường bắt đầu từ một tình huống. Khách không biết hệ thống dùng từ khóa nào, và cần ai đó nối tình huống của mình với chính sách. Đó là chỗ giao diện hội thoại tạo ra giá trị.

Dữ liệu từ các báo cáo benchmark trải nghiệm khách hàng của CustomerGauge (2023) từng chỉ ra rằng đa số người dùng ưa chuộng trợ lý ảo hơn trang web tĩnh trong việc tự phục vụ. Tôi xem đây là một giả thiết đáng thử nghiệm thay vì chân lý, bởi hiệu quả thực tế luôn dao động tùy theo đặc thù sản phẩm và phân khúc khách hàng.

Giải pháp: chatbot là lớp giao tiếp đặt trên kiến thức (knowledge base) đã tồn tại sẵn.

Chatbot của chúng tôi không tự tạo ra kiến thức mới.
FAQ, chính sách và các câu trả lời CS đang dùng đều đã tồn tại. Mục tiêu của dự án là thay thế những phản hồi CS mà chỉ cần đọc FAQ là trả lời được.
Khách nhận câu trả lời nhanh hơn, và CS có thời gian cho những công việc khó, có giá trị hơn.

Chatbot đứng giữa kho kiến thức và khách hàng, và biết khi nào cần chuyển câu hỏi sang CS (human escalation). Cách chia việc này gần với tư duy “phễu hỗ trợ” (Conversational Support Funnel) của Intercom: bot trả lời câu hỏi lặp lại, con người xử lý case phức tạp. Mỗi phần của thiết kế này đáp lại một cửa. Chatbot nhận câu hỏi ngay trong ngữ cảnh khách đang cần (cửa 1), trả lời ngắn thay vì bắt khách đọc cả trang (cửa 2) và diễn giải chính sách bằng ngôn ngữ của khách (cửa 3). Với case rủi ro cao hoặc case đặc thù (cửa 4), chatbot không cố thay con người mà chuyển case sang CS đúng lúc.

Team bắt đầu từ phạm vi nhỏ để đo được chất lượng trước khi mở rộng. Bản MVP chỉ chạy trên 4 nhóm câu hỏi. Bộ dữ liệu FAQ ban đầu được xây theo các cụm chủ đề khách hỏi nhiều nhất: chi tiết về hình ảnh và cách sử dụng, tải xuống và thanh toán, cùng các quy định về trường hợp được và không được sử dụng sản phẩm.

Khi chatbot thực sự “hiểu” được nỗi lòng khách hàng

Trong giai đoạn đầu, đội CS chỉ ra một hội thoại mà họ ấn tượng. Một khách hỏi xem có được dùng một hình ảnh cho một mục đích cụ thể không. Trong một phiên duy nhất, khách đổi góc hỏi ba lần: từ “có được dùng không”, sang “câu chữ này trong điều khoản nghĩa là gì”, rồi “cụ thể những cách thể hiện nào thì thuộc diện bị hạn chế”. Bot trả lời nhất quán theo điều khoản ở cả ba lượt, giải thích ý nghĩa quy định và dẫn lại đúng nội dung điều khoản.

Tuy nhiên, một vài hội thoại xuất sắc là chưa đủ để khẳng định thành công của cả hệ thống. Để biết AI có thực sự giải quyết được bài toán hay không, chúng tôi cần những con số.

Đo lường: từ “độ chính xác” đến “kết quả của khách hàng”

Độ chính xác của bot tăng gần gấp đôi so với lúc bắt đầu. 

Con số này cho biết bot trả lời đúng chính sách đến đâu, nhưng chưa cho biết vấn đề của khách đã được giải quyết hay chưa. Một câu trả lời đúng vẫn có thể không giải quyết được gì, nếu khách đọc xong vẫn hỏi “vậy trường hợp của tôi có được không?”.

Vì độ chính xác chưa đủ, team đo ở hai thời điểm với hai bộ chỉ số khác nhau. Trước go live, team đo chất lượng và tốc độ của bot. Sau go live, team đo tác động thật lên khách và lên đội CS.

Mỗi chỉ số là một câu hỏi, không phải một con số

Trước go live

Sau go live

Giai đoạn sau go live khó hơn, vì các chỉ số ở đây gắn với hành vi của khách, không chỉ với bot. Tôi rút ra một bài học: nếu định nghĩa chỉ số mơ hồ, cả đội sẽ tranh luận về con số thay vì về sản phẩm. Ví dụ, tỷ lệ bot trả lời được chưa chắc bằng tỷ lệ khách không cần liên hệ CS nữa.

Câu hỏi đúng không phải “bot trả lời chính xác đến đâu” mà là “sau khi dùng bot, khách còn cần liên hệ CS không”.

Khi coverage tăng nhưng khối lượng việc không giảm

Một chỉ số đứng riêng rất dễ bị đọc sai. Ví dụ rõ nhất là cặp bot coverage và khối lượng việc của CS.

Coverage tăng mạnh nhưng khối lượng việc của CS không giảm. Theo logic thông thường, bot nhận nhiều câu hỏi hơn thì CS phải nhẹ việc hơn. Số liệu không cho thấy điều đó, nên team có hai giả thuyết. Giả thuyết thứ nhất: bot trả lời chưa tốt, nên khách vẫn quay lại CS. Giả thuyết thứ hai: tổng lượng câu hỏi tăng vì một nguyên nhân bên ngoài, nên bot nhận thêm câu hỏi nhưng CS vẫn không giảm việc. Khi kiểm tra, team thấy doanh nghiệp vừa công bố một thay đổi về chính sách kinh doanh, và nhóm khách hàng chịu ảnh hưởng đặt nhiều câu hỏi hơn hẳn quanh thời điểm công bố.

Để phân biệt hai giả thuyết, team nhìn lượng liên hệ theo từng cụm chủ đề. Nếu bot yếu đi, liên hệ tăng sẽ trải đều trên mọi chủ đề. Thực tế mức tăng dồn vào một chủ đề gắn với sự kiện, nên giả thuyết thứ hai đúng. Nhờ vậy team tiếp tục theo hướng đã định, thay vì dừng lại để sửa một lỗi không tồn tại.

Từ chẩn đoán đến phiên bản mới

Chẩn đoán chỉ có giá trị khi dẫn đến thay đổi trên sản phẩm. Sau mỗi vòng đo lường, team cập nhật phiên bản: vá lỗi, cải thiện tính năng, nâng cấp UI/UX. 

Mỗi phiên bản đóng góp một phần vào kết quả chung.

Sau 5 tháng go-live, tỷ lệ tự động hóa tăng khoảng 1,4 lần, và đội CS tập trung được vào những case cần kiểm tra riêng từng trường hợp. Đây là kết quả của cả giai đoạn, gồm việc mở rộng phạm vi, bổ sung kho kiến thức và các bản cập nhật. Team không quy toàn bộ mức tăng cho riêng các bản cập nhật.

Câu hỏi lặp lại cũng là tín hiệu từ khách hàng

Ngoài việc giảm tải cho CS, các câu hỏi lặp lại còn cho biết sản phẩm đang khó dùng ở đâu. Mỗi kiểu câu hỏi chỉ ra một vấn đề khác nhau.

Vì vậy CS không chỉ là nơi xử lý vấn đề sau khi khách gặp trở ngại. Dữ liệu liên hệ của CS còn là nguồn nghiên cứu người dùng sẵn có, phát sinh từ chính hoạt động hằng ngày.

Từ chatbot đến Product Thinking

Cách tôi đặt câu hỏi đã thay đổi theo thời gian. Lúc đầu là “làm sao xây chatbot trả lời được khách”. Về sau là một chuỗi ba câu hỏi: khách đang cố hoàn thành điều gì, thông tin họ cần đã tồn tại chưa, và nếu đã có thì vì sao họ vẫn không tự tìm được nó.

Câu trả lời cho câu hỏi cuối, tức là khách bị chặn ở cửa nào, quyết định nên làm gì. Các cách xử lý có thể xếp theo thứ tự từ đơn giản đến phức tạp:

Nguyên tắc là chọn cách đơn giản nhất giải quyết được cửa mà khách đang bị chặn, và chỉ dùng AI khi các bước trước chưa đủ. AI hội thoại phù hợp khi khách phải diễn đạt một tình huống riêng và cần hệ thống tìm, tổng hợp, giải thích thông tin sẵn có. Nếu viết lại FAQ giải quyết được thì viết lại FAQ, và nếu cải thiện Search giải quyết được thì cải thiện Search.

Những điểm có thể áp dụng cho sản phẩm có AI

1. Xác định công việc của khách trước khi chọn công nghệ. Phân loại các case CS theo bốn cửa để biết khách rẽ sang CS ở bước nào. (PM, PO, BA)

2. Thiết kế đường chuyển sang người ngay từ phiên bản đầu. Quy định rõ case nào bot không tự xử lý, và chuyển kèm tóm tắt hội thoại để CS không hỏi lại từ đầu. (PM, engineer)

3. Định nghĩa mỗi chỉ số bằng câu hỏi nó trả lời. Ghi rõ tử số, mẫu số và điều kiện hiệu chỉnh trước khi báo cáo. (PM, BA)

4. Khi một chỉ số bất thường, tách theo chủ đề và nhóm đối tượng trước khi kết luận về chất lượng mô hình. Việc này đòi hỏi log được gắn nhãn chủ đề ngay từ đầu. (engineer, BA)

5. Bắt đầu từ phạm vi nhỏ. MVP của dự án chỉ chạy trên một số nhóm câu hỏi, đủ để đo và điều chỉnh trước khi mở rộng. (PM, PO)

Kết luận

Sau khi go live, vấn đề và nhu cầu mới vẫn liên tục xuất hiện, từ người dùng lẫn từ business. Đo lường liên tục giúp team phát hiện sớm và phân tích nguyên nhân trước khi thay đổi sản phẩm, như trường hợp coverage tăng mà khối lượng việc không giảm.

Thước đo thành công của một AI Customer Support Chatbot không phải là bot trả lời được ngày càng nhiều câu hỏi. Thước đo đúng là khách hàng nhận được câu trả lời họ cần mà không phải quay lại hỏi người một lần nữa.

Chatbot chỉ có giá trị khi giúp khách giải quyết xong việc của họ. Vì vậy, với tôi, AI là phương tiện, không phải đích đến.

Lưu ý nhỏ: Bài viết chia sẻ góc nhìn từ một case study với tệp khách hàng và bài toán đặc thù. Quá trình hiện thực hóa dự án này không thể thiếu các framework nghiên cứu nền tảng, cùng sự đồng hành, cố vấn và nỗ lực tuyệt vời từ nhiều team liên quan. Kết quả ở mỗi sản phẩm có thể khác nhau, nhưng hy vọng tư duy tiếp cận (Product Thinking) này có thể ứng dụng được cho bài toán của bạn.

Tác giả: Khuyen Nguyen (Sophia)

Tài liệu tham khảo

• How Users Read on the Web, Jakob Nielsen, Nielsen Norman Group
• Why Customers Prefer Self-Service Support, But Only If It’s Done Right, CustomerGauge
• The Psychology of Customer Self Service, BetterDocs
• Conversational Support Funnel, Intercom