Case: Biến hơn 500 hồ sơ LarkBase thành hàng đợi dữ liệu cần xử lý

TL;DR: Một doanh nghiệp dịch vụ có hơn 500 hồ sơ trên LarkBase, nhưng đội vận hành không biết hồ sơ nào thiếu gì và ai phải bổ sung. Diginno dựng một lớp rà soát riêng: hệ thống gắn tag lỗi cụ thể, phân trạng thái xử lý, ghi ngày kiểm tra và hướng dẫn ngắn cho từng hồ sơ. AI chỉ xử lý phần mơ hồ; việc kiểm tra ô trống do code đảm nhiệm để kết quả ổn định và tiết kiệm chi phí.

ℹ️ Info: Case thật, đã ẩn danh. Ảnh minh hoạ trong bài được dựng lại bằng dữ liệu giả; không sử dụng tên, số điện thoại, đường dẫn hệ thống hay dữ liệu thật của khách hàng.

Hệ thống thực tế trông như thế nào?

Ảnh dưới đây là màn hình audit sau khi chạy backfill. Ảnh đã được cắt bỏ cột định danh, URL hệ thống và làm mờ thời gian triển khai; nội dung còn lại chỉ thể hiện các field audit và trạng thái xử lý.

Vấn đề của hơn 500 hồ sơ là gì?

Vấn đề không phải là doanh nghiệp không có dữ liệu. Vấn đề là dữ liệu đã có nhưng không đủ tin cậy để vận hành.

Các hồ sơ nằm chung trong một bảng LarkBase. Có hồ sơ thiếu số điện thoại, có hồ sơ thiếu trạng thái, có hồ sơ thiếu người phụ trách, có hồ sơ thiếu cùng lúc nhiều thông tin. Muốn kiểm tra, một người phải mở từng dòng, đọc nhiều cột rồi tự quyết định nên nhắc ai.

Hệ quả vận hành rất cụ thể:

• Sale không có một danh sách rõ ràng về hồ sơ cần bổ sung.
• Quản lý khó phân biệt hồ sơ thật sự đầy đủ với hồ sơ chỉ “trông có vẻ đủ”.
• Báo cáo phía sau có thể sai vì trường phân loại hoặc trạng thái bị bỏ trống.
• Mỗi lần tổng vệ sinh dữ liệu lại phải làm thủ công từ đầu.
• Người nhập liệu chỉ nhận lời nhắc chung chung, không biết chính xác phải sửa gì.

Vì sao không giao toàn bộ việc kiểm tra cho AI?

Vì AI không phải công cụ tốt nhất để kiểm tra một ô có rỗng hay không. Code làm việc đó chính xác hơn, nhanh hơn và rẻ hơn.

Diginno tách quy tắc thành ba lớp:

Quyết định này quan trọng vì nó ngăn hệ thống “thông minh quá mức”: AI không tự bịa dữ liệu, không tự điền field nghiệp vụ và không được tạo tag ngoài danh sách đã duyệt.

Hàng đợi xử lý được thiết kế như thế nào?

Thay vì sửa bảng đang dùng, hệ thống bổ sung một nhóm field audit riêng và đặt liền nhau để người vận hành đọc từ trái sang phải:

Một view audit mới chỉ hiển thị những hồ sơ cần hành động. Đội Sale không còn phải tự lọc cả bảng; họ mở view và thấy ngay:

1. Hồ sơ nào cần xử lý.
2. Thiếu chính xác trường nào.
3. Ai chịu trách nhiệm bổ sung.
4. Hồ sơ đã được rà soát lúc nào.

Quy trình triển khai đã giảm rủi ro ra sao?

Hệ thống không được tự động hoá ngay từ ngày đầu. Diginno dùng quy trình hai giai đoạn để tránh nhân rộng một quy tắc sai.

Bước 1: Đọc schema và lấy mẫu dữ liệu

Kiểm tra kiểu field thật trên LarkBase và đọc một nhóm hồ sơ đại diện. Text rỗng, danh sách rỗng và liên kết rỗng không được đánh đồng với nhau.

Bước 2: Chạy audit local ở chế độ dry-run

Xuất trước kết quả dự kiến theo dạng hồ sơ → tag → trạng thái → ghi chú. Chưa ghi gì vào Base khách hàng.

Bước 3: Chốt rule với người phụ trách nghiệp vụ

Phân biệt field luôn bắt buộc, field chỉ bắt buộc theo điều kiện và trường hợp cần quản lý xác nhận.

Bước 4: Ghi thử một nhóm nhỏ

Chỉ cập nhật các field audit trên một số hồ sơ, sau đó đọc lại bằng API để đối chiếu kết quả.

Bước 5: Backfill và chạy định kỳ

Sau khi rule ổn định, workflow n8n quét hồ sơ mới hoặc hồ sơ vừa sửa, thay vì quét lại toàn bộ bảng mỗi lần.

Kết quả vận hành nhìn thấy được là gì?

Lượt backfill đầu tiên đã rà soát hơn 500 hồ sơ. Kết quả phân luồng:

Những lỗi xuất hiện nhiều nhất là thiếu trạng thái nghiệp vụ, người phụ trách, phương thức xử lý và thông tin liên hệ. Ngoài ra, khoảng 11% hồ sơ được gắn cờ nghi rác để kiểm tra, gồm bản ghi gần như trống, số điện thoại trùng và dữ liệu test/demo. Cờ này chỉ phục vụ rà soát, không kích hoạt xoá tự động.

Sự thay đổi quan trọng không nằm ở một dashboard đẹp. Nó nằm ở việc biến câu hỏi mơ hồ “data có sạch không?” thành một hàng đợi công việc có thể giao và theo dõi:

• Hồ sơ đủ dữ liệu được tách khỏi hồ sơ cần bổ sung.
• Mỗi lỗi thiếu dữ liệu có tag cụ thể để lọc và thống kê.
• Bộ phận xử lý và quản lý có trạng thái riêng.
• Workflow chỉ ghi vào field audit, không ghi đè dữ liệu nghiệp vụ.
• Hệ thống không tự động xoá hồ sơ nghi rác.

Workflow production chạy định kỳ ngoài giờ làm việc và chỉ quét lại hồ sơ mới hoặc vừa thay đổi. Lượt quét toàn bộ ban đầu được chia thành 26 batch; chi phí model khoảng 0,0065 USD vì phần kiểm tra xác định được xử lý bằng code và dữ liệu gửi cho AI đã được tối giản.

⚠️ Warning: Các tỷ lệ được làm tròn và thông tin nhận diện đã được loại bỏ. Case này chưa công bố số giờ tiết kiệm hoặc tỷ lệ giảm lỗi vì chưa có đo lường trước–sau đủ dài. Diginno chỉ nêu những gì đã kiểm chứng trên hệ thống, không quy đổi thành ROI giả định.

Tại sao phải tách dữ liệu thiếu và dữ liệu nghi rác?

Vì hai nhóm này dẫn tới hai hành động hoàn toàn khác nhau.

• Thiếu dữ liệu: còn có thể giao cho Sale hoặc bộ phận liên quan bổ sung.
• Nghi rác: cần con người kiểm tra trước khi quyết định giữ, gộp hay xoá.

Nếu trộn hai nhóm vào cùng một cột, một thao tác lọc sai có thể đưa hồ sơ hợp lệ vào danh sách xoá. Vì vậy, cờ nghi rác phải nằm ở field riêng và không có bước tự động xoá record.

Doanh nghiệp nào nên làm audit dữ liệu kiểu này?

Mô hình phù hợp khi doanh nghiệp đã dùng LarkBase cho CRM, nhân sự, đơn hàng, tài chính hoặc hồ sơ vận hành và gặp ít nhất hai dấu hiệu sau:

• Báo cáo thường xuyên xuất hiện mục “không xác định”.
• Nhân sự phải nhắn nhau hỏi hồ sơ còn thiếu gì.
• Cùng một loại dữ liệu nhưng mỗi người nhập một kiểu.
• Có hàng trăm bản ghi cũ nhưng không ai dám dọn.
• Workflow phía sau hay lỗi vì field đầu vào bị bỏ trống.
• Quản lý muốn giao trách nhiệm làm sạch dữ liệu theo bộ phận.

Bài học rút ra là gì?

Dữ liệu sạch không đến từ một lần “tổng vệ sinh”. Nó đến từ một cơ chế lặp lại được: rule rõ, hàng đợi rõ, người xử lý rõ và lịch kiểm tra rõ.

AI có ích nhất khi được đặt đúng chỗ. Để code xử lý điều chắc chắn; để AI hỗ trợ phần ngôn ngữ và trường hợp mơ hồ; để con người giữ quyền quyết định với dữ liệu nghi rác. Đó là cách xây hệ thống gọn gàng mà vẫn vận hành an toàn.