Kiến thức / Bán hàng – Chăm sóc khách hàng / Sale / CSKH

AI Agent cho Nhân viên Sale: bản đồ use case

AI Agent cho Nhân viên Sale: bản đồ công việc, dữ liệu và giới hạn

Tình huống thật trong buổi kiểm kê công việc Sale

Thay vì nhìn vào một lead cụ thể, quản lý Sale mời đội ngồi lại với bảng công việc của cả tháng. Danh sách có hơn ba mươi việc: đọc inbox Zalo, làm sạch export từ MISA AMIS, cập nhật Google Sheets, chuẩn bị tài liệu, ghi chú sau cuộc gọi, rà lịch, kiểm tra dữ liệu fanpage và bàn giao cơ hội cho người phụ trách. Mỗi người đánh giá mức “tốn thời gian” khác nhau nên nhóm chưa biết use case nào đáng thử.

AI Agent cho Nhân viên Sale ở giai đoạn bản đồ không xử lý lead, không viết follow-up và không phân loại khách. Nó giúp mô tả từng nhiệm vụ, xác định dữ liệu, tiêu chí kiểm tra, tác động khi sai, quyền cần thiết và mức trưởng thành. Kết quả là danh mục PILOT, CHỜ_DỮ_LIỆU hoặc KHÔNG_GIAO_AI. Người quản lý phê duyệt use case; Agent chỉ tạo tài liệu DRAFT cho workshop.

Việc có thể giao cho AI và giới hạn thương mại

Ứng viên phù hợp thường là việc hậu trường có đầu vào lặp và đầu ra kiểm tra được: chuẩn hóa tên trường, tìm ô trống, tóm tắt nội dung nội bộ, gắn nguồn, tạo checklist, đối chiếu tài liệu phiên bản và chuẩn bị bản nháp cho người Sale. Use case hẹp cho phép đội đo lỗi, sửa schema và thu hồi quyền mà không tác động trực tiếp đến khách.

Không đưa vào pilot các hành động tự gửi, tự thay giá, tạo ưu đãi, cam kết tồn kho, thay điều khoản, bỏ qua consent hoặc tự gộp bản ghi. Một nhiệm vụ rộng như “chăm sóc lead” phải tách thành dữ liệu đầu vào, bước chuẩn bị, người duyệt và hành động cuối. Permission boundary mặc định chỉ READ và CREATE_DRAFT. Quyền ghi CRM, gửi tin hoặc thay trạng thái thương mại nằm ngoài bản đồ thử nghiệm.

Dữ liệu cần chuẩn bị để đánh giá use case

Mỗi use case có data card gồm nguồn, owner, schema, trường bắt buộc, phiên bản chính sách, tần suất cập nhật, mức nhạy cảm, quyền, thời hạn lưu và cách đối chiếu. Dữ liệu mẫu dùng lead_id DEMO, không dùng tên, số điện thoại hoặc email giống thật. Trích đoạn hội thoại chỉ xuất hiện khi cần kiểm tra cấu trúc và đã được giảm dữ liệu.

Độ sẵn sàng phải có bằng chứng: tỷ lệ trường có giá trị, số record trùng, nguồn mâu thuẫn, trường không có consent và khả năng truy vết. Sheet dễ mở chưa chắc là nguồn chuẩn. Nếu Zalo, Messenger và fanpage dùng ba cách ghi trạng thái, nhóm cần chuẩn hóa trước. MISA AMIS hoặc CRM nội bộ chỉ được kết nối sau khi chủ dữ liệu xác nhận quyền.

Workflow sáu bước chọn use case và mức trưởng thành

Bước 1 — Lập inventory: ghi kích hoạt, đầu vào, đầu ra, tần suất, owner và reviewer. Bước 2 — Chấm khả năng kiểm tra: xác định schema, nguồn, checklist hoặc người xác nhận. Bước 3 — Đánh giá data readiness: rà độ đủ, trùng, version, consent và quyền. Use case thiếu owner hoặc nguồn dừng ở CHỜ_DỮ_LIỆU.

Bước 4 — Lập ma trận kiểm soát: ghi sự cố có thể xảy ra, dấu hiệu, tác động, điểm dừng và cách phục hồi. Bước 5 — Vẽ permission boundary: tách đọc, tạo nháp, đề xuất, ghi và gửi. Bước 6 — Xác định mức trưởng thành: Mức 0 thủ công, Mức 1 AI tạo nháp, Mức 2 workflow có review, Mức 3 orchestration có log và rollback. Pilot chỉ lên cấp tiếp theo sau nghiệm thu.

Quy trình chọn use case AI cho Nhân viên Sale theo dữ liệu quyền và mức trưởng thành — Quy trình minh họa dùng để chọn use case, không phải lifecycle xử lý lead.

Năm prompt mẫu cho workshop use case

Prompt 1 tạo inventory công việc. Prompt 2 lập data-readiness card. Prompt 3 tạo ma trận kiểm soát. Prompt 4 vẽ quyền theo vai trò. Prompt 5 đánh giá mức trưởng thành và lập pilot charter. Không prompt nào phân loại lead, soạn objection, viết câu hỏi hay tạo follow-up; những intent này thuộc hai bài chuyên biệt khác.

Mỗi điểm hoặc nhãn cần bằng chứng, owner và reviewer. Nếu Agent tự cho rằng dữ liệu sạch, tự mở rộng quyền hoặc chọn use case thay nhóm, kết quả bị trả lại. Dùng bộ DEMO và nêu rõ ngoài phạm vi. Workshop kết thúc bằng một use case hẹp, tiêu chí đạt, ngưỡng dừng cùng lịch review.

Công cụ phù hợp để lập bản đồ

Google Sheets phù hợp cho inventory; Base.vn quản lý action item; MISA AMIS hoặc CRM cung cấp tên nguồn và schema sau khi được phép; Zalo, Messenger và fanpage chỉ là ví dụ về kênh dữ liệu cần owner. Không cần kết nối live trong giai đoạn map. Một whiteboard giúp vẽ data flow và điểm giao giữa Marketing, Sale, CSKH.

Risk register lưu sự cố vận hành như lẫn lead_id, dùng chính sách cũ, thiếu consent, tự thêm giá hoặc gửi nhầm. RACI chỉ rõ quản lý Sale, chủ dữ liệu, IT và tuân thủ. Link trong inventory trỏ tới kho nội bộ có quyền. Tên use case dùng động từ–đầu ra, như “chuẩn hóa ghi chú thành schema”, không dùng tên rộng “AI bán hàng”.

Ma trận use case Sale theo giá trị dữ liệu kiểm soát và mức trưởng thành — Ma trận minh họa dùng use case DEMO; không phải dự báo doanh số.

AI làm gì và người duyệt làm gì

AI chuẩn hóa mô tả, gom bằng chứng, chỉ ra trường thiếu và trình bày ma trận nhất quán. Agent có thể gợi ý câu hỏi workshop nhưng không xác nhận consent, chính sách hoặc quyền. Nhãn mức trưởng thành và pilot luôn ở trạng thái PROPOSED.

Nhân viên Sale mô tả công việc; quản lý xác nhận giá trị và ranh giới thương mại; chủ dữ liệu xác nhận nguồn; IT xác nhận quyền; tuân thủ rà consent và retention. Lãnh đạo bộ phận quyết định pilot. Khi một use case bị hoãn, nhóm ghi việc cần hoàn thiện thay vì sửa điểm cho đẹp.

Sai lầm và rủi ro cần tránh

Sai lầm đầu tiên là chọn việc vì đang gây bức xúc nhất. Sai lầm thứ hai là dùng dữ liệu live để chứng minh ý tưởng. Sai lầm thứ ba là trộn bước chuẩn bị với hành động gửi. Sai lầm thứ tư là xem mức trưởng thành như cuộc đua tự động hóa. Mức phù hợp là mức đội kiểm soát được, không phải mức nhiều quyền nhất.

Ma trận kiểm soát tập trung vào lỗi của use case: dữ liệu sai nguồn, lead_id trùng, consent không rõ, policy hết hạn, draft tự thêm thông tin và log thiếu. Mỗi lỗi có owner, stop condition và rollback. Nếu chưa có cách phát hiện hoặc thu hồi, use case không lên pilot. Không dùng score để dự đoán hành vi khách hàng.

Triển khai cá nhân, đội và doanh nghiệp

Cá nhân kiểm kê mười việc và chọn ba ứng viên có đầu ra kiểm tra được. Đội nhỏ tổ chức workshop với Sale, IT và chủ dữ liệu, dùng 20 bản ghi DEMO. Mỗi use case có owner và reviewer khác nhau nếu cần kiểm soát chéo.

Doanh nghiệp duy trì registry use case gồm mã, nguồn, quyền, mức trưởng thành, kiểm soát, phiên bản và ngày review. Pilot chạy ở Mức 1 với READ/CREATE_DRAFT. Theo dõi trường tự điền, nguồn thiếu, phần reviewer sửa và thời gian kiểm tra. Chỉ sau nghiệm thu mới thiết kế state machine hoặc thư viện prompt chăm sóc.

Kết quả đầu ra mẫu và câu hỏi thường gặp

Kết quả minh họa: UC-SALE-DEMO-05 “chuẩn hóa ghi chú nội bộ thành schema”; 20 bản ghi DEMO; mức trưởng thành 1; quyền READ/CREATE_DRAFT; reviewer Quản lý Sale; dừng khi tự thêm giá, lịch hoặc consent; trạng thái PILOT_PROPOSED.

Use case Sale nào nên xem trước?

Chọn việc hậu trường, dữ liệu rõ, đầu ra kiểm tra được và chưa cần gửi hoặc ghi hệ thống chính.

Mức trưởng thành cao hơn có luôn tốt hơn?

Không. Đội chỉ tăng mức khi dữ liệu, quyền, review, log và rollback đã được nghiệm thu.

Có thể dùng lead thật để workshop không?

Không cần. Dùng mã DEMO và dữ liệu đã giảm theo chính sách nội bộ.

Ai phê duyệt permission boundary?

Quản lý Sale, chủ dữ liệu, IT và tuân thủ xác nhận phần thuộc trách nhiệm của họ.

Nếu cần điều phối workshop, hãy liên hệ NganAds tại trang tư vấn hoặc số 0983543063.

Gợi ý chương trình buổi làm việc 75 phút: dành 15 phút thống nhất mục tiêu, 20 phút kiểm kê nhiệm vụ, 15 phút rà data card, 15 phút lập permission boundary và 10 phút chốt owner cùng việc tiếp theo. Mỗi người mang một bằng chứng thay vì nhận xét chung. Kết thúc buổi họp chỉ chọn tối đa một pilot và một use case dự phòng. Phần còn lại được đưa vào backlog có điều kiện mở lại. Cách giới hạn này giúp nhóm giữ cuộc thảo luận ở cấp use case, không trượt sang thiết kế pipeline hoặc viết tin chăm sóc trước khi dữ liệu và quyền được xác nhận.

Workflow

Bước 1: Lập inventory nhiệm vụ — Tách việc theo kích hoạt, đầu vào, đầu ra, tần suất, owner và reviewer.
Bước 2: Đánh giá khả năng kiểm tra — Xác định schema, nguồn, checklist hoặc người xác nhận dùng để đối chiếu.
Bước 3: Lập data-readiness card — Rà độ đủ, trùng, version, consent, quyền và dữ liệu DEMO.
Bước 4: Lập ma trận kiểm soát — Ghi lỗi, dấu hiệu, tác động, stop condition, owner và recovery.
Bước 5: Vẽ ranh giới quyền cho lead — Tách đọc hồ sơ lead, tạo nháp follow-up, đề xuất next step, ghi CRM và gửi; chọn quyền thấp nhất.
Bước 6: Xác định mức trưởng thành và pilot — Đặt level, gap, reviewer, tiêu chí, ngưỡng dừng và rollback.

Prompt mẫu

Lập inventory công việc Sale

MỤC TIÊU: Chuyển danh sách việc Sale thành inventory use case hẹp và kiểm tra được.
[ĐẦU VÀO]: Việc, kích hoạt, tần suất, đầu vào, đầu ra, owner, reviewer, công cụ và lỗi thường gặp.
ĐỊNH DẠNG ĐẦU RA: Bảng mã use case, động từ–đầu ra, nguồn, tiêu chí đúng, owner, quyền dự kiến và câu hỏi thiếu; không gộp hành động gửi.
VÍ DỤ ĐIỀN SẴN: Chuẩn hóa ghi chú nội bộ; 60 bản ghi DEMO/tháng; nguồn CRM export; quản lý Sale duyệt.

Tạo data-readiness card

MỤC TIÊU: Đánh giá dữ liệu cho một use case Sale trước pilot.
[ĐẦU VÀO]: Nguồn, owner, schema, policy version, mẫu DEMO, trường trống, trùng, consent, quyền và retention.
ĐỊNH DẠNG ĐẦU RA: READY/NEEDS_WORK, bằng chứng, khoảng trống, việc chuẩn hóa, owner và ngày review; không tự xác nhận nguồn.
VÍ DỤ ĐIỀN SẴN: 20 bản ghi DEMO; 4 thiếu source_id; 2 trùng; policy SALE-DATA-v3.

Lập ma trận kiểm soát

MỤC TIÊU: Xác định lỗi vận hành của use case và biện pháp kiểm soát.
[ĐẦU VÀO]: Mục tiêu, dữ liệu, đầu ra, tác động khi sai, kiểm soát hiện có, owner và rollback.
ĐỊNH DẠNG ĐẦU RA: Sự cố, dấu hiệu, tác động, phòng ngừa, phát hiện, stop condition, owner và recovery.
VÍ DỤ ĐIỀN SẴN: Draft tự thêm giá; phát hiện bằng source check; dừng lô và thu hồi bản nháp.

Vẽ permission boundary

MỤC TIÊU: Xác định quyền tối thiểu theo vai trò cho use case Sale.
[ĐẦU VÀO]: Hệ thống, nguồn, vai trò, hành động đọc/tạo nháp/đề xuất/ghi/gửi, consent và người duyệt quyền.
ĐỊNH DẠNG ĐẦU RA: Ma trận role–resource–action, allow, deny, thời hạn, log, cách thu hồi và reviewer.
VÍ DỤ ĐIỀN SẴN: Agent đọc 20 bản ghi DEMO và tạo DRAFT; không ghi CRM, không gửi kênh khách.

Đánh giá mức trưởng thành và pilot charter

MỤC TIÊU: Xác định mức trưởng thành hiện tại và soạn charter cho cấp tiếp theo.
[ĐẦU VÀO]: Use case, dữ liệu, quyền, review, log, rollback, bộ DEMO, tiêu chí đạt và ngưỡng dừng.
ĐỊNH DẠNG ĐẦU RA: Mức 0–3 có bằng chứng, gap, mục tiêu pilot, ngoài phạm vi, reviewer, stop condition và rollback.
VÍ DỤ ĐIỀN SẴN: UC-SALE-DEMO-05; Mức 1; 20 record; READ/CREATE_DRAFT; dừng khi tự thêm dữ kiện.

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

Use case Sale nào nên xem trước?

Chọn việc hậu trường, dữ liệu rõ, đầu ra kiểm tra được và chưa cần gửi hoặc ghi hệ thống chính.

Mức trưởng thành cao hơn có luôn tốt hơn?

Không; chỉ tăng mức khi dữ liệu, quyền, review, log và rollback đã nghiệm thu.

Có thể dùng lead thật để workshop không?

Không cần; dùng mã DEMO và dữ liệu đã giảm theo chính sách.

Ai phê duyệt permission boundary?

Quản lý Sale, chủ dữ liệu, IT và tuân thủ xác nhận phần của họ.

Bài liên quan

Muốn cài AI Agent cá nhân 499K (support 7 ngày)? Inbox / Zalo 0983543063.