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

AI Agent cho CSKH: ticket, dữ liệu và giới hạn

AI Agent cho Chăm sóc khách hàng (CSKH): bản đồ ticket, dữ liệu và giới hạn

Thuật ngữ: Trong bài, ticket là hồ sơ theo dõi một yêu cầu; knowledge base (KB) là kho tri thức đã duyệt; SLA là cam kết thời gian xử lý nội bộ; escalation là chuyển tuyến; DRAFT là bản nháp chờ người duyệt.

Tình huống thật khi một phản hồi đi qua nhiều hàng chờ

Một khách nhắn Zalo hỏi đơn giao chậm, sau đó bình luận trên fanpage và gọi vào cửa hàng. Ba kênh tạo ba bản ghi, trong khi trạng thái đơn nằm ở KiotViet, chính sách đổi trả nằm trong Google Drive và trưởng ca đang theo dõi việc trên Base.vn. Nếu AI chỉ nhìn một tin nhắn, nó có thể trả lời bằng chính sách cũ, tạo ticket trùng hoặc hứa một bước mà vận hành chưa xác nhận.

AI Agent cho Chăm sóc khách hàng phù hợp với phần hậu trường: chuẩn hóa sự kiện, tìm nguồn, tạo DRAFT, phát hiện trường thiếu và chuẩn bị phiếu chuyển tuyến. Nó không tự kết luận nguyên nhân, không quyết định bồi hoàn, không đóng ticket và không biến một phản hồi chưa giải quyết thành cơ hội bán thêm. Mọi câu trả lời ra ngoài cần nguồn, consent, người duyệt và dấu vết gửi.

Bài này là bản đồ nghề, không phải workflow xử lý ticket và không phải bộ prompt trả lời khách. Mục tiêu là phân định công việc, dữ liệu, quyền, rủi ro và reviewer để chọn một pilot hẹp. Hai bài còn lại đi sâu vào lifecycle ticket và năm prompt vận hành riêng.

Việc giao cho AI và việc giữ cho con người

Nhóm việc rủi ro thấp gồm chuẩn hóa ticket_id, tách order_ref, nhận diện trường thiếu, gắn nhãn hành chính theo taxonomy đã duyệt, tìm KB article theo issue_type và tạo bản tóm tắt facts_only. Đầu ra nằm ở DRAFT hoặc REVIEW; AI không sửa order, SLA hay trạng thái cuối trong hệ nguồn.

Nhóm cần duyệt gồm soạn lời xác nhận đã tiếp nhận, tạo câu trả lời từ knowledge base, đề xuất owner và lập escalation brief. Nhân viên CSKH kiểm sự kiện, phiên bản KB, cách xưng hô và bước tiếp theo. Trưởng ca xác nhận ngoại lệ SLA, khiếu nại phức tạp và quyền chuyển bộ phận.

Nhóm chỉ con người gồm xác định lỗi thuộc bên nào, chấp nhận trách nhiệm pháp lý, phê duyệt hoàn tiền/quà tặng, xử lý an toàn hoặc chuyên môn, khóa tài khoản, chấm điểm nhân viên và đóng khiếu nại. AI phải dừng khi thiếu proof, nguồn mâu thuẫn, khách yêu cầu ngừng liên hệ hoặc nội dung vượt taxonomy hành chính.

Dữ liệu cần chuẩn bị cho bản đồ CSKH

Mỗi ticket cần ticket_id, source_event_id, kênh, thời điểm, order/service_ref, quote tối thiểu, consent_scope, issue_type, owner, status và previous_action. Dữ liệu nhận dạng chỉ dùng trường cần thiết; bộ test sử dụng mã DEMO. Không sao chép toàn bộ lịch sử chat vào prompt để “hiểu khách”.

Knowledge base cần article_id, version, owner, ngày hiệu lực, phạm vi sản phẩm/dịch vụ và nội dung được phép gửi. SLA card ghi loại ticket, mốc bắt đầu, pause condition, escalation role và proof đóng. Refund/compensation policy phải tách mức nhân viên được phép đề xuất khỏi mức quản lý phê duyệt.

Chuẩn bị thêm test set gồm ticket trùng, order không tìm thấy, KB hết hạn, hai nguồn mâu thuẫn, `STOP_CONTACT`, lỗi an toàn và ticket mở lại. Đây là dữ liệu minh họa để kiểm hành vi, không dùng làm chứng cứ về hiệu quả thật. Mỗi ca có expected status và reviewer.

Workflow sáu bước chọn pilot phù hợp

Bước 1 — Kiểm kê ticket work: tách tiếp nhận, tra nguồn, soạn nháp, chuyển tuyến và đóng ticket thành việc riêng. Bước 2 — Chấm khả năng kiểm: nêu schema, KB source, proof và người xác nhận cho mỗi đầu ra.

Bước 3 — Vẽ data lineage: nối field với hệ nguồn, purpose, consent, owner và thời hạn lưu. Bước 4 — Gán permission boundary: tách READ, CREATE_DRAFT, REQUEST_REVIEW và HUMAN_ONLY; quyền refund, close hoặc send không thuộc pilot mặc định.

Bước 5 — Chạy tình huống lỗi: thử duplicate, KB cũ, consent bị rút và escalation. Hệ thống đạt khi biết dừng. Bước 6 — Duyệt pilot charter: trưởng CSKH, data owner và IT xác nhận phạm vi, tiêu chí, stop condition cùng rollback trước khi kết nối.

Sơ đồ chọn pilot AI cho CSKH theo ticket, nguồn, quyền và reviewer — Workflow minh họa chọn một tác vụ CSKH có đầu ra kiểm được và điều kiện dừng rõ.

Năm prompt mẫu để thiết kế bản đồ

Prompt 1 lập inventory việc CSKH; Prompt 2 chấm knowledge-base readiness; Prompt 3 vẽ permission boundary; Prompt 4 viết escalation charter; Prompt 5 tạo pilot scorecard. Chúng không soạn câu trả lời ticket, không chạy dedupe và không đóng/mở ticket; đó là phạm vi của hai bài cùng cụm.

Khi dùng, thay ticket thật bằng DEMO, ghi rõ taxonomy version và reviewer. Nếu nguồn thiếu, kết quả phải là `NEEDS_WORK` hoặc `BLOCKED`. Điểm do AI tạo chỉ giúp thảo luận; quản lý quyết định có thử hay không dựa trên bằng chứng và khả năng khôi phục.

Công cụ phù hợp theo vai trò

Pancake hoặc Zalo OA có thể là nguồn tương tác; KiotViet/Sapo cung cấp trạng thái đơn theo quyền; Getfly hoặc MISA AMIS CRM giữ customer/ticket state; Base.vn giữ owner và phê duyệt. Google Sheets phù hợp cho inventory cùng test fixture trong pilot, không phải nơi công khai toàn bộ hội thoại.

Công cụ AI chỉ đọc view tối thiểu và ghi vùng DRAFT. Connector phải có service account, log, timeout, retry có giới hạn và cách tra target proof. Canva chỉ dùng asset thương hiệu đã được phép, không chứa ảnh khiếu nại, chứng từ hoặc dữ liệu khách.

Ma trận việc CSKH với dữ liệu, mức rủi ro, quyền AI và người duyệt — Ma trận minh họa tách tác vụ hậu trường, tác vụ cần duyệt và quyết định chỉ con người thực hiện.

AI làm gì và người duyệt quyết định gì

AI chuẩn hóa field, tìm KB source, phát hiện thiếu dữ liệu, tạo DRAFT và phiếu escalation. Nó không biết một sự kiện đã thực sự xảy ra nếu không có proof, không sở hữu SLA/policy và không được dùng sentiment làm quyết định ưu tiên hoặc bồi hoàn.

Nhân viên CSKH xác nhận facts, order_ref, giọng và gửi. Trưởng ca duyệt escalation cùng ngoại lệ SLA. Vận hành/kho xác nhận proof; quản lý duyệt bồi hoàn; bộ phận pháp lý, an toàn hoặc chuyên môn nhận trường hợp vượt ranh giới. IT/data owner quản lý quyền và retention.

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

Sai lầm đầu tiên là coi nhiều tin giống nhau là một ticket và tự merge. Sai lầm thứ hai là dùng KB không có version. Sai lầm thứ ba là để AI tự hứa thời gian xử lý, hoàn tiền hoặc quà tặng. Sai lầm thứ tư là đóng ticket khi đã gửi tin nhưng chưa có resolution proof.

Rủi ro dữ liệu xuất hiện khi gom toàn bộ chat, chia sẻ Sheet rộng hoặc giữ dữ liệu quá hạn. Rủi ro trải nghiệm xuất hiện khi retry tin nhắn, đổi kênh hoặc cross-sell sau khi khách yêu cầu dừng. Mỗi rủi ro cần stop condition, owner và cách quay về thao tác thủ công.

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

Cá nhân kiểm kê mười việc và thử trên hai mươi ticket DEMO thuộc một issue_type. Đội nhỏ chọn một kênh, một KB owner và duyệt mọi DRAFT. Doanh nghiệp thêm state machine, service account, audit log, hàng lỗi và registry cho KB/prompt.

Đo pilot bằng tỷ lệ DRAFT có source, duplicate được chuyển review, trường hợp dừng đúng, phần người sửa và lỗi quyền. Không dùng số ticket trả lời tự động như bằng chứng thành công. Một sự cố gửi chưa duyệt, sai consent hoặc tự bồi hoàn là điều kiện dừng ngay.

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

Dữ liệu minh họa: use case `CSKH-MAP-DEMO-04` là “tìm KB và tạo DRAFT xác nhận ticket”. AI READ ticket/order view, CREATE_DRAFT với KB-CS-12-v3; nhân viên CSKH duyệt; quyền SEND/CLOSE/REFUND bị cấm. Ca KB hết hạn trả `BLOCKED`; ca ticket trùng trả `REVIEW_DUPLICATE`. Pilot ở `PROPOSED`.

Nên bắt đầu AI Agent CSKH từ việc nào?

Chọn việc hậu trường hẹp như kiểm trường ticket hoặc tìm KB có version, đầu ra dễ đối chiếu và chưa tác động trực tiếp.

AI có được tự trả lời khách không?

Không trong pilot bản đồ. AI tạo DRAFT; nhân viên kiểm nguồn, consent, nội dung và quyết định gửi.

Sentiment có được dùng để ưu tiên ticket không?

Không dùng như quyết định duy nhất. Ưu tiên phải dựa trên taxonomy, SLA và rule đã duyệt; trường mơ hồ chuyển người.

Khi nào phải dừng pilot?

Dừng khi AI gửi chưa duyệt, sai consent, dùng KB hết hiệu lực, tự merge/close hoặc đề xuất bồi hoàn ngoài quyền.

Tiếp tục với workflow xử lý ticket, dùng bộ prompt CSKH hoặc liên hệ NganAds qua Zalo 0983543063 để thiết kế pilot trên hệ thống hiện có.

Workflow

Bước 1: Kiểm kê việc — Tách tác vụ ticket theo nguồn, đầu ra, lỗi và người duyệt; không gộp hành động gửi hoặc đóng.
Bước 2: Chấm khả năng kiểm — Gắn schema, KB source, proof và reviewer cho từng use case; thiếu tiêu chí thì chưa thử.
Bước 3: Vẽ data lineage — Ghi field, nguồn, purpose, consent, owner và retention; thiếu căn cứ thì BLOCKED.
Bước 4: Gán quyền tối thiểu — Tách READ, CREATE_DRAFT, REVIEW và HUMAN_ONLY; SEND/CLOSE/REFUND ngoài pilot.
Bước 5: Chạy bộ lỗi — Thử duplicate, KB cũ, consent rút và escalation; hệ thống phải dừng đúng.
Bước 6: Duyệt pilot charter — CSKH lead, data owner và IT duyệt phạm vi, metric, stop condition và rollback.

Prompt mẫu

Lập inventory việc CSKH

MỤC TIÊU: Tách công việc CSKH thành use case hậu trường có đầu vào, đầu ra và reviewer.
[ĐẦU VÀO]: [VIỆC, TẦN SUẤT, TICKET SOURCE, ĐẦU RA, LỖI, OWNER].
YÊU CẦU: Không gộp gửi, close, refund hoặc quyết định nguyên nhân vào use case AI.
ĐỊNH DẠNG ĐẦU RA: Bảng use_case_id | source | output | verify_method | risk | permission | reviewer | status.
VÍ DỤ ĐIỀN SẴN: CSKH-DEMO; tìm KB theo issue_type; AI chỉ READ và CREATE_DRAFT; trưởng ca duyệt.

Chấm readiness của knowledge base

MỤC TIÊU: Đánh giá kho trả lời trước khi cho AI tra cứu.
[ĐẦU VÀO]: [ARTICLE_ID, VERSION, OWNER, EFFECTIVE_AT, SCOPE, APPROVED_TEXT].
RÀNG BUỘC: Không tự xác nhận nội dung đúng; thiếu owner/version ghi NEEDS_WORK.
ĐỊNH DẠNG ĐẦU RA: data card gồm completeness, conflicts, expired_items, permissions và remediation owner.
VÍ DỤ ĐIỀN SẴN: KB-CS-12-v3 hợp lệ; KB-CS-09 thiếu owner và bị BLOCKED.

Vẽ permission boundary ticket

MỤC TIÊU: Tách quyền read, draft, approve, send, close và refund theo vai trò.
[ĐẦU VÀO]: [HỆ THỐNG, RESOURCE, ROLE, ACTION, CONSENT, LOG].
YÊU CẦU: AI không có SEND/CLOSE/REFUND; quyền tối thiểu, có thời hạn và cách thu hồi.
ĐỊNH DẠNG ĐẦU RA: Ma trận role-resource-action | allow/deny | approver | expiry | audit proof.
VÍ DỤ ĐIỀN SẴN: Agent đọc ticket view, ghi DRAFT; nhân viên duyệt/gửi; quản lý duyệt refund.

Viết escalation charter

MỤC TIÊU: Xác định dấu hiệu dừng và vai trò nhận ticket vượt ranh giới.
[ĐẦU VÀO]: [ISSUE TAXONOMY, RISK SIGNAL, OWNER DIRECTORY, SLA POLICY].
CẤM: Không chẩn đoán, nhận trách nhiệm pháp lý hoặc đề xuất bồi hoàn.
ĐỊNH DẠNG ĐẦU RA: Cây IF/THEN với NORMAL, REVIEW, ESCALATE và BLOCKED; mỗi nhánh có next_owner.
VÍ DỤ ĐIỀN SẴN: phản hồi an toàn sản phẩm → ESCALATE_SAFETY, dừng mẫu trả lời thường.

Tạo scorecard pilot CSKH

MỤC TIÊU: So sánh use case theo khả năng kiểm, data readiness, rủi ro và rollback.
[ĐẦU VÀO]: [INVENTORY, KB CARD, PERMISSION MATRIX, TEST CASES].
YÊU CẦU: Không chọn use case có quyền gửi/close/refund hoặc thiếu reviewer.
ĐỊNH DẠNG ĐẦU RA: Điểm 0–3 từng tiêu chí, lý do, stop condition và PILOT/SỬA/BỎ.
VÍ DỤ ĐIỀN SẴN: tìm KB + DRAFT đạt PILOT; tự đóng ticket bị BỎ.

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

Nên bắt đầu AI Agent CSKH từ việc nào?

Chọn việc hậu trường hẹp như kiểm trường ticket hoặc tìm KB có version, đầu ra dễ đối chiếu và chưa tác động trực tiếp.

AI có được tự trả lời khách không?

Không trong pilot bản đồ. AI tạo DRAFT; nhân viên kiểm nguồn, consent, nội dung và quyết định gửi.

Sentiment có được dùng để ưu tiên ticket không?

Không dùng như quyết định duy nhất. Ưu tiên phải dựa trên taxonomy, SLA và rule đã duyệt; trường mơ hồ chuyển người.

Khi nào phải dừng pilot?

Dừng khi AI gửi chưa duyệt, sai consent, dùng KB hết hiệu lực, tự merge hoặc close, hay đề xuất bồi hoàn ngoài quyền.

Bài liên quan

Bắt đầu bằng một use case hậu trường, knowledge base có owner và ma trận quyền; không mở gửi hoặc bồi hoàn trong pilot đầu.