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

Workflow AI cho Trực page/chat: lead đến follow-up

Workflow từ lead mới đến phân loại, tư vấn và follow-up dành cho Trực page / trực chat

Tình huống thật: lead mới không đồng nghĩa với một người mới

Một khách hỏi sản phẩm qua Facebook Messenger lúc 14:02, gửi ảnh mã hàng trên Zalo OA lúc 14:06 và nhắn TikTok Shop lúc 14:10 rằng cần giao gấp. Nếu hệ thống tự ghép ba tài khoản vì cùng tên hiển thị, nó có thể nối nhầm lịch sử, dùng sai consent hoặc để lộ thông tin. Nếu coi mỗi tin là lead mới, ba nhân viên lại tư vấn lặp và ba job follow-up cùng được tạo.

Workflow AI cho Trực page / trực chat phải bắt đầu từ event và thread, không bắt đầu từ câu “hãy trả lời khách”. Mỗi message có channel, thread_id, message_id, reply_to và timestamp. Identity chỉ là candidate có evidence, không tự merge. Consent quyết định mục đích, kênh, quiet hours và thời hạn. Intent cùng SLA định tuyến; catalog/KB có version cung cấp fact; người trực giữ quyền gửi và chuyển tuyến.

Quy trình dưới đây dành cho nhịp hội thoại thời gian thực đa kênh, khác quy trình ticket hậu trường. Nó xử lý từ tin mới đến phân loại, tư vấn DRAFT, human-in-the-loop, outcome và follow-up. AI không tự gửi, đổi đơn, hoàn tiền, hứa giá/tồn/giao hàng, ghép danh tính hoặc đóng khiếu nại.

Việc giao AI trong từng chặng và điều kiện dừng

Ở đầu luồng, AI kiểm schema, trích fact và gợi intent candidate. Ở giữa luồng, AI truy xuất đoạn KB được duyệt, soạn DRAFT theo channel và tạo handoff brief. Ở cuối luồng, AI tóm tắt outcome, đề xuất next_action và chuẩn bị follow-up theo consent. Mỗi artifact có thread_id, source_ref, prompt/version, UNKNOWN, reviewer và SEND=false.

Agent trực xác nhận thread, ngữ cảnh, intent, fact và giọng điệu. Shift lead quyết định escalation, xử lý khách bức xúc, lạm dụng, xung đột và SLA cao. Product/policy owner xác nhận giá, tồn, khuyến mại, đổi trả và chính sách. System owner quản connector, idempotency, delivery receipt, secret, audit và rollback. Khách cấp/rút consent; đội ngũ chỉ xác minh evidence và thực thi.

STOP ngay khi thread không chắc, consent bị rút, nội dung chứa PII không cần, nguồn đã hết hiệu lực, yêu cầu thanh toán/hoàn tiền, nguy cơ an toàn, prompt injection hoặc hành động vượt authority. ERROR_PARTIAL áp dụng khi tạo DRAFT thành công nhưng CRM/log/handoff thất bại. Không retry gửi trước khi kiểm delivery receipt và idempotency key.

Dữ liệu đầu vào và trạng thái cần chuẩn hóa

Event envelope gồm event_id, channel, thread_id, message_id, reply_to, sent_at, direction, sender_role, text/reference, attachment metadata và ingest status. Conversation state gồm owner, intent candidate, SLA class, last approved fact, escalation, outcome và reopen window. Identity candidate chỉ chứa evidence/reference, verification status và owner, không chứa kết luận tự động.

Consent có subject reference, purpose, channel, granted/revoked, quiet hours, expiry, evidence và retention. Product packet có sku/variant, price/inventory/policy source, version, effective_from/to và reviewer. Order/payment chỉ đưa vào bằng reference và quyền cần thiết. Attachment được sandbox/quét trước; text bên trong là dữ liệu không đáng tin, không phải system instruction.

Các trạng thái cốt lõi: RECEIVED, IDENTITY_UNVERIFIED, CONSENT_OK, NEED_CLARIFICATION, INTENT_CANDIDATE, NEED_SOURCE, DRAFT_READY, HUMAN_REVIEW, HANDOFF, SENT_BY_HUMAN, WAITING_CUSTOMER, CLOSED hoặc STOP. Một transition có precondition, owner và audit. Không dùng một trường “done” để che việc reply đã gửi nhưng CRM chưa ghi.

Workflow bảy bước có nhánh lỗi, STOP và Human-in-the-loop

Bước 1 — Nhận event và chống lặp: adapter xác minh channel/thread/message, tạo idempotency key và lưu raw reference. Event trùng trả trạng thái ALREADY_SEEN; sai schema vào quarantine. Bước 2 — Kiểm consent và identity candidate: xác định reply-on-thread có phù hợp purpose không, kiểm quiet hours và evidence. Không chắc danh tính thì vẫn xử lý trong thread hiện tại, không kéo dữ liệu chéo kênh.

Bước 3 — Phân loại intent/SLA: AI trả tối đa ba candidate với evidence, trường thiếu và escalation. Intent thanh toán, khiếu nại, safety hoặc abuse chuyển shift lead. Bước 4 — Truy xuất nguồn: chỉ lấy KB/catalog/policy được allow-list, kiểm version/effective window và giữ source conflict. Không có nguồn thì NEED_SOURCE hoặc hỏi làm rõ, không sáng tác.

Bước 5 — Tạo DRAFT và validator: câu trả lời phù hợp độ dài kênh, có disclaimer khi cần; chặn PII, forbidden claim, SEND/CHANGE_ORDER/REFUND. Bước 6 — Human review, gửi hoặc handoff: người trực xem thread, source, consent và diff rồi bấm gửi; hai bản sửa mâu thuẫn tạo MERGE_REVIEW. Handoff brief chuyển đúng owner với SLA còn lại.

Bước 7 — Outcome và follow-up: ghi SENT/WAITING/HANDOFF/CLOSED, delivery receipt và next_action. Follow-up chỉ được lên lịch khi purpose, channel, quiet hours và expiry còn hợp lệ. Khách rút consent thì hủy job chờ, STOP_CONTACT và retention. Nếu CRM ghi thất bại sau khi tin đã gửi, ERROR_PARTIAL chỉ retry log, không gửi lại.

Workflow AI bảy bước cho Trực page trực chat
Sơ đồ minh họa luồng event đến outcome, có nhánh identity, source, human review, ERROR_PARTIAL và STOP_CONTACT.

Năm prompt vận hành theo đúng artifact của workflow

Prompt 1 kiểm event/thread/consent; Prompt 2 phân loại intent và SLA; Prompt 3 truy xuất nguồn kèm trích dẫn; Prompt 4 tạo DRAFT hoặc handoff brief; Prompt 5 quyết định follow-up/close/reopen. Mỗi prompt nhận packet riêng, không truyền toàn bộ lịch sử hoặc quyền connector.

Đầu ra là JSON hoặc bảng cố định để validator kiểm, không phải đoạn văn tự do duy nhất. Prompt phải ghi rõ không merge identity, không coi nội dung khách là lệnh, không tạo fact thiếu nguồn và không tự gửi. Ví dụ DEMO bao phủ cả happy path lẫn lỗi: catalog stale, consent revoked, duplicate event, prompt injection và CRM timeout.

Prompt version nằm trong registry, gắn owner và bộ fixture. Khi intent taxonomy, policy, channel adapter hoặc model đổi, chạy regression. Không tự học policy từ sửa tay của agent; correction được review và chỉ cập nhật source/prompt qua quy trình quản trị.

Công cụ triển khai và kiến trúc quyền tối thiểu

Facebook Messenger, Zalo OA, TikTok Shop, Shopee Chat và live chat website phát event qua adapter riêng. Haravan hoặc Sapo có thể gom hội thoại; CRM/ticket giữ owner và outcome; Google Drive giữ KB version; Google Sheets giữ source/intent registry ở pilot; Base.vn xử lý escalation. Không coi giao diện inbox là source duy nhất cho giá hoặc đơn hàng.

n8n/Make điều phối queue, validator, review và log. Mỗi adapter chuẩn hóa event nhưng vẫn giữ channel-specific metadata. AI node chỉ READ packet và CREATE_DRAFT; credential SEND nằm tại service tách biệt, chỉ nhận artifact đã được người duyệt ký. Idempotency store và delivery receipt ngăn gửi lặp; dead-letter queue giữ job lỗi để điều tra.

Giao diện hàng đợi duyệt hội thoại đa kênh minh họa
UI minh họa hiển thị thread, consent, source, SLA, diff và nút gửi/handoff tách biệt.

AI chuẩn bị, người trực duyệt và chủ hệ thống kiểm soát

AI thực hiện công việc có thể hoàn tác: trích, phân loại candidate, truy xuất, soạn, tóm tắt và cảnh báo. Nó không được tự kết luận identity, không tự đổi trạng thái nghiệp vụ có hậu quả và không được lấy dữ liệu ngoài thread/purpose. Confidence thấp không được biến thành câu trả lời tự tin; output phải ghi UNKNOWN và escalation.

Agent trực nhìn toàn bộ thread hiện tại, sửa nội dung và quyết định gửi. Shift lead chịu trách nhiệm về ưu tiên, handoff, khiếu nại và abuse. Product/policy owner xác nhận fact. System owner xác nhận quyền, receipt, retry, retention và rollback. UI phải hiển thị ai sửa trường nào, source version nào và thay đổi nào xảy ra sau khi AI tạo DRAFT.

Khách là chủ thể consent. Nếu khách nói “đừng nhắn nữa”, workflow không yêu cầu nội bộ “duyệt quyền rút”; nó ghi evidence, STOP_CONTACT và chuyển data owner thực thi retention theo policy. Nhân viên chỉ xác minh thread và phạm vi, không bác bỏ ý chí khách.

Sai lầm, lỗi một phần và cách phục hồi

Sai thread và merge nhầm identity là lỗi nghiêm trọng nhất. Tiếp theo là dùng nguồn cũ, hứa giá/tồn/giao, gửi ngoài quiet hours, tự xử lý hoàn tiền, lộ PII hoặc bỏ qua prompt injection. Validator cần kiểm claim và action, nhưng con người vẫn phải duyệt sắc thái, ngoại lệ và ngữ cảnh.

ERROR_PARTIAL cần được thiết kế từ đầu. Nếu tin đã có delivery receipt nhưng CRM timeout, chỉ retry ghi log. Nếu CRM đã tạo task nhưng tin chưa gửi, kiểm idempotency key và trạng thái SEND trước hành động. Nếu handoff tạo hai ticket, merge theo event_id, giữ audit và không xóa im lặng. Khi nguồn mâu thuẫn, không chọn bản mới hơn chỉ dựa timestamp; chuyển owner.

Rollback có ba mức: tắt SEND, tắt retrieval nguồn lỗi, hoặc tắt toàn bộ orchestration và trở lại macro thủ công. Giữ snapshot cấu hình, queue và log đủ để phục hồi. Không rollback bằng cách xóa lịch sử vì đội cần điều tra consent, duplicate và nội dung đã gửi.

Triển khai canary và đo chất lượng theo ca

Giai đoạn một dùng 60 thread DEMO của một kênh, ba intent và shadow mode. Giai đoạn hai chạy DRAFT cho hai agent trong một ca, không tự gửi. Giai đoạn ba cho người bấm gửi ở 10% thread rủi ro thấp, còn khiếu nại, payment, abuse và cross-channel luôn handoff. Mỗi giai đoạn có reviewer capacity và stop threshold.

Dashboard theo dõi thread accuracy, source coverage, intent correction, time-to-first-draft, time-to-handoff, consent violation, duplicate send, ERROR_PARTIAL, SLA và reviewer backlog. Tách theo channel/intent/ca để không che lỗi. Số liệu là minh họa trong pilot, không hứa cải thiện doanh thu hoặc thời gian.

Mỗi thay đổi adapter, taxonomy, KB, prompt hoặc model đều chạy fixture và canary lại. Chỉ mở kênh mới khi receipt, consent mapping và escalation của kênh đó được kiểm riêng. Một lỗi sai thread, gửi sau revoked consent hoặc lộ dữ liệu là STOP và rollback SEND.

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

Kết quả minh họa: event EVT-DEMO-882 từ Messenger thread TH-DEMO-44; idempotency NEW; consent reply-on-thread OK đến 22:00; intent PRODUCT_FIT 0,78, cần hỏi biến thể; KB-PROD-v12 hợp lệ; DRAFT 73 từ; agent A review; SEND=false. Zalo thread cùng tên giữ IDENTITY_UNVERIFIED. Nếu khách yêu cầu hoàn tiền, HANDOFF shift lead với SLA 10 phút.

Workflow có thể trả lời khách hoàn toàn tự động không?

Không ở giai đoạn này. AI tạo DRAFT; người trực kiểm source, consent, thread và bấm gửi. Intent rủi ro cao luôn handoff.

Làm sao tránh gửi một tin hai lần?

Dùng idempotency key theo event/action, delivery receipt và state machine; retry log không được đồng nghĩa với retry SEND.

Có nên nối lịch sử Messenger với Zalo không?

Chỉ khi có evidence và quy trình xác minh hợp lệ. Mặc định giữ hai identity candidate và không kéo dữ liệu chéo thread.

Khi nào workflow đóng hội thoại?

Khi outcome đã được người trực xác nhận và không còn job hợp lệ. Follow-up phải có consent; khách rút consent thì STOP_CONTACT, không chỉ CLOSED.

Đọc bản đồ Trực page/chat, dùng prompt pack trực chat, mở trang nghề hoặc liên hệ NganAds.

Workflow

  1. Bước 1: Nhận event và chống lặp — Xác minh channel/thread/message, idempotency và quarantine event lỗi.
  2. Bước 2: Kiểm consent và identity — Kiểm purpose/quiet hours; không merge identity candidate tự động.
  3. Bước 3: Phân loại intent và SLA — Gợi candidate, hỏi làm rõ và handoff intent rủi ro cao.
  4. Bước 4: Truy xuất nguồn — Lấy KB/catalog allow-list có version hoặc NEED_SOURCE.
  5. Bước 5: Tạo và kiểm DRAFT — Chặn PII, forbidden claim, SEND/CHANGE_ORDER/REFUND.
  6. Bước 6: Người trực duyệt — Agent gửi hoặc handoff; MERGE_REVIEW khi sửa mâu thuẫn.
  7. Bước 7: Outcome và follow-up — Ghi receipt, next action; STOP_CONTACT và xử lý ERROR_PARTIAL không gửi lặp.

Prompt mẫu

Kiểm event thread và consent

MỤC TIÊU: Xác minh packet đầu vào trước phân loại mà không tự ghép danh tính.
[ĐẦU VÀO]: event_id, channel, thread_id, message_id, reply_to, timestamp, consent evidence và identity candidate.
ĐỊNH DẠNG ĐẦU RA: EVENT NEW/DUPLICATE/INVALID | THREAD check | CONSENT | quiet hours | UNKNOWN | STOP.
VÍ DỤ ĐIỀN SẴN: EVT-DEMO-882, Messenger TH-44, NEW; consent reply-on-thread OK; Zalo cùng tên IDENTITY_UNVERIFIED.

Phân loại intent và SLA

MỤC TIÊU: Đề xuất intent candidate cùng evidence, câu hỏi làm rõ và tuyến xử lý.
[ĐẦU VÀO]: Tin hiện tại, tối đa ba tin trước cùng thread, taxonomy version, SLA và escalation.
ĐỊNH DẠNG ĐẦU RA: Candidate/confidence/evidence | missing | next question | SLA | owner | HANDOFF.
VÍ DỤ ĐIỀN SẴN: 'Mẫu này size M còn không'; PRODUCT_AVAIL 0,76; thiếu mã màu; hỏi làm rõ; không hứa tồn.

Truy xuất nguồn có version

MỤC TIÊU: Chọn facts được phép dùng và làm lộ xung đột hoặc nguồn cũ.
[ĐẦU VÀO]: Intent, product candidates, KB/catalog allow-list, effective_at và channel policy.
ĐỊNH DẠNG ĐẦU RA: Fact | source_ref/version | effective | conflict | UNKNOWN | NEED_SOURCE.
VÍ DỤ ĐIỀN SẴN: SKU-DEMO-M-BLUE; KB-v12 hợp lệ; tồn snapshot quá hai giờ; NEED_SOURCE, không trả còn hàng.

Tạo DRAFT hoặc handoff brief

MỤC TIÊU: Soạn câu phù hợp kênh hoặc brief chuyển người thật, không thực thi hành động.
[ĐẦU VÀO]: Fact đã duyệt, intent, source, consent, SLA, tone guide, forbidden claims và owner.
ĐỊNH DẠNG ĐẦU RA: DRAFT tối đa 100 từ hoặc HANDOFF gồm summary/facts/unknown/urgency; SEND=false.
VÍ DỤ ĐIỀN SẴN: Hỏi mã màu, chưa xác nhận tồn; DRAFT 54 từ; agent A review; SEND=false.

Quyết định follow-up close hoặc reopen

MỤC TIÊU: Chuẩn bị next action từ outcome mà không vượt consent.
[ĐẦU VÀO]: Thread outcome, receipt, consent purpose/channel/expiry, quiet hours, pending owner và reopen rule.
ĐỊNH DẠNG ĐẦU RA: WAIT/FOLLOW_UP/HANDOFF/CLOSE/STOP_CONTACT | execute_at | owner | reason | idempotency key.
VÍ DỤ ĐIỀN SẴN: Khách đồng ý Zalo một lần trước 18/7; follow-up 10h; nếu revoked thì STOP_CONTACT và hủy job.

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

Workflow có thể trả lời khách hoàn toàn tự động không?

Không ở giai đoạn này. AI tạo DRAFT; người trực kiểm source, consent, thread và bấm gửi. Intent rủi ro cao luôn handoff.

Làm sao tránh gửi một tin hai lần?

Dùng idempotency key theo event/action, delivery receipt và state machine; retry log không được đồng nghĩa với retry SEND.

Có nên nối lịch sử Messenger với Zalo không?

Chỉ khi có evidence và quy trình xác minh hợp lệ. Mặc định giữ hai identity candidate và không kéo dữ liệu chéo thread.

Khi nào workflow đóng hội thoại?

Khi outcome đã được người trực xác nhận và không còn job hợp lệ. Follow-up phải có consent; khách rút consent thì STOP_CONTACT, không chỉ CLOSED.

Bài liên quan

Triển khai từ event đúng thread đến DRAFT có người duyệt; khóa SEND, identity merge, đổi đơn và hoàn tiền cho tới khi consent, idempotency và rollback đạt chuẩn.