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

Workflow AI Sale B2C: tư vấn và follow-up có consent

Workflow từ lead mới đến phân loại, tư vấn và follow-up dành cho Sale B2C

Tình huống lead B2C: ba kênh, một nhu cầu và vài phút để hiểu đúng

Khách bình luận dưới livestream “còn size M không?”, rồi gửi Messenger hỏi màu khác và nhắn Zalo cho cửa hàng về phí giao. TikTok Shop đã tạo một conversation ID, fanpage có thread khác, còn Sapo chưa nhận customer profile. KiotViet báo tồn theo chi nhánh nhưng bản đồng bộ gần nhất cách đây vài phút. Nếu workflow coi mỗi tin là một lead mới, khách sẽ nhận nhiều câu hỏi lặp; nếu tự gộp theo tên hiển thị, hệ thống có thể nối nhầm hai người.

Workflow AI cho Sale B2C trong bài ưu tiên phản hồi có kiểm soát: tạo event chống lặp, kiểm consent theo kênh, đề xuất thread link, phân loại intent, routing theo giờ và queue, giao nhân viên trực tiếp tư vấn, kiểm lại giá-tồn trước cart, rồi handoff order cùng hậu mãi. AI chuẩn bị dữ liệu và DRAFT; nó không chat thay nhân viên, không reserve hàng, không nhận thanh toán, không gửi follow-up và không duyệt đổi trả. Tốc độ được đo từ lúc event vào đúng queue, không phải số tin máy tự phát đi.

Việc giao cho AI ở từng điểm chuyển trạng thái

Tại intake, Agent chuẩn hóa channel event, ẩn dữ liệu không cần thiết, tạo idempotency key và kiểm consent purpose. Ở triage, nó phân loại intent như hỏi thông tin, tìm lựa chọn, giá-khuyến mại, tồn kho, trạng thái đơn, đổi trả hoặc cần người hỗ trợ. Agent có thể tìm catalog candidate, nêu thuộc tính thiếu và chuẩn bị conversation summary cho Sale. Mọi dữ liệu giá, tồn và policy đều kèm source timestamp.

Người Sale đọc brief, hỏi lại nhu cầu cá nhân và tư vấn. Sau outcome, AI có thể tạo cart DRAFT, checklist xác minh, order handoff và task follow-up theo consent. Với hậu mãi, nó gom order proof, policy version và lý do thành return case DRAFT. Nhân viên xác nhận SKU, khả dụng, promotion, nội dung gửi và trạng thái case. Workflow không dùng sentiment để chọn khách ưu tiên, không tự đề xuất ưu đãi ngoài rule và không coi việc khách ngừng trả lời là quyền nhắn ở kênh khác.

Dữ liệu cần chuẩn bị cho inbox, tư vấn và hậu mãi

CHANNEL-EVENT cần EVENT-ID, provider event ID, received_at, thread ID, channel, message, attachment reference, consent purpose và customer reference nếu đã xác minh. Identity-link candidate dùng channel IDs, verification evidence và mức match; tên hoặc nội dung giống nhau không đủ. Intent router cần taxonomy version, queue, giờ hoạt động, location, language và escalation rule. Payload ngoài schema được giữ ở quarantine để kiểm.

Consultation packet gồm nhu cầu khách đã nói, product attribute, khoảng giá nếu khách nêu, preference, câu hỏi mở và conversation source. Product check dùng SKU, variant, price version, promotion validity, inventory location, updated_at và reservation status. Cart/order handoff có CART-ID, line items, fulfillment, total DRAFT, payment route, address token cùng owner; không lưu chi tiết thanh toán trong prompt. Follow-up và return cần order ID, delivered state, consent, quiet hours, policy version, deadline, evidence và CSKH reviewer.

Workflow bảy bước từ channel event đến chăm sóc

Bước 1 — Intake và idempotency: gateway ghi payload chỉ đọc, tạo EVENT-ID và loại webhook lặp. Consent không phù hợp trả STOP_CONTACT. Bước 2 — Thread/customer link: Agent tạo candidate; nhân viên xác nhận LINK hoặc SEPARATE. Thiếu bằng chứng giữ IDENTITY_REVIEW, không mở dữ liệu đơn.

Bước 3 — Intent, SLA và routing: rule engine chọn queue theo taxonomy, giờ hoạt động, chi nhánh và escalation; đa ý định hoặc khiếu nại chuyển HUMAN_PRIORITY. Bước 4 — Handoff tư vấn: AI tạo brief cùng câu hỏi; nhân viên trực tiếp trao đổi và ghi CONFIRMED_NEED. Không có outcome thì không tạo cart.

Bước 5 — Kiểm giá, promotion và stock: adapter đọc snapshot mới, nhân viên xác nhận variant; dữ liệu quá hạn trả STOCK_RECHECK. Bước 6 — Cart và order handoff: Agent tạo DRAFT, order operator kiểm tổng, phương thức và fulfillment rồi mới ghi hệ thống. Bước 7 — Follow-up hoặc return: chỉ tạo task theo consent và quiet hours. STOP_CONTACT dừng gửi; return ngoài rule chuyển EXCEPTION_REVIEW, không tự hứa hoàn tiền.

Workflow bảy bước Sale B2C từ inbox đến tư vấn, order và đổi trả
Sơ đồ minh họa các nhánh consent, identity review, stock recheck và ngoại lệ đổi trả.

Năm prompt hỗ trợ vận hành state machine B2C

Năm prompt tương ứng năm packet chuyển giao: event validation, identity-link candidate, intent-routing decision, consultation brief và cart/order/return handoff. Chúng không viết kịch bản xử lý phản đối chi tiết; phần đó nằm ở prompt pack riêng. Mỗi đầu ra có state, error code, source và owner. Prompt không gọi API, không sửa record và không gửi tin, nên có thể kiểm trước khi adapter xử lý.

Khi điền, dùng event cùng thread ID giả lập, catalog snapshot có timestamp và policy version. Đặt rõ trạng thái thất bại: ALREADY_RECEIVED, STOP_CONTACT, IDENTITY_REVIEW, NEEDS_CLARIFICATION, STOCK_RECHECK, ORDER_REVIEW hoặc RETURN_EXCEPTION. Không yêu cầu AI “tự giải quyết nếu có thể”. Nếu intent liên quan an toàn, tranh chấp hoặc dữ liệu nhạy cảm, prompt phải route người phụ trách mà không tạo tư vấn suy đoán.

Công cụ kết nối và cách phục hồi khi lỗi

Zalo, Messenger, TikTok Shop, Shopee và fanpage đi qua channel adapter; Sapo, KiotViet hoặc Haravan giữ catalog/order tùy nguồn chính; Base.vn quản lý queue, approval và case; Google Sheets có thể chứa mapping chi nhánh hoặc SLA tạm. CRM chỉ giữ customer link cùng consent đã xác minh. Hình ảnh từ Canva là asset marketing đã duyệt, không xác nhận tồn hay đặc tính nếu catalog không ghi.

Mỗi adapter dùng idempotency, retry giới hạn và dead-letter queue. Lỗi mạng có thể retry; lỗi consent, identity, price, order hoặc policy phải chờ owner. Optimistic version ngăn hai nhân viên ghi đè cart. Target proof gồm record ID cùng version sau ghi; thiếu proof thì ERROR_PARTIAL. Dashboard hiển thị tuổi event, queue, consent, source freshness và blocker. Người vận hành có thể replay event an toàn bằng cùng idempotency key, không tạo order thứ hai.

Bảng trạng thái event, consent, stock, cart và return Sale B2C
Hình minh họa state board B2C với owner, thời hạn nguồn và mã lỗi phục hồi.

AI làm gì và người duyệt xác nhận gì

AI chuẩn hóa event, đề xuất link, phân loại intent, tìm catalog và tạo packet. Nó có thể báo rằng promotion hết hạn, variant chưa rõ, stock snapshot cũ, order không thuộc profile đã xác minh hoặc return request thiếu bằng chứng. Agent không xác minh danh tính bằng suy luận, không chọn sản phẩm thay khách, không quyết định giá, không reserve stock và không đánh dấu case đã giải quyết.

Nhân viên trực inbox xác nhận thread, nhu cầu cùng nội dung gửi; Sale tư vấn; catalog và pricing owner quản lý dữ liệu; kho xác nhận hàng; order operator kiểm giao dịch; CSKH duyệt đổi trả; manager xử lý ngoại lệ. IT quản lý queue cùng connector. Khi một người override route hoặc policy, họ ghi reason code. Mọi handoff có owner cụ thể và deadline; “đội bán hàng” không được dùng như một owner chung không truy trách nhiệm.

Sai lầm, nhánh lỗi và điều kiện STOP

Sai lầm dễ gặp là dedupe theo số điện thoại chưa xác minh, trả từ catalog description khi câu hỏi là tồn kho, hoặc áp promotion từ screenshot. Một lỗi khác là tạo cart trước khi khách xác nhận variant, coi cart là order, và tạo follow-up dù consent chỉ dành cho trả lời yêu cầu. Với return, hệ thống không được tự kết luận lỗi thuộc khách hoặc cửa hàng từ một đoạn chat.

STOP bắt buộc khi khách yêu cầu ngừng, consent hết hạn, attachment bị cách ly, identity conflict, dữ liệu đơn không thuộc profile, nguồn giá không có hiệu lực hoặc nội dung cần chuyên gia. STOCK_RECHECK và ORDER_REVIEW là trạng thái chờ, không phải lỗi để Agent lách. Quiet hours được áp theo kênh. Không chuyển sang Zalo khi Messenger bị STOP. Nếu adapter gửi một phần, khóa retry gửi và chuyển người vận hành kiểm receipt.

Triển khai theo ca trực và mở rộng đa kênh

Chạy thử với một kênh, một nhóm sản phẩm và một ca trực. Đầu tiên chỉ bật intake, intent cùng consultation brief; nhân viên duyệt mọi packet. Dùng tập hội thoại giả lập bao phủ typo, nhiều ý định, đổi kênh và yêu cầu đổi trả. Đo age-to-queue, route correction, source stale, draft correction, consent block và handoff completion. Không lấy tỷ lệ automation làm mục tiêu độc lập.

Khi thêm kênh, giữ event schema chung nhưng consent, rate limit và provider receipt riêng. Khi thêm cửa hàng, bổ sung location routing cùng stock source priority. Sales operations quản taxonomy; store ops quản inventory; CSKH quản return policy; IT quản adapter. Mỗi wave thay đổi chỉ mở sau regression test và rollback plan. Một connector mới không được mặc định kế thừa quyền gửi của connector cũ.

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

Dữ liệu minh họa: FLOW-B2C-DEMO-05 nhận 32 event, loại 5 bản lặp, đưa 3 thread vào IDENTITY_REVIEW và 4 yêu cầu vào STOCK_RECHECK. Có 11 consultation brief, 6 cart DRAFT và 2 return case chờ CSKH; không gửi tự động.

AI có thể trả lời khách ngay để đạt SLA không?

AI tạo DRAFT nhanh; nhân viên duyệt và gửi. SLA đo cả routing đúng, source đúng và consent, không chỉ thời điểm sinh chữ.

Khi nào được gắn hai thread với một khách?

Khi có evidence identity theo policy và người có quyền xác nhận; tên hiển thị hoặc sản phẩm hỏi giống nhau không đủ.

Cart DRAFT khác order thế nào?

Cart là đề xuất line item chờ kiểm; order chỉ được tạo sau xác nhận variant, giá, fulfillment và hành động của operator.

Return request ngoài policy xử lý ra sao?

Tạo case EXCEPTION_REVIEW kèm order proof và policy version; manager hoặc CSKH owner quyết định, AI không hứa kết quả.

Đọc bản đồ quyền B2C và dùng prompt pack B2C cho tác vụ tư vấn. Cần dựng queue theo hệ thống hiện tại, liên hệ NganAds hoặc Zalo 0983543063.

Workflow

  1. Bước 1: Intake và idempotency — Ghi channel event chỉ đọc, chống lặp và kiểm consent; vi phạm trả STOP_CONTACT.
  2. Bước 2: Xác minh thread/customer link — AI tạo candidate; nhân viên chọn LINK hoặc SEPARATE, thiếu bằng chứng giữ IDENTITY_REVIEW.
  3. Bước 3: Intent, SLA và routing — Áp taxonomy, giờ hoạt động, location cùng escalation; đa ý định nhạy cảm chuyển HUMAN_PRIORITY.
  4. Bước 4: Người Sale trực tiếp tư vấn — AI chuẩn bị brief; nhân viên hỏi lại, tư vấn và ghi CONFIRMED_NEED trước bước cart.
  5. Bước 5: Kiểm giá và khả dụng — Đọc source mới, xác nhận variant; dữ liệu quá hạn trả STOCK_RECHECK, không cam kết.
  6. Bước 6: Cart và order handoff — AI tạo DRAFT; operator kiểm tổng, fulfillment, payment route và target proof trước khi ghi.
  7. Bước 7: Follow-up hoặc return case — Task tuân consent/quiet hours; STOP_CONTACT chặn gửi, ngoài policy chuyển RETURN_EXCEPTION.

Prompt mẫu

Xác thực channel event và consent

MỤC TIÊU: Kiểm event B2C trước khi đưa vào queue, loại bản lặp và chặn mục đích liên hệ không được phép.

[ĐẦU VÀO]
CHANNEL_EVENT = [PROVIDER-ID, THREAD-ID, TIMESTAMP, PAYLOAD ĐÃ ẨN]
IDEMPOTENCY_RULE = [TRƯỜNG TẠO KHÓA]
CONSENT_RECORD = [CHANNEL, PURPOSE, EXPIRY, STOP]
SCHEMA_VERSION = [PHIÊN BẢN]

YÊU CẦU: Không gửi phản hồi. Trả RECEIVED, ALREADY_RECEIVED, NEEDS_INPUT, QUARANTINE hoặc STOP_CONTACT; nêu lý do.

ĐỊNH DẠNG ĐẦU RA: EVENT-ID | Khóa lặp | Schema | Consent | Trạng thái | Error code | Queue | Reviewer.

VÍ DỤ ĐIỀN SẴN: EVT-B2C-DEMO-61 từ Messenger giả lập bị webhook gửi hai lần; bản thứ hai ALREADY_RECEIVED.

Tạo thread-link candidate

MỤC TIÊU: Đề xuất liên kết thread/channel với customer reference để nhân viên xác minh, không tự mở dữ liệu đơn.

[ĐẦU VÀO]
THREAD_METADATA = [CHANNEL-ID, VERIFIED SIGNALS]
CUSTOMER_CANDIDATES = [CUSTOMER-ID, CHANNEL LINKS, STATUS]
IDENTITY_POLICY = [EVIDENCE ĐỦ VÀ CẤM DÙNG]
CONFLICTS = [TRÙNG TÊN, SHARED PHONE, FAMILY ACCOUNT]

YÊU CẦU: Không link tự động. Thiếu evidence trả IDENTITY_REVIEW; không hiển thị order detail trước xác minh.

ĐỊNH DẠNG ĐẦU RA: Candidate | Evidence hợp lệ | Conflict | Đề xuất LINK/SEPARATE/HOLD | Reviewer | Dữ liệu được phép.

VÍ DỤ ĐIỀN SẴN: THREAD-DEMO-18 chỉ trùng tên với hai profile; kết quả HOLD và không trả order.

Phân loại intent, SLA và route

MỤC TIÊU: Phân loại event theo taxonomy đã duyệt và chọn queue có owner.

[ĐẦU VÀO]
MESSAGE = [NỘI DUNG ĐÃ ẨN]
INTENT_TAXONOMY = [VERSION VÀ ĐỊNH NGHĨA]
QUEUE_POLICY = [GIỜ, LOCATION, SLA, FALLBACK]
ESCALATION_RULES = [KHIẾU NẠI, AN TOÀN, THANH TOÁN]

YÊU CẦU: Cho phép MULTI_INTENT và CLARIFY; không dùng sentiment làm route duy nhất. Trường nhạy cảm chuyển HUMAN_PRIORITY.

ĐỊNH DẠNG ĐẦU RA: EVENT-ID | Intent | Evidence text | Queue | SLA | Clarifying question DRAFT | Escalation | Owner.

VÍ DỤ ĐIỀN SẴN: MSG-B2C-DEMO hỏi size và báo giao sai; route CSKH/HUMAN_PRIORITY, không chỉ PRODUCT_QUERY.

Chuẩn bị consultation brief

MỤC TIÊU: Tạo brief để nhân viên trực tiếp tư vấn dựa trên nhu cầu khai báo và catalog có nguồn.

[ĐẦU VÀO]
CONVERSATION_SUMMARY = [FACT CÓ EVENT-ID]
DECLARED_NEEDS = [LOẠI, VARIANT, DỊP, KHOẢNG GIÁ NẾU CÓ]
CATALOG_VIEW = [SKU, ATTRIBUTE, SOURCE TIMESTAMP]
UNKNOWN_FIELDS = [TRƯỜNG CẦN HỎI]

YÊU CẦU: Không chọn thay khách, không báo stock/giá như cam kết và không gửi. Tách match, missing và câu hỏi.

ĐỊNH DẠNG ĐẦU RA: Brief DRAFT gồm Nhu cầu | Evidence | SKU candidate | Lý do | Freshness | Unknown | Câu hỏi | Sale owner.

VÍ DỤ ĐIỀN SẴN: NEED-B2C-DEMO-09 thiếu location và size; brief phải hỏi trước khi kiểm stock.

Tạo handoff cart, order hoặc return

MỤC TIÊU: Chuyển outcome do nhân viên xác nhận thành packet đúng state và nhánh lỗi.

[ĐẦU VÀO]
CONFIRMED_OUTCOME = [OUTCOME-ID, OWNER]
PRODUCT_STATE = [SKU, PRICE VERSION, PROMOTION, STOCK TIMESTAMP]
ORDER_STATE = [CART/ORDER-ID, FULFILLMENT, PAYMENT STATE]
RETURN_CONTEXT = [POLICY VERSION, PROOF, REQUEST]

YÊU CẦU: Không reserve, tạo payment, gửi hay refund. Source stale trả STOCK_RECHECK; order mismatch trả ORDER_REVIEW; ngoài policy trả RETURN_EXCEPTION.

ĐỊNH DẠNG ĐẦU RA: State | Packet DRAFT | Source/version | Missing | Error code | Owner | Human action | Target proof.

VÍ DỤ ĐIỀN SẴN: CART-B2C-DEMO-14 dùng stock cũ và return không liên quan; tạo hai packet STOCK_RECHECK và RETURN_EXCEPTION riêng.

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

AI có thể trả lời khách ngay để đạt SLA không?

AI tạo DRAFT; nhân viên duyệt và gửi. SLA đo cả routing đúng, source đúng và consent.

Khi nào được gắn hai thread với một khách?

Khi có evidence identity theo policy và người có quyền xác nhận; tên hiển thị giống nhau không đủ.

Cart DRAFT khác order thế nào?

Cart là đề xuất line item chờ kiểm; order chỉ tạo sau xác nhận variant, giá, fulfillment và operator.

Return request ngoài policy xử lý ra sao?

Tạo case EXCEPTION_REVIEW kèm order proof và policy version để manager hoặc CSKH owner quyết định.

Bài liên quan

Muốn dựng workflow Sale B2C có inbox queue, consent, stock recheck và return handoff theo hệ thống hiện tại? Liên hệ NganAds để thiết kế state machine.