Twenty: chuẩn hóa dữ liệu khách trước khi đưa AI vào CRM
Twenty là CRM mã nguồn mở đang xuất hiện trên GitHub Trending. Công cụ hướng đến đội ngũ kỹ thuật muốn tự thiết kế dữ liệu, chế độ xem, workflow và khả năng AI theo quy trình riêng.
Một khách hỏi giá qua Zalo, người khác để lại nhu cầu trên Facebook, cuộc gọi với đại lý lại nằm trong sổ tay của sales. Đến lúc cần gửi báo giá, nhắc lại khách hay xử lý khiếu nại, cả đội phải hỏi nhau: ai đang phụ trách và khách đã được tư vấn gì?
Đó là bài toán CRM cần giải quyết trước khi nói đến AI. Dữ liệu khách chưa thống nhất thì AI có thể viết tin nhắn trôi chảy, nhưng vẫn sai người, sai ngữ cảnh hoặc sai chính sách.
Twenty là một CRM mã nguồn mở, được dự án giới thiệu như một lựa chọn mở thay cho Salesforce và được thiết kế cho AI. Dự án đang xuất hiện trên GitHub Trending, với 58.785 sao tại thời điểm ghi nhận.
Điểm đáng chú ý của Twenty không chỉ là AI, mà là định hướng để đội kỹ thuật xây dựng CRM theo dữ liệu và quy trình thực tế của doanh nghiệp.
Twenty có gì đáng chú ý với sales và CSKH?
Theo README, Twenty cung cấp các thành phần cho CRM hiện đại như:
Đối tượng dữ liệu (objects)
Chế độ xem (views)
Workflow
Agent
Khả năng mở rộng bằng mã nguồn
Điều này phù hợp với doanh nghiệp có quy trình không hoàn toàn giống mẫu CRM có sẵn. Thay vì chỉ theo dõi tên, số điện thoại và cơ hội bán hàng, đội ngũ có thể cùng bộ phận kỹ thuật thiết kế thêm các thông tin cần quản lý, chẳng hạn:
Nguồn lead: Zalo, Facebook, website, đại lý…
Nhóm khách: khách lẻ, doanh nghiệp, khách cần chăm sóc lại.
Trạng thái xử lý: mới nhận, đã liên hệ, đang báo giá, chờ phản hồi, hoàn tất.
Lý do chưa chốt: giá, thời gian giao, chưa đúng nhu cầu, chưa có ngân sách.
Ngày cần follow-up và người phụ trách.
Kết quả cuộc gọi, yêu cầu hỗ trợ hoặc mức độ ưu tiên của khiếu nại.
Với sales, điều quan trọng là cả đội thống nhất được: một lead cần có những thông tin nào trước khi chuyển người xử lý.
Với CSKH, hồ sơ khách được cập nhật nhất quán sẽ giúp nhân viên nắm bối cảnh trước khi phản hồi, hạn chế việc khách phải kể lại vấn đề từ đầu.
> Lưu ý: Twenty hướng nhiều đến đội ngũ kỹ thuật. Nhân viên sales hoặc CSKH có thể sử dụng workspace đã được thiết lập, nhưng việc tự thiết kế cấu trúc dữ liệu, logic và ứng dụng mở rộng sẽ cần người có chuyên môn kỹ thuật.
Cách thử Twenty: bắt đầu từ một luồng công việc
README nêu ba hướng triển khai:
Dùng bản cloud tại twenty.com.
Xây ứng dụng bằng Twenty CLI.
Tự vận hành trên hạ tầng riêng bằng Docker Compose.
Với đội kinh doanh muốn đánh giá mức độ phù hợp, bản cloud là điểm khởi đầu đơn giản hơn. Dự án cho biết người dùng có thể tạo workspace trong chưa đến một phút mà không phải tự quản lý hạ tầng.
Đừng bắt đầu bằng việc nhập toàn bộ dữ liệu khách hàng. Hãy chọn một luồng công việc nhỏ nhưng đang gây vướng.
Ví dụ:
Lead từ Facebook cần được gọi lại trong ngày.
Khách đã nhận báo giá nhưng chưa phản hồi.
Khiếu nại sau bán cần được phân loại và chuyển đúng người.
Gợi ý quy trình thử nghiệm
Chọn một luồng duy nhất
Chỉ xử lý một loại lead hoặc một nhóm yêu cầu hỗ trợ trong giai đoạn đầu.
Chốt các trường bắt buộc
Có thể bắt đầu với nguồn khách, nhu cầu, trạng thái, người phụ trách, lần liên hệ gần nhất và hành động tiếp theo.
Định nghĩa rõ từng trạng thái
“Đã liên hệ” là đã gọi thành công, đã gửi tin hay khách đã phản hồi? Cả đội cần hiểu giống nhau.
Tạo chế độ xem theo vai trò
Sales có thể tập trung vào khách cần follow-up; trưởng nhóm xem các cơ hội đang chờ xử lý; CSKH xem các case chưa có phản hồi.
Chạy thử trên dữ liệu được phép sử dụng
Không nên đưa toàn bộ danh sách khách vào một hệ thống mới ngay từ đầu.
Đánh giá sau một vòng làm việc
Nhân viên có biết việc tiếp theo là gì không? Quản lý có nhìn thấy chỗ tắc không? Khách có phải lặp lại thông tin không?
Mục tiêu đầu tiên không phải là dựng chatbot trả lời khách. Mục tiêu là khi mở hồ sơ khách, nhân viên biết ngay:
Khách là ai?
Đang ở bước nào?
Lần gần nhất đội đã trao đổi gì?
Việc tiếp theo thuộc về ai?
“Thiết kế cho AI” nên hiểu thế nào?
Twenty cho biết nền tảng có workflow, agent và hướng dẫn phát triển cho objects, views, agents cùng logic functions. Đây là các thành phần để đội kỹ thuật xây luồng làm việc và khả năng AI theo nhu cầu riêng.
Với sales và CSKH, AI nên hỗ trợ chuẩn bị công việc, thay vì tự ra quyết định thay con người.
Một số tình huống có thể cân nhắc áp dụng sau khi dữ liệu đã được chuẩn hóa:
Tóm tắt ghi chú sau cuộc gọi để nhân viên kiểm tra trước khi lưu.
Nhắc các thông tin còn thiếu trước khi chuyển lead.
Soạn nháp tin nhắn follow-up dựa trên lịch sử trao đổi.
Hỗ trợ phân loại yêu cầu để chuyển đúng nhóm xử lý.
Nhắc người phụ trách xem lại các khách đang chờ hành động.
Điểm quan trọng là luôn có bước kiểm tra của con người. AI có thể soạn nháp, nhưng nhân viên cần duyệt trước khi gửi. AI có thể gắn nhãn, nhưng các case nhạy cảm vẫn cần trưởng nhóm hoặc người có thẩm quyền xem lại.
Mẫu prompt để soạn nháp follow-up
Bạn có thể dùng mẫu dưới đây với một công cụ AI phù hợp, sau khi đã ẩn hoặc thay thế dữ liệu cá nhân không cần thiết:
text
Bạn là trợ lý sales.
Dựa trên ghi chú CRM dưới đây, hãy soạn một tin nhắn follow-up lịch sự bằng tiếng Việt.
<loại khách>: <khách lẻ/đại lý/khách doanh nghiệp>
<nhu cầu khách>: <nhu cầu>
<trạng thái hiện tại>: <trạng thái>
<lần trao đổi gần nhất>: <ghi chú>
<chính sách và mức giá đã được duyệt>: <thông tin đã kiểm tra>
Yêu cầu:
Không tự bịa giá, ưu đãi, thời hạn hay cam kết giao hàng.
Nếu thiếu thông tin, ghi rõ phần cần nhân viên xác nhận.
Giọng điệu lịch sự, ngắn gọn.
Kết thúc bằng một câu hỏi để khách dễ phản hồi.
Ví dụ bản nháp có thể là:
> Dạ em chào anh/chị, em xin phép hỏi mình đã xem thông tin về <sản phẩm/dịch vụ> chưa ạ? Nếu cần, em có thể kiểm tra lại phương án phù hợp với nhu cầu của mình. Anh/chị đang ưu tiên về <tiêu chí> hay thời gian nhận hàng ạ?
Trước khi gửi, nhân viên vẫn cần kiểm tra giá, điều kiện giao hàng, ưu đãi và chính sách đang áp dụng. Một câu “em sẽ kiểm tra lại và phản hồi” tốt hơn nhiều so với một cam kết sai.
Trường hợp nào cần chuyển cho người thật?
Không nên để AI hoặc workflow tự xử lý đến cùng trong các tình huống như:
Khách khiếu nại gay gắt hoặc có nguy cơ hủy hợp đồng.
Yêu cầu hoàn tiền, bồi thường hoặc thay đổi điều khoản.
Báo giá cho khách doanh nghiệp, đại lý hoặc đơn hàng có điều kiện đặc biệt.
Khách hỏi thông tin mà hệ thống chưa có dữ liệu chắc chắn.
Có dấu hiệu nhầm khách, nhầm lịch sử trao đổi hoặc nhầm sản phẩm.
Để bàn giao nhanh hơn, nhân viên có thể chuẩn hóa ghi chú theo mẫu:
text
Loại yêu cầu: <bán hàng/hỗ trợ/khiếu nại>
Mức độ ưu tiên: <thấp/trung bình/cao>
Khách đang cần gì:
Thông tin đã xác nhận:
Thông tin cần kiểm tra lại:
Việc cần người phụ trách quyết định:
Bản nháp phản hồi lịch sự:
Nguyên tắc là không để AI tự đề xuất hoàn tiền, ưu đãi, mức giá hoặc cam kết ngoài thông tin đã được kiểm tra.
Đừng để CRM thành điểm rủi ro dữ liệu
CRM tập trung nhiều dữ liệu khách hàng, vì vậy doanh nghiệp nên kiểm soát rõ ai được xem, sửa và xuất dữ liệu.
Khi dùng AI để thử prompt hoặc tóm tắt, không nên đưa vào những thông tin không cần thiết như số giấy tờ, địa chỉ chi tiết, hợp đồng hoặc ảnh giấy tờ. Có thể thay bằng các biến như <tên khách>, <mã đơn> và <nội dung đã ẩn dữ liệu cá nhân>.
Việc cấp quyền cũng nên theo vai trò công việc: nhân viên chỉ thấy thông tin cần để xử lý, còn các dữ liệu hoặc quyết định nhạy cảm cần có kiểm soát phù hợp.
Kết luận: chuẩn hóa trước, tự động hóa sau
Twenty đáng để theo dõi với các doanh nghiệp có đội kỹ thuật và muốn xây CRM theo quy trình riêng. Với sales và CSKH, câu hỏi quan trọng không phải là:
> “AI có gửi follow-up thay tôi được không?”
Mà là:
> “Dữ liệu của tôi đã đủ rõ để tôi follow-up đúng chưa?”
Checklist bắt đầu
[ ] Chọn một luồng sales hoặc CSKH cần chuẩn hóa.
[ ] Chốt các trường dữ liệu cần theo dõi.
[ ] Thống nhất ý nghĩa của từng trạng thái xử lý.
[ ] Quy định ai phụ trách và ai được cập nhật trạng thái.
[ ] Đặt bước duyệt của con người trước các phản hồi nhạy cảm.
[ ] Kiểm tra giá và chính sách trước mọi phản hồi khách.
[ ] Hạn chế đưa dữ liệu cá nhân không cần thiết vào công cụ AI.