Customer identity resolution giúp AI Agent nhận diện khách đa kênh ra sao?

Cùng một người có thể nhắn fanpage bằng tên hiển thị, gọi tổng đài bằng số điện thoại, đặt hàng trên website bằng email và chat Zalo bằng một tài khoản khác. Với con người, nhận ra đó là một khách thường nhờ trí nhớ và ngữ cảnh. Với AI Agent, việc đó phải được làm bằng quy tắc: khi nào hai dấu vết là một người, chắc chắn đến mức nào, và được dùng sự “chắc chắn” đó để làm gì.

Bài AI Agent đa kênh đã trình bày cách kết nối các kênh và nguyên tắc chỉ gộp khi có khóa đáng tin. Bài này đi sâu vào phần khó hơn phía sau: quy tắc khớp, ngưỡng tin cậy, lúc nào phải hỏi khách xác minh, cách gộp và tách hồ sơ có thể hoàn tác, và cách ngăn tình huống tệ nhất là agent đưa dữ liệu của người này cho người khác. Việc làm sạch dữ liệu CRM có sẵn là một đề tài riêng, xem bài AI làm sạch dữ liệu CRM.

1. Identity resolution là bài toán về rủi ro, không chỉ về dữ liệu

Customer identity resolution là quá trình quyết định các dấu vết khác nhau có thuộc về cùng một khách hay không, và nối chúng lại. Trong báo cáo marketing, nối nhầm hai khách chỉ làm lệch con số. Trong một AI Agent trả lời trực tiếp cho khách, nối nhầm có nghĩa là agent có thể nói với người lạ về đơn hàng, công nợ hay lịch hẹn của người khác. Vì vậy mức chắc chắn cần có phụ thuộc vào việc sẽ làm gì với kết quả khớp.

Một cách chia hữu ích là ba mức sử dụng. Mức chào hỏi: agent đoán đây có thể là khách cũ để gợi ý hoặc chuyển đúng nhân viên, không tiết lộ gì. Mức tra cứu: agent đọc dữ liệu cá nhân để trả lời, bắt buộc danh tính đã xác minh. Mức hành động: agent đổi lịch, hủy đơn, cập nhật thông tin, cần xác minh và có khi cần thêm xác nhận. Cùng một kết quả khớp có thể đủ cho mức thứ nhất nhưng không đủ cho mức thứ hai.

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

1. Khóa định danh

Liệt kê mọi khóa có thể có và xếp theo độ tin: mã khách hàng nội bộ, số điện thoại đã xác minh bằng mã OTP, email đã xác minh, tài khoản đăng nhập trên website hay ứng dụng, mã người dùng của từng nền tảng nhắn tin, số hợp đồng, mã đơn. Cùng một loại khóa có thể có hai độ tin khác nhau: số điện thoại khách tự gõ vào khung chat khác hẳn số điện thoại đã xác minh. Mỗi khóa cần ghi nguồn và thời điểm xác minh gần nhất.

2. Matching xác định

Khớp xác định nối hai hồ sơ khi một khóa đáng tin trùng khít sau khi chuẩn hóa (số điện thoại cùng định dạng, email viết thường). Đây là lựa chọn mặc định an toàn. Tuy vậy vẫn có bẫy: một số điện thoại dùng chung cho cả gia đình, email công ty dùng chung cho cả phòng mua hàng, số điện thoại đã đổi chủ. Bảng quy tắc nên liệt kê các khóa bị loại trừ khỏi khớp tự động, ví dụ số tổng đài của khách doanh nghiệp hay email dạng info@.

3. Matching xác suất

Khi không có khóa trùng khít, hệ thống có thể chấm điểm dựa trên nhiều tín hiệu: tên gần giống, cùng địa chỉ giao hàng, cùng thiết bị, cùng khung giờ nhắn, nội dung nhắc tới cùng một mã đơn. Mô hình ngôn ngữ có thể giúp đọc các tín hiệu lộn xộn như cách viết tên khác nhau, nhưng quyết định cuối nên dựa trên điểm và ngưỡng rõ ràng chứ không để mô hình tự phán. Nên có ba vùng: trên ngưỡng cao thì đề xuất gộp để người duyệt nhanh, giữa hai ngưỡng thì chỉ gắn nhãn “có thể là”, dưới ngưỡng thấp thì coi là khách khác.

4. Xác minh và consent

Nhận ra khách không đồng nghĩa với được phép dùng dữ liệu của khách. Trước khi đọc hay nói ra thông tin cá nhân, agent cần xác minh theo mức rủi ro: gửi mã tới số điện thoại đã lưu, hỏi thông tin chỉ chủ tài khoản biết, hoặc yêu cầu đăng nhập. Câu hỏi xác minh không được tự để lộ dữ liệu, ví dụ không hỏi “Có phải chị ở số 12 đường X không?”. Việc nối dữ liệu từ các kênh vào một hồ sơ cũng phải khớp với mục đích mà khách đã đồng ý; phần này được bàn kỹ ở bài quản lý consent khi AI Agent thu thập dữ liệu.

5. Hợp nhất hồ sơ

Gộp hồ sơ là thao tác có hậu quả lâu dài, nên cần luật rõ: hồ sơ nào làm gốc, trường nào lấy từ đâu khi hai bên khác nhau (thường ưu tiên giá trị đã xác minh và mới hơn), lịch sử hội thoại và đơn hàng được nối vào ra sao. Thay vì ghi đè, nên giữ liên kết giữa các hồ sơ con và một hồ sơ hợp nhất, để lúc cần có thể tháo ra. AI Agent chỉ nên tự gộp trong trường hợp khớp xác định; các trường hợp khác đi vào hàng chờ người duyệt kèm lý do và các tín hiệu đã dùng.

6. Tách hồ sơ

Gộp nhầm sẽ xảy ra, nên thiết kế cách tách ngay từ đầu. Hệ thống phải biết từng bản ghi (tin nhắn, đơn, ghi chú) ban đầu thuộc hồ sơ con nào để trả về đúng chỗ. Sau khi tách, cần tra lại nhật ký xem trong thời gian bị gộp, agent đã trả lời những gì và làm hành động nào dựa trên dữ liệu sai. Nếu đã có dữ liệu bị lộ cho nhầm người, sự việc phải đi theo quy trình sự cố dữ liệu chứ không chỉ sửa trong CRM.

7. CRM

CRM thường là nơi lưu hồ sơ hợp nhất cuối cùng, nên cần thống nhất ai được ghi: agent chỉ đề xuất liên kết hay được gộp trực tiếp, nhân viên sửa tay thì agent có được ghi đè không. Một lỗi hay gặp là agent gộp theo quy tắc của mình trong khi CRM lại có luật chống trùng riêng, hai bên kéo dữ liệu qua lại. Nên chọn một nơi quyết định việc gộp, nơi còn lại chỉ đọc kết quả. Các lỗi đồng bộ với CRM sau khi vận hành được phân tích riêng ở bài lỗi tích hợp AI Agent với CRM.

8. Audit

Mỗi lần khớp, gộp, tách hay xác minh cần để lại dấu vết: khóa và tín hiệu nào được dùng, điểm bao nhiêu, ai hoặc quy tắc nào quyết định, lúc nào. Nhật ký này giúp trả lời khi khách hỏi “sao bên anh biết tôi mua gì”, và là căn cứ để tinh chỉnh ngưỡng. Nguyên tắc ghi nhật ký cho agent nói chung có ở bài nhật ký AI Agent.

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

Bước 1: Kiểm kê khóa và đo mức trùng hiện có

Liệt kê các khóa ở từng kênh, tỷ lệ khách có khóa đã xác minh, và các trường hợp khóa dùng chung. Lấy một mẫu hồ sơ để người vận hành gắn nhãn thủ công “cùng một người” hay “khác người”; mẫu này là bộ đáp án để đo quy tắc sau này.

Bước 2: Viết bảng quy tắc khớp theo mức sử dụng

Với mỗi mức (chào hỏi, tra cứu, hành động), ghi rõ khóa hoặc điểm tối thiểu, cách xác minh bắt buộc và trường hợp phải chuyển nhân viên. Chủ dữ liệu khách hàng và bộ phận chăm sóc khách hàng cùng duyệt.

Bước 3: Thiết kế gộp, tách và hàng chờ duyệt

Dựng cấu trúc hồ sơ con và hồ sơ hợp nhất, thao tác gộp có lưu trạng thái trước, thao tác tách trả bản ghi về đúng nguồn, và giao diện để nhân viên duyệt các đề xuất gộp kèm tín hiệu. Quyền gộp và tách được cấp theo vai trò, theo cách mô tả ở bài phân quyền AI Agent.

Bước 4: Thử bằng ca khó rồi chỉnh ngưỡng

Chạy quy tắc trên bộ đáp án ở bước 1 và trên các ca cố ý gây khó: hai anh em cùng số điện thoại, khách đổi số, tên trùng khác người, người lạ nhắn kèm mã đơn của người khác. Chỉnh ngưỡng để tỷ lệ gộp nhầm thấp nhất có thể, chấp nhận bỏ sót nhiều hơn ở giai đoạn đầu.

4. Ví dụ giả định

Một chuỗi bán lẻ điện máy có AI Agent trả lời trên fanpage, Zalo và website. Một người nhắn fanpage: “Đơn tủ lạnh của tôi giao chưa?”. Tài khoản fanpage này chưa từng liên kết với hồ sơ nào, nhưng tên hiển thị trùng với một khách vừa đặt tủ lạnh trên website, cùng quận giao hàng.

Điểm khớp xác suất rơi vào vùng giữa. Agent không trả lời về đơn hàng mà xin số điện thoại đặt hàng và gửi mã xác minh tới số đó. Người nhắn nhập đúng mã, agent liên kết tài khoản fanpage vào hồ sơ và trả lời trạng thái đơn. Trong một ca khác, người nhắn cung cấp đúng mã đơn nhưng không nhận được mã xác minh vì số điện thoại là của vợ; agent không tiết lộ thông tin, chuyển sang nhân viên kèm ghi chú. Nhân viên gọi lại số đã lưu để xác nhận trước khi trả lời. Cả hai ca đều được ghi nhật ký với tín hiệu, điểm và cách xác minh đã dùng.

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

• Gộp nhầm hai người khiến agent tiết lộ dữ liệu cho người lạ
• Khóa dùng chung hoặc đổi chủ làm khớp xác định vẫn sai
• Xác minh quá phiền làm khách bỏ cuộc giữa chừng
• Hai hệ thống cùng tự gộp theo luật khác nhau

Không có quy tắc khớp nào đúng tuyệt đối. Điều doanh nghiệp chọn được là loại lỗi chấp nhận: bỏ sót (coi một khách là hai) thì khách phải xác minh lại, hơi phiền; gộp nhầm (coi hai khách là một) thì có thể lộ dữ liệu. Với agent trả lời trực tiếp, thường nên chấp nhận bỏ sót nhiều hơn. Xác minh cũng có giới hạn: mã gửi tới số điện thoại chỉ chứng minh người nhắn đang giữ điện thoại đó, không chứng minh họ là chủ hợp đồng. Với dữ liệu nhạy cảm như tài chính, sức khỏe, nên kết hợp thêm đăng nhập hoặc chuyển nhân viên.

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

Chủ dữ liệu khách hàng sở hữu bảng khóa, bảng quy tắc khớp và ngưỡng. Bộ phận chăm sóc khách hàng quyết định cách xác minh ở từng mức và xử lý các ca chuyển sang. Người vận hành dữ liệu duyệt hàng chờ gộp và thực hiện tách khi có phản ánh. Đội kỹ thuật chịu trách nhiệm cấu trúc hồ sơ, thao tác gộp tách có hoàn tác, đồng bộ với CRM và nhật ký. An toàn thông tin tham gia khi có nghi ngờ dữ liệu bị lộ do gộp nhầm.

Khi thêm kênh mới, đổi nhà cung cấp gửi mã xác minh hay chạy chiến dịch thu thập số điện thoại lớn, ngưỡng và bảng khóa cần được xem lại, vì phân bố dữ liệu đầu vào thay đổi.

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

• Tỷ lệ gộp nhầm phát hiện được qua lấy mẫu và qua phản ánh của khách
• Tỷ lệ khách cần xác minh và tỷ lệ bỏ cuộc giữa bước xác minh
• Thời gian chờ trung bình của hàng đề xuất gộp và tỷ lệ được duyệt
• Số lần tách hồ sơ và số sự cố dữ liệu liên quan tới nhận diện sai

Tỷ lệ “nhận ra khách” cao không phải lúc nào cũng tốt; nó có thể đến từ ngưỡng quá lỏng. Chỉ số này luôn phải đọc cùng tỷ lệ gộp nhầm. Tỷ lệ bỏ cuộc ở bước xác minh cho biết cách xác minh có quá nặng so với mức rủi ro hay không.

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

• Bảng khóa có độ tin, nguồn và danh sách khóa bị loại khỏi khớp tự động
• Quy tắc khớp tách theo mức chào hỏi, tra cứu và hành động
• Agent không tiết lộ dữ liệu cá nhân trước khi xác minh
• Gộp hồ sơ lưu trạng thái trước và tách lại được
• Chỉ một hệ thống có quyền quyết định gộp
• Mọi lần khớp, gộp, tách, xác minh đều có nhật ký

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

Khớp xác định và khớp xác suất khác nhau thế nào? Khớp xác định chỉ nối hai hồ sơ khi một khóa đáng tin trùng khít, như số điện thoại đã xác minh hay mã khách hàng. Khớp xác suất chấm điểm dựa trên nhiều tín hiệu gần giống nhau như tên, email, địa chỉ, thiết bị. Khớp xác định an toàn hơn; khớp xác suất bắt được nhiều hơn nhưng phải có ngưỡng và người duyệt.

AI Agent có nên tự gộp hai hồ sơ khách hàng không? Chỉ nên tự gộp khi khớp xác định bằng khóa đã xác minh. Với khớp xác suất, agent có thể dùng tạm liên kết trong phiên để hỏi đúng câu, nhưng việc gộp vĩnh viễn nên chờ người duyệt hoặc chờ khách tự xác minh, vì gộp nhầm rất khó tách lại sạch.

Khi nào AI Agent phải hỏi khách xác minh danh tính? Trước khi đưa ra bất kỳ thông tin cá nhân nào như đơn hàng, công nợ, lịch hẹn, hợp đồng, và trước khi thực hiện hành động trên tài khoản. Nhận ra khách qua số điện thoại hay tài khoản mạng xã hội chỉ đủ để chào và gợi ý, chưa đủ để tiết lộ dữ liệu.

Gộp nhầm hồ sơ khách hàng thì xử lý thế nào? Hệ thống phải lưu trạng thái trước khi gộp để tách lại được, kèm nhật ký bản ghi nào đã chuyển sang đâu. Sau khi tách, cần rà xem agent đã trả lời hoặc hành động gì dựa trên hồ sơ gộp nhầm, và thông báo cho khách bị ảnh hưởng theo quy trình sự cố dữ liệu.

Kết luận

Customer identity resolution cho AI Agent là việc chọn đúng mức chắc chắn cho đúng việc: đoán để chào hỏi, xác minh để tra cứu, xác minh chặt hơn để hành động. Quy tắc khớp rõ ràng, ngưỡng có dữ liệu kiểm chứng, gộp và tách có hoàn tác cùng nhật ký đầy đủ giúp agent nhận ra khách trên nhiều kênh mà không đánh đổi bằng rủi ro trả lời nhầm người.

Trao đổi với Naventic để thiết kế quy tắc nhận diện khách cho AI Agent đa kênh. Đọc thêm: AI Customer Support.