Trên trang này ↓
Một khách hàng có thể xuất hiện ba lần trong cùng hệ thống. Sales tạo hồ sơ từ số điện thoại trên Zalo, form website tạo thêm bản ghi bằng email công việc, rồi kế toán nhập một file có tên công ty viết khác. Nếu giữ nguyên, lịch sử chăm sóc và giao dịch bị chia nhỏ. Nếu gộp vội, đội có thể nối nhầm hai người cùng tên hoặc ghi đè thông tin mới bằng dữ liệu cũ.
Chức năng hợp nhất hồ sơ vì thế không nên được mô tả bằng một nút “Gộp”. Đội sản phẩm cần thiết kế cả chuỗi quyết định: tìm ứng viên, đối chiếu điểm giống và khác, chọn dữ liệu được giữ, chuyển quan hệ liên quan, xác nhận kết quả và chuẩn bị đường khôi phục. Đây là bài toán về tính toàn vẹn dữ liệu trước khi là bài toán giao diện.
Khi nào hai hồ sơ nên vào hàng chờ kiểm tra?
Khóa định danh và tín hiệu gợi ý không giống nhau. Một mã khách hàng do hệ thống cấp có thể là khóa ổn định trong phạm vi một nguồn. Tên, số điện thoại, email và công ty chỉ là tín hiệu. Chúng có thể thay đổi, bị nhập sai, được dùng chung hoặc xuất hiện ở nhiều định dạng.
- Form website: khách dùng email công việc nhưng để số điện thoại cá nhân đã có trong CRM.
- Sales nhập tay: tên được viết tắt, số điện thoại có hoặc không có mã quốc gia.
- Nhập từ CSV: một hàng có mã công ty cũ, hàng khác dùng tên pháp lý mới.
- Tích hợp bên ngoài: cùng một người có mã riêng ở hệ thống bán hàng và hệ thống hỗ trợ.
Phân biệt khóa định danh và tín hiệu gợi ý
| Tình huống | Cách xử lý phù hợp | Lý do |
|---|---|---|
| Cùng mã khách hàng trong cùng một nguồn tin cậy | Có thể đề nghị hợp nhất với bản xem trước | Mã có quy tắc cấp và phạm vi rõ |
| Cùng email, khác tên hoặc công ty | Đưa vào hàng chờ kiểm tra | Email có thể được chuyển tiếp hoặc dùng chung |
| Tên gần giống, số điện thoại khác | Không tự động gộp | Khả năng trùng người chưa đủ rõ |
| Cùng công ty, khác người liên hệ | Giữ hai hồ sơ, liên kết cùng tổ chức nếu cần | Hai cá nhân không phải một khách hàng duy nhất |
Chọn hồ sơ chính và quy tắc giữ dữ liệu
“Giữ bản mới nhất” nghe đơn giản nhưng thường không đủ. Hồ sơ mới có thể chỉ chứa email vừa nhập, trong khi hồ sơ cũ giữ địa chỉ giao hàng đã được xác nhận. Đội nên đặt quy tắc theo từng trường, thay vì chọn một bản ghi rồi ghi đè toàn bộ bản còn lại.
Chọn giá trị theo nguồn, thời điểm và xác nhận
| Thông tin định danh | Ưu tiên giá trị đã được người phụ trách xác nhận hoặc lấy từ nguồn có quy tắc kiểm tra rõ. |
|---|---|
| Thông tin liên hệ | Cho phép giữ nhiều email hoặc số điện thoại nếu sản phẩm hỗ trợ, đồng thời đánh dấu giá trị chính. |
| Trạng thái chăm sóc | Không chọn theo thời điểm đơn thuần. Phải theo luồng nghiệp vụ, chẳng hạn khách đang đàm phán không quay về trạng thái lead mới. |
| Người phụ trách | Hiển thị xung đột để quản lý sales quyết định, tránh tự chuyển khách giữa hai nhân viên. |
| Ghi chú tự do | Giữ cả hai theo thứ tự thời gian, kèm nguồn tạo. Không ghép chuỗi rồi làm mất ngữ cảnh. |
Với đội đang nhập dữ liệu từ file, quy tắc phát hiện trùng nên được thống nhất với luồng trong bài Cách thiết kế chức năng nhập dữ liệu CSV cho MVP. Một lần nhập không nên âm thầm tạo thêm hồ sơ nếu hệ thống đã phát hiện ứng viên có độ tương đồng cao. Ngược lại, màn hình nhập cũng không nên tự gộp trước khi người dùng xem các trường mâu thuẫn.
Dữ liệu liên quan phải được chuyển như thế nào?
Hồ sơ khách hàng thường là điểm nối của nhiều dữ liệu khác. Xóa một bản ghi trùng ngay sau khi sao chép tên và email có thể làm rơi các quan hệ mà giao diện không hiển thị: mã giảm giá đã dùng, cuộc hẹn sắp tới, người phụ trách, quyền xem, tệp hợp đồng hoặc mã tham chiếu của hệ thống bên ngoài.
- Đơn hàng và hóa đơn vẫn truy cập được từ hồ sơ chính.
- Lịch hẹn, việc follow-up và nhắc việc giữ nguyên người phụ trách cùng thời hạn.
- Ghi chú, tệp và lịch sử trao đổi giữ nguồn tạo và thứ tự thời gian.
- Thẻ, phân khúc và trạng thái không tạo ra tổ hợp trái quy tắc nghiệp vụ.
- Quyền truy cập sau hợp nhất không rộng hơn quyền trước đó.
- Mã của hệ thống tích hợp được lưu để đồng bộ tiếp, không bị thay bằng một giá trị ngẫu nhiên.
Nếu sản phẩm đang cho phép xóa vĩnh viễn, cần tách thao tác hợp nhất khỏi thao tác xóa. Bài Cách thiết kế chức năng xóa dữ liệu an toàn cho MVP giải thích rõ khác biệt giữa ẩn, lưu trữ và xóa. Với hợp nhất hồ sơ, bản nguồn nên được lưu ở trạng thái có thể truy vết trong một khoảng thời gian đã định, thay vì biến mất ngay.
Quy trình hợp nhất từ bản xem trước đến hoàn tất
- Tạo ứng viên.
Hệ thống ghi rõ tín hiệu khiến hai hồ sơ được đưa vào hàng chờ, đồng thời loại các cặp đã bị người phụ trách xác nhận là khác nhau.
- Hiển thị điểm giống và khác.
Bản xem trước đặt từng trường cạnh nhau, cho biết nguồn, thời điểm cập nhật và trạng thái xác nhận.
- Chọn hồ sơ chính.
Người phụ trách chọn bản ghi sẽ giữ URL hoặc mã nội bộ, sau đó giải quyết từng trường có xung đột.
- Xem tác động lên dữ liệu liên quan.
Hệ thống đếm theo loại quan hệ và cảnh báo mục không thể chuyển, nhưng không dùng con số tổng để che chi tiết lỗi.
- Thực hiện như một giao dịch.
Nếu một bước chuyển thất bại, toàn bộ thao tác phải dừng hoặc quay về trạng thái trước đó. Không để nửa số đơn hàng ở hồ sơ mới và nửa còn lại ở hồ sơ cũ.
- Kiểm tra và mở khả năng khôi phục.
Sau hợp nhất, hệ thống chạy kiểm tra toàn vẹn, lưu người thực hiện cùng thời điểm và cho phép hoàn tác theo chính sách đã chốt.
Hệ thống xử lý gì, con người quyết định gì?
Ranh giới trách nhiệm trong luồng hợp nhất
Hệ thống có thể chuẩn bị
| Người phụ trách phải quyết định
|
AI có thể hỗ trợ xếp hạng ứng viên hoặc giải thích điểm tương đồng, nhưng không nên tự xác nhận danh tính khi sai sót có thể ảnh hưởng đến giao dịch và cam kết với khách hàng. Quy tắc duyệt cần dựa trên mức rủi ro của dữ liệu, không dựa trên việc hệ thống dùng AI hay điều kiện cố định.
Checklist nghiệm thu chức năng hợp nhất hồ sơ
- Cặp hồ sơ chỉ vào hàng chờ khi có lý do hiển thị được cho người kiểm tra.
- Bản xem trước cho thấy mọi trường mâu thuẫn, nguồn và thời điểm cập nhật.
- Người dùng có thể giữ nhiều giá trị hợp lệ thay vì buộc ghi đè một trường.
- Đơn hàng, hóa đơn, ghi chú, lịch hẹn, tệp và quyền được kiểm tra riêng.
- Thao tác thất bại giữa chừng không tạo trạng thái dữ liệu nửa cũ, nửa mới.
- Hồ sơ nguồn không còn xuất hiện trong tìm kiếm thông thường nhưng vẫn truy vết được.
- Khôi phục đưa cả trường dữ liệu và quan hệ liên quan về đúng trạng thái trước đó.
- Test bao gồm hồ sơ cùng tên nhưng khác người, email dùng chung và dữ liệu từ hai nguồn mâu thuẫn.
Đội có thể dùng khung trong bài Quy trình chuẩn bị dữ liệu và tiêu chí nghiệm thu sản phẩm để tạo bộ mẫu trước khi chạy trên dữ liệu thật. Bộ test nên có cả trường hợp được gộp, phải hỏi thêm và bị từ chối.
Khi quy tắc đã rõ, Auranium có thể cùng đội rà nguồn dữ liệu, viết đặc tả hợp nhất, chuẩn bị bộ test và xác định phạm vi phù hợp cho phiên bản đầu tiên. Nếu cần làm rõ nên sửa quy trình hay xây chức năng, hãy bắt đầu từ dịch vụ Product Consultant; khi phạm vi đã đủ chắc để phát triển, Product Development có thể chuyển đặc tả thành sản phẩm chạy thật.
