Callbot gặp nhiều người cùng nói: 4 tình huống nên thử trước nghiệm thu

Một cuộc gọi thử giữa nhân viên và Callbot thường diễn ra khá gọn: một người hỏi, một người trả lời, căn phòng yên tĩnh. Nhưng khi khách mở loa ngoài, người nhà nói thêm hoặc đồng nghiệp trả lời hộ, bài toán thay đổi. Bot có thể nghe được từng câu mà vẫn gán nhầm ý kiến, xác nhận sai người hoặc tiếp tục nói khi chưa đến lượt.

Để kiểm thử Callbot khi có nhiều người nói, doanh nghiệp nên tách ba câu hỏi: ai đang đưa ra thông tin, câu đó có dành cho bot không, và bot được phép làm gì tiếp theo. Bài viết đề xuất bốn tình huống thử và một cách ghi nhận kết quả cho đội telesales, chăm sóc khách hàng và người phụ trách nghiệm thu. Đây là phương pháp kiểm tra đề xuất, không phải cam kết rằng mọi hệ thống hiện có đều hỗ trợ nhận diện người nói.

Vì sao nghe đúng câu vẫn có thể hiểu sai cuộc gọi?

Hãy hình dung một tình huống giả định: nhân viên gọi xác nhận lịch tư vấn. Khách nói “chiều thứ Ba nhé”, sau đó quay sang người bên cạnh hỏi “hay thứ Tư được hơn?”. Nếu bot chốt ngay thứ Tư, lỗi không nhất thiết nằm ở nhận dạng chữ. Nó có thể đã hiểu nhầm câu trao đổi riêng thành chỉ dẫn trực tiếp cho mình.

Trong cuộc gọi nhiều người, nội dung và vai trò phải được xét cùng nhau. Người nói to hơn chưa chắc là người có quyền xác nhận. Người nói cuối cùng chưa chắc là khách chính. Câu “đồng ý” có thể là trả lời cho người nhà, cho một cuộc trò chuyện khác hoặc cho câu hỏi của bot. Từ bản ghi chỉ có chữ, người rà soát cũng dễ bỏ qua những khác biệt đó.

Đội nghiệm thu vì thế cần đánh giá cả việc bot chọn phản ứng. Phản hồi có thể là tiếp tục hỏi, chờ, xác nhận lại, ghi nhận chưa rõ hoặc bàn giao người thật. Một câu trả lời nghe trôi chảy nhưng làm thay đổi sai lịch hẹn vẫn là lỗi nghiệp vụ. Ngược lại, câu hỏi ngắn để làm rõ có thể là kết quả phù hợp hơn việc đoán.

Cách nhìn này giúp doanh nghiệp tránh dùng một bản demo đẹp làm đại diện cho mọi điều kiện. Bài thử sạch vẫn cần thiết để có mốc so sánh, nhưng phải bổ sung các tình huống sát cách khách thực sự nghe điện thoại. Mức độ phức tạp nên tăng dần, thay vì đưa nhiều nguồn âm thanh vào cùng lúc rồi không biết lỗi xuất hiện ở đâu.

Nghiên cứu MP-Bench gợi ý điều gì, và không chứng minh điều gì?

MP-Bench của Yi-Jen Shih và cộng sự, công bố ngày 11/9/2026, nghiên cứu tác tử giọng nói trong hội thoại nhiều bên. Bộ đánh giá có 927 tác vụ, gồm kiểm tra hiểu hội thoại và hành vi như nói đúng lượt hoặc giữ im lặng. Bối cảnh gồm ba người mô phỏng và một tác tử; trang công bố ghi nhận bài được nhận tại EMNLP 2026 Findings.

Điểm hữu ích cho doanh nghiệp là cách tách hiểu nội dung khỏi chọn lượt phản hồi. Tuy nhiên, đây không phải thử nghiệm Callbot UCALL, không phải phép đo chuyển đổi bán hàng Việt Nam và không cung cấp tỷ lệ nghiệm thu áp dụng chung. Không nên lấy điểm của một mô hình trong nghiên cứu làm tỷ lệ lỗi dự kiến cho hệ thống đang triển khai.

Bốn tình huống dưới đây là đề xuất biên tập cho quy trình nghiệm thu doanh nghiệp, không phải bộ đề nguyên bản của MP-Bench. Mục tiêu là biến rủi ro nhiều người nói thành những ca có đầu vào, kết quả mong đợi và cách xử lý rõ. Người dùng vẫn cần thống nhất với nhà cung cấp phạm vi hỗ trợ của hệ thống thực tế.

Bốn tình huống nên bổ sung vào buổi nghiệm thu

1. Người bên cạnh chen lời nhưng không nói với bot

Ví dụ giả định: khách đang xác nhận thời gian tư vấn, người bên cạnh nói “để chiều đi” trong một trao đổi riêng. Người điều phối bài thử cần ghi trước câu chen lời đó có phải chỉ dẫn cho bot hay không. Nếu không có kỳ vọng từ đầu, đội đánh giá sẽ dễ chọn lời giải theo kết quả bot đã tạo ra.

Điều cần xem là bot có tự thay lịch theo câu chen lời hay không. Phương án xử lý an toàn có thể là hỏi lại khách chính: “Anh/chị xác nhận giúp em thời gian muốn hẹn nhé?”. Không nên yêu cầu bot đoán danh tính chỉ từ chất giọng khi sản phẩm chưa công bố hỗ trợ việc đó. Tiêu chí ở đây là không biến thông tin chưa rõ thành xác nhận chắc chắn.

Khi xem lại, hãy nghe cả đoạn trước và sau câu chen lời. Một ảnh chụp transcript thường không đủ để xác định câu nói hướng tới ai. Ghi thời điểm, phản ứng thực tế và thay đổi trong kết quả cuối cuộc gọi. Nếu bot nói nhầm nhưng chưa lưu sai, vẫn cần ghi lỗi hội thoại; nếu đã lưu sai, phải ghi thêm ảnh hưởng nghiệp vụ.

2. Khách chủ động nhờ người khác trả lời hộ

Ví dụ giả định: khách nói “phần này để đồng nghiệp tôi trao đổi”, rồi đưa máy. Đây khác với tiếng nói nền vì có dấu hiệu chuyển người tham gia rõ ràng. Tuy nhiên, việc đổi người trao đổi không tự tạo quyền truy cập thông tin nhạy cảm hay quyền quyết định thay khách trong mọi nghiệp vụ.

Trước buổi thử, doanh nghiệp cần xác định phần nào được tiếp tục, phần nào phải xác minh lại và phần nào chuyển người thật. Với câu hỏi nhu cầu chung, bot có thể hỏi tiếp theo phạm vi đã thống nhất. Với thao tác quan trọng, phải dùng quy trình xác minh được doanh nghiệp phê duyệt; không tự suy ra rằng người đang cầm máy có đủ thẩm quyền.

Kết quả nên ghi rõ ai đã cung cấp thông tin, điều gì còn chưa xác nhận và bước sau do ai xử lý. Nếu hệ thống không có trường nhận diện người trao đổi, đội vận hành cần thống nhất cách lưu ghi chú hoặc trạng thái ngoại lệ mà sản phẩm thực sự hỗ trợ. Không mô tả tính năng chưa được kiểm tra thành tính năng sẵn có.

3. Hai người đưa ra hai câu trả lời khác nhau

Ví dụ giả định: một người muốn được gọi lại buổi sáng, người khác nói buổi chiều mới tiện. Lỗi dễ gặp là bot lấy câu đến sau cùng, hoặc ghép cả hai thành một nhu cầu không có thật. Với bài thử này, đội nghiệm thu không nên chấm đạt chỉ vì transcript chứa đầy đủ hai câu.

Hãy kiểm tra bot có phát hiện điều chưa thống nhất và yêu cầu xác nhận kết quả cuối hay không. Câu hỏi làm rõ nên ngắn, chỉ tập trung vào một điểm. Nếu qua một số lượt đã thống nhất trước mà vẫn chưa rõ, kết quả hợp lý là ghi nhận chưa xác nhận và chuyển xử lý phù hợp, thay vì tiếp tục hỏi lặp vô hạn.

Ca thử chỉ được xem là xử lý đúng khi câu chốt cuối và dữ liệu đầu ra nhất quán. Nếu bot đọc lại “buổi sáng” nhưng danh sách bàn giao ghi “buổi chiều”, vấn đề nằm ở toàn luồng, không chỉ ở chất lượng giọng nói. Cần kiểm tra cả nơi đội sales nhận việc, trong phạm vi quyền truy cập đã được cho phép.

4. Khách trao đổi riêng, rồi quay lại cuộc gọi

Ví dụ giả định: khách đang nghe tư vấn, tạm hỏi người nhà một câu rồi quay lại nói “tôi nghe đây”. Một hệ thống có thể chen ngang liên tục trong khoảng đó, hoặc bỏ mất nhu cầu đã nêu trước khi khách tạm dừng. Hai biểu hiện này cần được ghi nhận riêng vì cách sửa không giống nhau.

Thiết kế ca thử với một thông tin đã xác nhận trước đoạn trao đổi riêng, sau đó kiểm tra bot có giữ đúng ngữ cảnh khi tiếp tục hay không. Không chấm điểm dựa trên việc bot phải im lặng đúng một số giây tùy ý. Ngưỡng chờ, thông báo nhắc và phương án kết thúc cần phù hợp nghiệp vụ, được cấu hình hoặc xác nhận cùng nhà cung cấp.

Cuối ca, người kiểm thử nên xác nhận rằng bot không tạo thêm cam kết trong lúc khách chưa thực sự quay lại. Nếu hệ thống chỉ hỗ trợ hội thoại một người tại một thời điểm, hướng dẫn khách chuyển sang chỗ yên tĩnh hoặc xin phép gọi lại có thể phù hợp hơn cố xử lý một bối cảnh ngoài phạm vi hỗ trợ.

Chuẩn bị bộ thử để biết lỗi nằm ở đâu

Bắt đầu bằng một tác vụ hẹp như xác nhận thời gian gọi lại. Viết một phiên bản sạch với một người nói, rồi tạo các phiên bản nhiều người từ cùng mục tiêu đó. Giữ ổn định nội dung chính, cấu hình bot và cách chấm điểm giữa các lần thử. Khi mọi thứ cùng thay đổi, kết luận rằng lỗi do người thứ ba sẽ thiếu cơ sở.

Mỗi ca cần một phiếu ngắn gồm mục tiêu, vai trò người tham gia, lời dẫn, thông tin được phép thay đổi, điều bot không được tự kết luận và kết quả mong đợi. Không cần biến phiếu thử thành một kịch bản đọc cứng từng chữ. Cần giữ đủ cấu trúc để các lần thử còn so sánh được, đồng thời cho người kiểm thử nói tự nhiên.

Phân biệt âm thanh có thêm người nói với tiếng ồn thông thường. Tiếng quạt gây khó nghe, nhưng một giọng người nói “đồng ý” có thể gây thêm nhầm lẫn về ý định. Nên thử riêng từng yếu tố trước khi kết hợp. Khi dùng bản ghi hoặc người tham gia thật, chỉ sử dụng dữ liệu và hình thức ghi âm đã được cho phép.

Không chọn toàn ca dễ hoặc toàn ca đánh đố. Danh sách nên gồm tình huống thường gặp, tình huống có thể làm sai dữ liệu quan trọng và tình huống ngoài phạm vi mà bot cần biết dừng. Tỷ trọng do doanh nghiệp quyết định theo cuộc gọi của mình. Một bộ thử nội bộ không đại diện cho thị trường nếu chưa có cách lấy mẫu và phạm vi rõ ràng.

Chấm kết quả theo nghiệp vụ, không chỉ theo độ tự nhiên

Đội vận hành có thể chấm theo bốn lớp: giữ đúng thông tin, chọn phản ứng phù hợp, tạo đầu ra nhất quán và xử lý ngoại lệ đúng. Đây là khung đề xuất để tổ chức việc quan sát. Một ca có thể đạt ở lớp này nhưng chưa đạt ở lớp khác; không nên gộp mọi thứ vào một cảm giác chung rằng bot “nghe ổn”.

Với thông tin, đối chiếu người cung cấp, nội dung đã xác nhận và nội dung chưa rõ. Với phản ứng, xem bot có trả lời nhầm cuộc trao đổi riêng, hỏi lặp hoặc tự chốt khi còn mâu thuẫn không. Với đầu ra, đối chiếu câu chốt cuối với kết quả lưu và việc bàn giao. Với ngoại lệ, xem đường xử lý tiếp có được thực hiện đúng phạm vi đã thống nhất.

Nếu tính tỷ lệ đạt, mẫu số phải là số ca đã chạy đủ điều kiện chấm. Không tự bỏ những ca thất bại hoặc mất kết nối khỏi báo cáo mà không giải thích. Tách lỗi môi trường, lỗi cấu hình, lỗi hội thoại và lỗi dữ liệu khi có đủ bằng chứng phân loại. Các ca chưa xác định được nguyên nhân cần giữ riêng để rà soát.

Doanh nghiệp nên thống nhất trước những lỗi nghiêm trọng phải chặn mở rộng, chẳng hạn tự xác nhận sai lịch, làm thay đổi dữ liệu ngoài yêu cầu hoặc tiết lộ thông tin không đúng người. Không có một mức phần trăm đạt chung đủ để thay thế các điều kiện này. Một điểm trung bình đẹp vẫn có thể che đi lỗi mà quy trình không chấp nhận được.

Sửa lỗi rồi thử lại theo đúng điểm đã thay đổi

Khi phát hiện lỗi, lưu lại ca thử, thời điểm và cấu hình liên quan. Trước khi chỉnh, mô tả kỳ vọng bằng ngôn ngữ nghiệp vụ: “không chốt lịch khi hai người còn đưa thông tin khác nhau”, thay vì chỉ viết “bot chưa thông minh”. Mô tả cụ thể giúp đội nội dung, kỹ thuật và vận hành thống nhất vấn đề cần giải quyết.

Biện pháp sửa có thể là rút ngắn câu hỏi, thêm câu xác nhận, tách một nhánh, đổi thông báo chờ hoặc chuyển một tình huống sang nhân viên. Chọn cách nằm trong khả năng thực tế của sản phẩm. Nếu cần năng lực phân biệt người nói mà hệ thống chưa hỗ trợ, việc ghi nhận giới hạn và thay quy trình có thể thực tế hơn tiếp tục tinh chỉnh lời thoại.

Sau chỉnh sửa, chạy lại ca gây lỗi và những ca sạch có liên quan. Một thay đổi khiến bot thận trọng hơn có thể đồng thời làm tăng số câu hỏi xác nhận ở cuộc gọi đơn giản. Vì vậy phải xem cả lợi ích lẫn ảnh hưởng. Không dùng kết quả của cấu hình cũ để nghiệm thu cấu hình mới dù tên kịch bản vẫn giống nhau.

Khi chuẩn bị mở rộng, người phụ trách cần biết các giới hạn còn lại, cách nhận diện ngoại lệ và ai tiếp nhận chúng. Nếu muốn thử hai cách hỏi xác nhận, hãy dùng phương pháp phân nhóm và đo lường rõ ràng; có thể tham khảo bài A/B kịch bản Callbot: đo hiệu quả trước khi tăng ngân sách. Không xem một vài cuộc gọi thuận lợi là bằng chứng đủ cho mọi nhóm khách.

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

Có cần Callbot nhận diện danh tính bằng giọng nói không?

Không nhất thiết. Phân biệt một tình huống chưa rõ để hỏi lại khác với xác thực danh tính bằng giọng nói. Doanh nghiệp cần chọn năng lực phù hợp bài toán, kiểm tra sản phẩm có hỗ trợ hay không và dùng quy trình xác minh được phê duyệt khi thao tác đòi hỏi quyền hạn.

Chỉ đọc transcript có đủ để nghiệm thu không?

Chưa đủ cho những lỗi liên quan đến người nói, khoảng dừng và sự chen ngang. Transcript hữu ích để tìm đoạn cần xem, nhưng cần nghe bản ghi được phép sử dụng và đối chiếu dữ liệu đầu ra. Khi chỉ có bản chữ, hãy ghi rõ giới hạn của kết luận.

Phải chạy bao nhiêu cuộc mới kết luận được?

Số lượng phụ thuộc mục tiêu, mức rủi ro, độ đa dạng của tình huống và mức chắc chắn mong muốn. Bộ thử nhỏ giúp phát hiện lỗi rõ, chưa đủ để ước lượng tỷ lệ cho toàn bộ chiến dịch. Hãy ghi phạm vi thử và tránh công bố một tỷ lệ tổng quát từ mẫu tiện lợi.

Có nên dùng ví dụ trong bài làm bộ đề nghiệm thu luôn?

Có thể dùng làm khung khởi đầu, nhưng cần thay tác vụ, cách nói và kết quả mong đợi bằng bối cảnh doanh nghiệp. Bốn ví dụ đều là giả định, không phải dữ liệu khách hàng UCALL và không chứng minh chất lượng của một cấu hình cụ thể.

UCALL có thể được đưa vào quy trình này như thế nào?

Khi trao đổi với UCALL, hãy mang theo mục tiêu cuộc gọi, các tình huống nhiều người nói và yêu cầu bàn giao để xác nhận cấu hình phù hợp. Yêu cầu chạy thử trên phiên bản sẽ triển khai, kiểm tra kết quả và ghi rõ giới hạn hỗ trợ. Tìm hiểu giải pháp tại website UCALL; không coi tên mô hình hoặc một tính năng riêng lẻ là bảo đảm cho cả quy trình.