Một khách, một hồ sơ: liên kết hội thoại đa kênh trong Adahub

Một khách hỏi thông tin trên Facebook, trao đổi chi tiết qua Zalo rồi quay lại với một yêu cầu hỗ trợ. Nếu mỗi cuộc trò chuyện được giữ như một người hoàn toàn khác, đội ngũ có thể vừa chăm sóc trùng, vừa bỏ sót những thông tin đã được cung cấp. Trong báo cáo, số liên hệ tăng nhưng người quản lý chưa chắc biết doanh nghiệp đang có thêm khách thật hay chỉ thêm một kênh của khách cũ.

Roadmap Adahub CRM mô tả hướng liên kết hội thoại đa kênh với cùng một hồ sơ Liên hệ. Theo thiết kế, hội thoại gắn với khách qua định danh kênh; khi phát hiện dấu hiệu trùng, hệ thống đưa ra gợi ý để người dùng quyết định thay vì tự gộp chỉ dựa vào tên. Đây là định hướng sắp ra mắt, chưa phải xác nhận mọi khả năng đã được phát hành.

Bài viết tập trung vào nhận diện khách, chất lượng dữ liệu và bàn giao lịch sử. Phạm vi kênh, cách gộp, quyền thao tác và những dữ liệu được giữ lại cần được kiểm tra trên bản sản phẩm chính thức. Các ví dụ đều là tình huống giả định để doanh nghiệp chuẩn bị cách thử, không phải hồ sơ của khách hàng thật.

Adahub đã có hướng dẫn tạo và liên kết hồ sơ từ chat đa kênh. Bài này giới thiệu hướng bổ sung về đối chiếu định danh và quyết định xử lý hồ sơ trùng; không thay thế hướng dẫn đang công khai.

Một người có thể có nhiều định danh

Tên hiển thị trên mạng xã hội không phải lúc nào cũng giống tên trong hồ sơ mua hàng. Số điện thoại có thể dùng cho một nhóm người hoặc thay đổi theo thời gian. Một tài khoản chat cũng có thể được dùng để hỏi cho người khác. Vì vậy, “tên giống nhau” hoặc “có một thông tin trùng” chỉ là dấu hiệu để kiểm tra, không phải kết luận chắc chắn về danh tính.

Trong CRM, cần phân biệt người khách với định danh của từng kênh. Hồ sơ giúp tổ chức thông tin nghiệp vụ về người hoặc đầu mối liên hệ; hội thoại ghi nhận trao đổi trên một tài khoản cụ thể. Liên kết hai phần này làm lịch sử dễ tra cứu hơn, nhưng chỉ hữu ích khi mối liên hệ được xác nhận đúng.

Mục tiêu “một khách, một hồ sơ” vì thế không có nghĩa ép mọi thông tin gần giống về cùng một bản ghi. Mục tiêu là giảm hồ sơ trùng khi có đủ căn cứ, đồng thời giữ khả năng phân biệt những người khác nhau. Một lần hợp nhất nhầm có thể khiến nhân viên đọc thông tin của người này khi đang phục vụ người khác, tạo ra vấn đề lớn hơn việc phải tra cứu thêm một hồ sơ.

Liên kết hội thoại khác với gộp liên hệ

Liên kết hội thoại là xác định một cuộc trao đổi thuộc về hồ sơ nào. Gộp liên hệ là xử lý những bản ghi được xác nhận cùng đại diện một khách. Hai việc liên quan nhưng khác phạm vi tác động. Doanh nghiệp cần dạy nhân viên phân biệt chúng trước khi giao quyền sửa dữ liệu trên diện rộng.

Ví dụ giả định, một khách đã có hồ sơ và vừa nhắn ở một kênh mới. Nếu xác định được đúng người, việc cần làm có thể là liên kết hội thoại mới vào hồ sơ hiện có. Không nhất thiết phải tạo thêm hồ sơ rồi gộp ngay, đặc biệt nếu luồng thực tế của sản phẩm đã có cách liên kết phù hợp.

Ở tình huống khác, hai nhân viên đã tạo hai bản ghi của cùng khách từ các lần tiếp cận trước. Lúc này cần kiểm tra dữ liệu đang nằm ở từng bản ghi: thông tin nào mới, thông tin nào mâu thuẫn và công việc nào liên quan. Quyết định gộp phải xem xét dữ liệu nghiệp vụ, không chỉ tìm cách làm danh sách ngắn hơn.

Thiết kế dự kiến đặt người dùng ở bước quyết định

Theo roadmap, hệ thống có thể gợi ý liên hệ khi phát hiện một thông tin trùng như số điện thoại. Nhân viên chọn hồ sơ phù hợp, liên kết hội thoại có sẵn hoặc xử lý liên hệ trùng theo chức năng được hỗ trợ. Điểm cần giữ là gợi ý giúp tìm ứng viên; người vận hành vẫn phải kiểm tra trước khi chấp nhận.

Phần chi tiết liên hệ được định hướng có khối Chat đa kênh để liệt kê những hội thoại đã gắn với khách. Giá trị kỳ vọng là người tiếp nhận không cần tự đi tìm trên từng màn hình để dựng lại lịch sử. Tuy nhiên, danh sách hiển thị đầy đủ chỉ đáng tin khi quá trình liên kết và phân quyền đã được kiểm tra.

Một hồ sơ có nhiều hội thoại cũng không đồng nghĩa mọi người dùng đều nên thấy toàn bộ. Quyền xem cần theo vai trò, mục đích công việc và phạm vi được phép. Bài viết không mặc định hệ thống sẽ mở rộng quyền của nhân viên chỉ vì hội thoại được gắn vào cùng một khách.

Chuẩn bị căn cứ nhận diện trước khi gộp

Doanh nghiệp nên thống nhất những dữ liệu nào có thể hỗ trợ xác minh và mức tin cậy của chúng. Tên, số điện thoại, thông tin giao dịch hoặc nội dung trao đổi có thể là những căn cứ khác nhau tùy quy trình. Không nên quy định một thông tin luôn đủ cho mọi tình huống nếu thực tế doanh nghiệp có khách dùng chung số hoặc mua hộ.

Khi có mâu thuẫn, nên giữ lại câu hỏi cần làm rõ và chuyển người có trách nhiệm xem xét. Việc chưa gộp ngay không phải thất bại của quy trình; đó có thể là cách tránh đưa ra quyết định vượt quá bằng chứng. Nhân viên không nên sửa thông tin nguồn để làm cho hai bản ghi trông giống nhau chỉ nhằm vượt qua một bước kiểm tra.

Một bộ hướng dẫn ngắn có thể nêu các trường hợp thường gặp: tên giống nhưng số khác, số giống nhưng người liên hệ khác, hồ sơ cá nhân và đầu mối doanh nghiệp, hoặc khách thay đổi kênh. Cần dùng ví dụ giả định khi đào tạo để nhân viên hiểu cách suy xét mà không làm lộ dữ liệu thật ngoài phạm vi được phép.

Khi dữ liệu mâu thuẫn, chọn gì làm chuẩn?

Hai hồ sơ có thể có số điện thoại, người phụ trách hoặc trạng thái bán hàng khác nhau. Không nên mặc định bản tạo gần nhất luôn đúng hoặc bản có nhiều dữ liệu luôn nên được giữ. Cần xem nguồn, thời điểm xác nhận và ý nghĩa của thông tin trong quy trình đang vận hành.

Ví dụ giả định, hồ sơ cũ có địa chỉ dùng cho một lần giao hàng, còn hồ sơ mới có địa chỉ khách vừa cung cấp cho yêu cầu hiện tại. Cả hai thông tin có thể đúng ở những bối cảnh khác nhau. Cách tổ chức dữ liệu cần được xác định trước khi gộp, tránh biến một thay đổi theo giao dịch thành việc ghi đè toàn bộ lịch sử liên hệ.

Cũng cần kiểm tra các đối tượng liên quan như công việc, đơn hàng và yêu cầu hỗ trợ theo khả năng thực tế của sản phẩm. Bài viết không khẳng định cách chuyển từng loại liên kết sau khi gộp. Đó là một phần quan trọng của nghiệm thu: người dùng phải biết dữ liệu nào được giữ, dữ liệu nào cần xử lý riêng và làm sao nhận ra kết quả chưa như mong đợi.

Tình huống giả định: khách chuyển từ Facebook sang Zalo

Một khách đã hỏi dịch vụ trên Facebook nhưng chưa cung cấp đủ thông tin liên hệ. Vài ngày sau, người đó trao đổi qua Zalo và cho biết đã từng nhắn trước. Nhân viên không nên chỉ dựa vào tên tương tự để nối ngay hai lịch sử; cần đối chiếu những thông tin khách xác nhận trong phạm vi công việc.

Khi có đủ căn cứ, nhân viên chọn hồ sơ phù hợp và thực hiện liên kết theo chức năng được phát hành. Sau thao tác, họ kiểm tra cuộc hội thoại mới có xuất hiện ở đúng hồ sơ và không làm thay đổi nhầm dữ liệu người khác. Trước khi trả lời tiếp, đọc lại phần trao đổi cũ để biết câu hỏi nào đã được giải quyết và điều gì còn chờ.

Nếu phát hiện hai liên hệ thật sự trùng, người có quyền kiểm tra dữ liệu từng bản rồi mới gộp. Đầu việc này không nên được làm như thao tác dọn danh sách hàng loạt khi chưa có quy tắc. Nhóm cần biết cách lưu thông tin đối chiếu và xử lý khi kết quả không đúng, dựa trên khả năng thực tế được sản phẩm hỗ trợ.

Sau khi xử lý, người phụ trách cập nhật bước tiếp theo trong chăm sóc. Liên kết xong hội thoại chưa tự hoàn thành nhu cầu của khách. Giá trị thực tế xuất hiện khi nhân viên có thể tiếp tục trao đổi từ thông tin đã có, giảm hỏi lại và không để khách bị hai người liên hệ với nội dung mâu thuẫn.

Bàn giao khách cần bàn giao cả ngữ cảnh

Khi khách chuyển nhóm hoặc nhân viên nghỉ, một danh sách tên và số điện thoại chưa đủ để tiếp tục phục vụ. Người mới cần biết câu hỏi đang mở, cam kết đã đưa ra và kênh khách muốn sử dụng. Hội thoại được tổ chức theo hồ sơ có thể giúp tìm ngữ cảnh, nhưng nhóm vẫn cần quy định cách ghi phần việc cần tiếp tục.

Không phải mọi đoạn trò chuyện đều có cùng mức quan trọng. Một bản bàn giao có thể nêu những điều đã xác nhận và việc còn chờ, kèm vị trí tra cứu hội thoại liên quan theo quyền được cấp. Đây là đề xuất tổ chức thông tin; không nên coi một bản tóm tắt chưa được kiểm tra là bằng chứng thay thế cho nguồn gốc trao đổi.

Trước khi hoàn tất bàn giao, thử bằng tài khoản người nhận xem họ có thể mở hồ sơ và các phần cần dùng không. Một liên kết tồn tại nhưng người tiếp quản không có quyền đọc vẫn là một điểm nghẽn. Cần xử lý quyền theo quy trình đã được cho phép, không tự mở rộng phạm vi dữ liệu chỉ để làm thao tác thuận tiện hơn.

Kiểm thử bằng cả trường hợp dễ và trường hợp dễ nhầm

Ca thử đơn giản là một hồ sơ mẫu có thông tin nhận diện rõ và một hội thoại tương ứng. Kiểm tra cách chọn, liên kết và hiển thị lịch sử. Sau đó thêm một kênh khác để xem người dùng có nhận ra đúng khách và đúng cuộc trao đổi, thay vì chỉ quan sát số lượng hội thoại tăng.

Ca dễ nhầm gồm hai người trùng tên, hai hồ sơ có cùng một số liên hệ và một khách thay đổi thông tin. Người kiểm thử ghi rõ trường hợp nào được phép liên kết, trường hợp nào cần hỏi lại và trường hợp nào không nên gộp. Những kết quả mong đợi này phải được chốt trước để tránh hợp thức hóa một thao tác chỉ vì giao diện cho phép thực hiện.

Nếu có chức năng gộp, cần thử trên dữ liệu giả định đủ các đối tượng liên quan doanh nghiệp dùng. Kiểm tra sau thao tác bằng cách mở từng phần quan trọng, không chỉ xem thông báo thành công. Trước khi áp dụng vào dữ liệu thật, xác minh cách xử lý sai và phạm vi khôi phục với đội hỗ trợ sản phẩm.

Báo cáo khách hàng cũng cần hiểu lại đơn vị đếm

Khi giảm hồ sơ trùng, số liên hệ có thể giảm dù doanh nghiệp không mất khách. Nếu người quản lý chỉ xem tổng bản ghi, thay đổi này dễ bị đọc như sụt giảm dữ liệu. Nên phân biệt số hồ sơ, số hội thoại và số khách đã được xác minh theo quy tắc của doanh nghiệp.

Tương tự, một khách có nhiều hội thoại không nên được diễn giải ngay thành nhiều khách mới. Cách tính chuyển đổi và nguồn cần dựa trên định nghĩa đã thống nhất, đặc biệt khi khách chuyển kênh trong quá trình mua. Việc liên kết dữ liệu có thể hỗ trợ phân tích, nhưng không tự giải quyết mọi câu hỏi về phân bổ công lao giữa các kênh marketing.

Trong giai đoạn thử, có thể theo dõi số trường hợp trùng được phát hiện, số gợi ý bị từ chối và số lần phải sửa liên kết. Những con số này giúp cải thiện quy tắc và đào tạo. Không nên biến mục tiêu “ít hồ sơ trùng hơn” thành yêu cầu gộp nhanh bằng mọi giá, vì độ đúng của nhận diện mới là điều kiện để lịch sử có giá trị.

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

Hệ thống có tự gộp khách theo tên không?

Theo roadmap được dùng cho bài, thiết kế không tự gộp chỉ dựa vào tên mà đưa ra gợi ý để người dùng kiểm tra. Hành vi cụ thể cần được xác nhận trên bản phát hành thực tế.

Cùng số điện thoại có chắc cùng một người?

Không nên kết luận cho mọi trường hợp. Doanh nghiệp có thể gặp số dùng chung, người mua hộ hoặc dữ liệu cũ. Cần đối chiếu bối cảnh và những căn cứ phù hợp trước khi quyết định liên kết hay gộp.

Có thể bảo đảm mọi lịch sử đều được giữ sau gộp không?

Bài viết không đưa ra bảo đảm như vậy. Trước khi sử dụng, cần kiểm tra dữ liệu và liên kết mà sản phẩm hỗ trợ giữ lại, cách xử lý mâu thuẫn và phương án sửa sai trên dữ liệu mẫu.

Nên chuẩn bị gì ngay bây giờ?

Hãy chọn các tình huống nhận diện thường gặp, viết quy tắc xác minh và xác định người có quyền xử lý hồ sơ trùng. Khi tính năng ra mắt, dùng bộ tình huống đó để thử cùng Adahub trước khi làm sạch dữ liệu trên diện rộng.