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

Workflow AI xử lý ticket CSKH có người duyệt

Workflow xử lý ticket CSKH: từ tiếp nhận đến duyệt, đóng và mở lại

Thuật ngữ: Trong bài, ticket là hồ sơ theo dõi 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ộ; DRAFT là bản nháp; close và reopen lần lượt là đóng và mở lại hồ sơ.

Tình huống thật: một vấn đề xuất hiện ở ba kênh

Workflow AI cho Chăm sóc khách hàng ngành Bán hàng – Chăm sóc khách hàng cần bắt đầu từ sự kiện hỗ trợ, không phải từ một danh sách lead chung. Ví dụ, khách báo thiếu phụ kiện qua Zalo OA, nhắc lại trên Facebook và gọi cửa hàng sau hai giờ. Nếu mỗi kênh tự tạo một hành động, ba nhân viên có thể trả ba câu khác nhau, trong khi kho chưa xác nhận kiện hàng.

Workflow đúng phải gom bằng bằng chứng, nhưng không tự merge chỉ vì nội dung giống nhau. Hệ thống lập `duplicate_candidate`, giữ nguyên source_event_id và yêu cầu nhân viên xác nhận quan hệ giữa các ticket. Sau đó nó tra order view cùng knowledge base có phiên bản, tạo DRAFT và chờ duyệt. Việc đã gửi không đồng nghĩa với việc đã giải quyết.

Bài này tập trung vào lifecycle tiếp nhận → chuẩn hóa → tra nguồn → nháp → duyệt → resolution → close/reopen. Nó không thay thế bản đồ chọn tác vụ và cũng không phải thư viện prompt. Mọi dữ liệu bên dưới là dữ liệu minh họa; tổ chức cần thay bằng taxonomy, SLA, kênh và quyền thật đã được phê duyệt.

Việc giao cho AI trong từng trạng thái ticket

Ở trạng thái `NEW`, AI kiểm trường bắt buộc, trích mã đơn nếu khách đã cung cấp và tạo bản tóm tắt facts-only. Ở `TRIAGE`, nó đề xuất issue_type theo taxonomy, đánh dấu mức tin cậy và tìm ticket có cùng order_ref, contact_ref hoặc source_event. Kết quả chỉ là đề xuất; thiếu khóa xác thực thì chuyển `NEEDS_INFO`.

Ở `DRAFT`, AI truy xuất bài KB còn hiệu lực, chèn article_id, version và câu hỏi còn thiếu. Ở `REVIEW`, nhân viên xác nhận sự kiện, cách xưng hô, consent và next step rồi mới gửi. AI có thể ghi delivery receipt sau khi connector trả target id, nhưng không tự hiểu receipt là khách đã đọc hay đồng ý.

Ở `RESOLUTION_REVIEW`, con người kiểm proof từ kho, vận hành hoặc chuyên môn. Chỉ khi resolution_code, proof_ref và customer-facing summary đã duyệt mới chuyển `CLOSE_READY`. Quyền đóng thuộc nhân viên hoặc trưởng ca theo policy. Tin mới liên quan cùng vấn đề tạo `REOPEN_REVIEW`, không lặng lẽ sửa ticket đã đóng.

Dữ liệu cần chuẩn bị trước khi nối công cụ

Ticket schema tối thiểu gồm ticket_id, source_event_id, channel, received_at, customer_ref đã giảm định danh, order_or_service_ref, quote, issue_type, priority_rule, owner, status và last_action_at. Mỗi lần chuyển trạng thái có actor, reason_code, source_ref và timestamp. Không dùng một cột ghi chú tự do để thay toàn bộ lịch sử.

Knowledge base cần article_id, version, effective_from, expires_at, scope, owner và approved_snippet. SLA cần start event, pause reason hợp lệ, due_at, escalation role và timezone. Directory ghi vai trò nhận các vấn đề kho, thanh toán, an toàn, pháp lý hoặc chuyên môn; không để AI tự đoán người nhận từ tên phòng ban.

Consent card ghi kênh được phép, purpose, thời hạn và `STOP_CONTACT`. Bộ test phải có ticket trùng giả, order không tồn tại, KB hết hạn, hai nguồn mâu thuẫn, connector timeout, gửi thành công nhưng thiếu receipt, khách đổi ý và ticket mở lại. Mỗi ca có expected status, expected owner cùng điều kiện cấm gửi.

Workflow sáu bước, nhánh lỗi và điều kiện dừng

Bước 1 — Intake bất biến: nhận webhook, kiểm chữ ký, tạo event_key và lưu payload tối thiểu. Event_key đã tồn tại thì không tạo ticket mới; payload thiếu source id vào hàng lỗi. Bước 2 — Triage có bằng chứng: chuẩn hóa field, tìm duplicate candidate và gắn taxonomy; mọi merge cần người duyệt.

Bước 3 — Grounding: tra order/service view và KB theo scope, ngày hiệu lực. Không có nguồn hợp lệ thì `BLOCKED_SOURCE`; nguồn mâu thuẫn thì `ESCALATE_OWNER`. Bước 4 — DRAFT và Human-in-the-loop: tạo phản hồi gồm facts, source, giới hạn và next step; nhân viên sửa, duyệt rồi bấm gửi.

Bước 5 — Theo dõi resolution: ghi delivery proof, chờ bằng chứng xử lý và cập nhật khách theo SLA đã duyệt. Retry dùng idempotency key; quá số lần thì chuyển người, không gửi lặp. Bước 6 — Close hoặc reopen: người có quyền xác nhận resolution proof; tín hiệu mới tạo phiên review. Dừng toàn luồng khi sai consent, lộ dữ liệu, KB cũ, hành động chưa duyệt hoặc connector không xác định kết quả.

Workflow ticket CSKH từ intake, triage, tra nguồn, duyệt, resolution đến mở lại — Sơ đồ minh họa sáu trạng thái chính, hàng lỗi và điểm Human-in-the-loop trước khi gửi hoặc đóng.

Năm prompt hỗ trợ workflow mà không tự hành động

Prompt 1 chuẩn hóa sự kiện thành ticket facts; Prompt 2 tạo phiếu duplicate candidate; Prompt 3 tra KB và soạn DRAFT có dẫn nguồn; Prompt 4 tạo escalation brief; Prompt 5 kiểm điều kiện close hoặc reopen. Mỗi prompt nhận một object rõ ràng và trả một cấu trúc để người dùng kiểm, không phát lệnh tới connector.

Không đưa mật khẩu, token, số giấy tờ hoặc toàn bộ chat vào prompt. Với ví dụ DEMO, thay tên bằng contact_ref. Nếu đầu vào không đủ, prompt phải trả `NEEDS_INFO`; nếu nguồn quá hạn hoặc mâu thuẫn, trả `BLOCKED`. Một câu trả lời trôi chảy nhưng không gắn source_ref không được phép đi tiếp.

Năm prompt trong `promptPack` bên dưới bám đúng lifecycle này. Bộ prompt chuyên sâu của cụm CSKH lại xử lý các gói nghiệp vụ khác như SLA acknowledgment, closure check và chuyển tuyến. Tách hai lớp giúp workflow ổn định ngay cả khi nội dung prompt được cải tiến.

Công cụ và cách phân quyền phù hợp tại Việt Nam

Zalo OA, Pancake hoặc tổng đài là nguồn sự kiện; Sapo/KiotViet cung cấp order view; MISA AMIS CRM, Getfly hoặc hệ ticket giữ trạng thái; Base.vn có thể giữ task phê duyệt. Google Drive lưu KB có owner, còn Google Sheets phù hợp cho test fixture và đối soát trong pilot, không phải kho hội thoại mở.

Connector chỉ dùng service account tối thiểu. AI được READ view và CREATE_DRAFT; nhân viên có APPROVE/SEND; trưởng ca có ESCALATE/CLOSE theo vai trò; refund hoặc thay đổi đơn thuộc hệ nghiệp vụ và authority matrix riêng. Log phải ghi ai đọc, ai sửa, ai duyệt, target id và phiên bản KB.

Giao diện hàng chờ ticket với nguồn, SLA, bản nháp và nút duyệt — UI minh họa đặt source, trạng thái và nút duyệt cạnh nhau; không giấu quyết định gửi trong tiến trình nền.

AI làm gì và người duyệt chịu trách nhiệm gì

AI kiểm schema, tóm tắt facts, tìm nguồn, dự thảo phản hồi, phát hiện trường thiếu và chuẩn bị phiếu chuyển tuyến. Nó không xác nhận sự kiện kho, không nhận lỗi thay doanh nghiệp, không chọn mức bồi hoàn, không đánh giá nhân viên bằng cảm xúc của khách và không đóng vấn đề chỉ vì SLA sắp hết.

Nhân viên CSKH xác thực order_ref, quote, KB và cách trả lời. Trưởng ca quyết định ưu tiên ngoại lệ, merge ticket, chuyển tuyến hoặc close. Kho/vận hành xác nhận proof; quản lý phê duyệt bồi hoàn; bộ phận an toàn, pháp lý hay chuyên môn nhận đúng tình huống. Data owner và IT quản lý trường, retention, token cùng rollback.

Human-in-the-loop không phải một nút “duyệt tất cả”. Màn duyệt phải hiển thị input, source, thay đổi so với template, điều AI không biết và hành động kế tiếp. Người duyệt có thể sửa, từ chối, chuyển owner hoặc trả về `NEEDS_INFO`; mọi lựa chọn đều có reason code.

Sai lầm, nhánh lỗi và cách khôi phục

Lỗi nguy hiểm nhất là dùng similarity để tự merge ticket; cách sửa là chỉ tạo candidate. Lỗi tiếp theo là retry sau timeout mà không có idempotency key; cách sửa là tra delivery status trước. Lỗi khác gồm dùng KB cũ, lấy sentiment làm priority, đóng ngay sau khi gửi và để AI tự hứa ngày hoàn tất.

Hàng lỗi cần error_id, event_key, stage, retry_count, last_error, safe_payload_ref và owner. Các lỗi schema có thể sửa rồi replay; lỗi consent, quyền hoặc nguồn mâu thuẫn phải chuyển người. Không replay một event nếu không biết connector trước đó đã ghi hay chưa. Rollback là tắt write scope và quay về hàng chờ thủ công, không xóa log.

Đặt circuit breaker khi tỷ lệ `BLOCKED_SOURCE` tăng bất thường, receipt thiếu liên tiếp hoặc reviewer phát hiện bản nháp vượt policy. Một trường hợp gửi chưa duyệt, rò dữ liệu hoặc tự đóng là stop condition tức thì. Sau sự cố, soát phạm vi ảnh hưởng bằng event_key và target id rồi mới mở lại.

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

Cá nhân bắt đầu với một issue_type, một kênh và ticket DEMO; AI chỉ tạo facts cùng DRAFT. Đội nhỏ bổ sung KB owner, review queue và SLA card, chạy shadow mode trên khoảng dữ liệu đại diện. Doanh nghiệp thêm state machine, event bus, permission registry, audit store và quan sát theo từng bước.

Trước khi chạy thật, dùng test matrix gồm happy path, duplicate, thiếu order, KB hết hạn, STOP_CONTACT, timeout, delivery unknown và reopen. Mỗi ca kiểm status, owner, source, hành động cấm cùng log. Reviewer ký acceptance criteria; không dựa vào việc bài mẫu “nghe hợp lý”.

Đo tỷ lệ ticket đủ dữ liệu, DRAFT có nguồn, thời gian review, số lỗi dừng đúng, tỷ lệ reopen và phần sửa của người duyệt. Dữ liệu đo phải có denominator, giai đoạn và ghi “minh họa” nếu chưa lấy từ production. Chỉ mở thêm issue_type khi wave trước không có lỗi quyền hoặc consent.

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

Dữ liệu minh họa: ticket `TK-DEMO-028` nhận từ Zalo, order `ORD-DEMO-41`, issue_type `MISSING_ACCESSORY`, KB `KB-RET-07-v4`. Hệ thống tìm thấy ticket Facebook cùng order nên trả `REVIEW_DUPLICATE`; nhân viên xác nhận liên quan, duyệt DRAFT và gửi. Kho cập nhật proof `WH-DEMO-09`; trưởng ca duyệt `CLOSE_READY`. Hai ngày sau có event mới nên trạng thái thành `REOPEN_REVIEW`, không ghi đè lịch sử.

Có thể tự động merge ticket giống nhau không?

Không nên. AI chỉ tạo duplicate candidate kèm khóa và lý do; người có quyền xác nhận merge để tránh gộp nhầm hai vấn đề.

Khi nào ticket được đóng?

Khi có resolution_code, proof_ref, nội dung cập nhật khách và người có quyền duyệt. Gửi tin hoặc hết SLA không phải proof giải quyết.

Timeout khi gửi thì xử lý thế nào?

Giữ trạng thái `DELIVERY_UNKNOWN`, tra target/idempotency key rồi chuyển người nếu chưa xác định; không gửi lại mù.

Khách nhắn sau khi đóng thì sao?

Tạo source event mới và đưa ticket vào `REOPEN_REVIEW`; giữ nguyên log đóng cũ để có lịch sử kiểm toán.

Xem bản đồ AI cho CSKH, dùng bộ prompt ticket hoặc liên hệ NganAds qua Zalo 0983543063 để thiết kế pilot có quyền và rollback rõ.

Workflow

Bước 1: Tiếp nhận bất biến — Xác minh event, tạo event_key và lưu payload tối thiểu; trùng key thì không tạo ticket mới.
Bước 2: Phân loại có review — Chuẩn hóa facts, issue_type và duplicate candidate; thiếu khóa thì NEEDS_INFO.
Bước 3: Tra nguồn có phiên bản — Đọc order view và KB còn hiệu lực; nguồn thiếu hoặc mâu thuẫn thì BLOCKED hoặc ESCALATE.
Bước 4: Tạo DRAFT và duyệt — AI tạo bản nháp có source; nhân viên kiểm facts, consent và quyết định gửi.
Bước 5: Theo dõi resolution — Ghi delivery proof, chờ proof nghiệp vụ, retry có idempotency và chuyển người khi không xác định.
Bước 6: Đóng hoặc mở lại — Người có quyền duyệt close; sự kiện liên quan mới tạo REOPEN_REVIEW, không ghi đè lịch sử.

Prompt mẫu

Chuẩn hóa sự kiện thành ticket facts

MỤC TIÊU: Chuyển sự kiện hỗ trợ thành facts-only mà không suy đoán nguyên nhân.
[ĐẦU VÀO]: [SOURCE_EVENT_ID, CHANNEL, RECEIVED_AT, QUOTE, CONTACT_REF, ORDER_REF, CONSENT].
RÀNG BUỘC: Giữ nguyên quote; trường thiếu ghi MISSING; không tạo lời trả khách.
ĐỊNH DẠNG ĐẦU RA: JSON ticket_facts, missing_fields, candidate_issue_type, confidence, next_status.
VÍ DỤ ĐIỀN SẴN: EVT-DEMO-18; Zalo; thiếu phụ kiện; order ORD-DEMO-41; next_status TRIAGE_REVIEW.

Lập phiếu duplicate candidate

MỤC TIÊU: So sánh ticket mới với candidate mà không tự merge.
[ĐẦU VÀO]: [NEW_TICKET, CANDIDATE_TICKETS, MATCH_KEYS, TIME_WINDOW].
YÊU CẦU: Phân biệt cùng khách, cùng đơn và cùng vấn đề; thiếu khóa trả INCONCLUSIVE.
ĐỊNH DẠNG ĐẦU RA: candidate_id | matched_keys | conflicting_facts | recommendation | reviewer_question.
VÍ DỤ ĐIỀN SẴN: TK-DEMO-028 và TK-DEMO-019 cùng order nhưng khác kênh; REVIEW_DUPLICATE.

Tra KB và tạo DRAFT có nguồn

MỤC TIÊU: Tạo bản nháp từ ticket facts và KB còn hiệu lực.
[ĐẦU VÀO]: [TICKET_FACTS, KB_ARTICLES, ORDER_VIEW, TONE_RULES, ALLOWED_NEXT_STEPS].
CẤM: Không hứa thời gian, không nhận lỗi, không đề xuất bồi hoàn; nguồn hết hạn trả BLOCKED.
ĐỊNH DẠNG ĐẦU RA: DRAFT gồm facts_used, article_id/version, response_text, unknowns, reviewer_checklist.
VÍ DỤ ĐIỀN SẴN: KB-RET-07-v4; xác nhận đã tiếp nhận và cần kho kiểm proof; chờ nhân viên duyệt.

Tạo escalation brief

MỤC TIÊU: Chuyển ticket vượt ranh giới tới đúng owner với đủ bằng chứng.
[ĐẦU VÀO]: [TICKET_HISTORY, ESCALATION_MATRIX, SLA_CARD, SOURCE_REFS].
RÀNG BUỘC: Không kết luận lỗi; không gửi dữ liệu ngoài purpose; nêu rõ điều chưa biết.
ĐỊNH DẠNG ĐẦU RA: reason_code, facts, attempts, source_refs, due_at, next_owner, forbidden_actions.
VÍ DỤ ĐIỀN SẴN: ESCALATE_WAREHOUSE; thiếu proof kiện hàng; owner trưởng kho; refund bị cấm.

Kiểm điều kiện close hoặc reopen

MỤC TIÊU: Kiểm proof trước khi đề xuất CLOSE_READY hoặc REOPEN_REVIEW.
[ĐẦU VÀO]: [CURRENT_STATE, RESOLUTION_CODE, PROOF_REFS, CUSTOMER_UPDATE, NEW_EVENTS, CLOSE_POLICY].
YÊU CẦU: AI chỉ đề xuất; thiếu proof không close; event mới không xóa lịch sử.
ĐỊNH DẠNG ĐẦU RA: proposed_status, evidence_check, missing_items, reviewer, audit_note.
VÍ DỤ ĐIỀN SẴN: có WH-DEMO-09 và bản cập nhật đã duyệt → CLOSE_READY; tin mới → REOPEN_REVIEW.

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

Có thể tự động merge ticket giống nhau không?

Không nên. AI chỉ tạo duplicate candidate kèm khóa và lý do; người có quyền xác nhận merge để tránh gộp nhầm hai vấn đề.

Khi nào ticket được đóng?

Khi có resolution_code, proof_ref, nội dung cập nhật khách và người có quyền duyệt. Gửi tin hoặc hết SLA không phải proof giải quyết.

Timeout khi gửi thì xử lý thế nào?

Giữ trạng thái DELIVERY_UNKNOWN, tra target hoặc idempotency key rồi chuyển người nếu chưa xác định; không gửi lại mù.

Khách nhắn sau khi đóng thì sao?

Tạo source event mới và đưa ticket vào REOPEN_REVIEW; giữ nguyên log đóng cũ để có lịch sử kiểm toán.

Bài liên quan

Pilot một issue_type và một kênh; giữ AI ở READ/CREATE_DRAFT, người duyệt gửi và đóng, mọi nhánh lỗi có owner.