AI Agent cho Bán hàng đa kênh: bản đồ công việc, dữ liệu và giới hạn
Tình huống thực tế của Bán hàng đa kênh trên nhiều kênh
Một mẫu bình giữ nhiệt DEMO-BGN-24 được đổi tên trên website, chạy khuyến mại riêng ở Shopee và có hai mã listing cũ trên TikTok Shop. KiotViet báo còn 18 chiếc, Haravan giữ một bản tồn chậm hơn, còn bảng đối soát COD của đơn vị vận chuyển chưa khớp ba đơn hoàn. Nhân viên không thiếu dữ liệu; họ thiếu cách biết bản ghi nào là nguồn, dữ liệu nào đã cũ và hành động nào cần người chịu trách nhiệm duyệt.
Bài này giải quyết bản đồ cơ hội và giới hạn trước khi chọn pilot. Trong phạm vi bài, “AI Agent cho Bán hàng đa kênh” là cách tổ chức nguồn, candidate và review chứ không phải trao quyền quyết định cho mô hình. Trọng tâm không phải tự động hóa toàn bộ mà là biết việc nào đủ nguồn, việc nào cần chuyên gia và use case nào có thể rollback. Nhân viên có thể dùng AI để đọc, so sánh và soạn candidate, nhưng mọi quyết định ảnh hưởng khách hàng, kho, giá, tiền hoặc chính sách phải hiện rõ người chịu trách nhiệm. Một ô trống không được bù bằng suy đoán; nó phải trở thành UNKNOWN, SOURCE_REVIEW hoặc STOP.
Việc giao cho AI và việc phải giữ cho chuyên gia
Với Bán hàng đa kênh, nhóm việc phù hợp cho AI gồm 1) đối chiếu SKU gốc với listing candidate trên từng kênh mà không tự publish; 2) chuẩn hóa thuộc tính và tạo bản nháp mô tả theo giới hạn ký tự của Shopee, Lazada, TikTok Shop; 3) gom sự kiện đơn theo idempotency key, phát hiện event lặp và giữ receipt của bước đã hoàn tất; 4) lập packet sai lệch tồn, giao, hoàn và COD để kho hoặc kế toán xử lý; 5) tạo dashboard ngoại lệ có owner, deadline, source_ref và trạng thái review. Đây đều là thao tác chuẩn hóa, đối chiếu, phát hiện thiếu nguồn hoặc tạo bản nháp. Đầu ra nên là bảng hay JSON có field cố định thay vì một đoạn văn khó audit; tối thiểu phải có source_ref, input_version, rule_version, blocker, next_owner và proposed_state.
AI không tự đăng listing, thay giá, áp khuyến mại, reserve tồn, tạo đơn hoặc shipment, duyệt hoàn tiền hay điều chỉnh sổ. Retry chỉ được chạy đúng bước với idempotency key và target proof; thay đổi tài chính luôn cần kế toán hoặc người có thẩm quyền. Policy engine mới là lớp kiểm quyền; mô hình chỉ trả candidate. Khi output chứa action ngoài whitelist, validator trả BLOCKED_ACTION. Khi nguồn mâu thuẫn, Agent không chọn bản “có vẻ hợp lý” mà tạo SOURCE_CONFLICT và đưa hai bằng chứng cho đúng owner.
Dữ liệu cần chuẩn bị và cách xác định nguồn sự thật
Bộ dữ liệu tối thiểu cho Bán hàng đa kênh gồm 1) product_id, SKU gốc, variant_id, barcode và trạng thái vòng đời sản phẩm; 2) channel, listing_id, title_version, price_version, promotion_ref và published_at; 3) inventory_location, available, reserved, damaged, snapshot_at và inventory_owner; 4) order_id, channel_order_id, event_id, line_item, payment_state, cancel_reason và idempotency_key; 5) shipment_id, carrier_ref, COD expected/received, fee version, return_id và reconciliation_receipt. Mỗi bản ghi phải có khóa nghiệp vụ ổn định, occurred_at và received_at để phân biệt sự kiện cũ đến muộn. Trường liên quan tiền, tồn, serial, bảo hành hoặc claim cần effective_at và owner; nếu chỉ có ảnh chụp màn hình không rõ thời điểm thì không đủ làm nguồn hành động.
Product master do catalog owner quản lý; tồn khả dụng do kho hoặc OMS xác nhận; giá và khuyến mại theo bảng chính sách có version; sự kiện đơn lấy từ kênh; biên nhận giao hàng, COD và phí lấy từ đối tác vận chuyển cùng MISA. Source register nên ghi source_id, hệ thống, entity, field được phép cung cấp, owner, version, freshness SLA, retention và approved_use. Ví dụ, catalog được dùng tạo bản nháp mô tả nhưng không thể thay receipt của kho; hội thoại khách cung cấp nhu cầu nhưng không thay chính sách bảo hành.
Workflow có điều kiện dừng, nhánh lỗi và Human-in-the-loop
Bước 1 — Lập inventory công việc và action cấm: Lập inventory công việc và action cấm cho Bán hàng đa kênh; đầu ra có source_ref, trạng thái, owner và tiêu chí chuyển bước. Thiếu nguồn hoặc vượt quyền thì STOP và đưa vào hàng đợi review. Bước 2 — Định danh nguồn sự thật cho SKU, giá, tồn và đơn: Định danh nguồn sự thật cho SKU, giá, tồn và đơn cho Bán hàng đa kênh; đầu ra có source_ref, trạng thái, owner và tiêu chí chuyển bước. Thiếu nguồn hoặc vượt quyền thì STOP và đưa vào hàng đợi review. Bước 3 — Chấm use case theo giá trị, rủi ro và khả năng rollback: Chấm use case theo giá trị, rủi ro và khả năng rollback cho Bán hàng đa kênh; đầu ra có source_ref, trạng thái, owner và tiêu chí chuyển bước. Thiếu nguồn hoặc vượt quyền thì STOP và đưa vào hàng đợi review. Bước 4 — Chạy shadow mode với dữ liệu DEMO: Chạy shadow mode với dữ liệu DEMO cho Bán hàng đa kênh; đầu ra có source_ref, trạng thái, owner và tiêu chí chuyển bước. Thiếu nguồn hoặc vượt quyền thì STOP và đưa vào hàng đợi review. Bước 5 — Duyệt pilot theo catalog, kho, CSKH và kế toán: Duyệt pilot theo catalog, kho, CSKH và kế toán cho Bán hàng đa kênh; đầu ra có source_ref, trạng thái, owner và tiêu chí chuyển bước. Thiếu nguồn hoặc vượt quyền thì STOP và đưa vào hàng đợi review. Bước 6 — Mở rộng từng kênh sau khi kiểm định: Mở rộng từng kênh sau khi kiểm định cho Bán hàng đa kênh; chỉ hoàn tất khi receipt, owner và điều kiện dừng được ghi rõ. Nếu còn conflict, workflow giữ REVIEW thay vì tự chạy tiếp.
Nhánh lỗi không chạy lại toàn luồng. Nếu bước ghi đích timeout, worker tra target proof; đã có receipt thì đóng DUPLICATE_IGNORED, chưa có thì replay đúng step bằng cùng idempotency key. Nếu một bước thành công còn bước sau lỗi, trạng thái là ERROR_PARTIAL, giữ receipt cũ và cấm tạo lại tài nguyên. Nếu nguồn, consent hoặc policy đổi trong lúc chờ duyệt, action candidate hết hiệu lực và phải dựng lại từ version mới.
Năm prompt theo đúng nhiệm vụ và định dạng đầu ra
Năm prompt của bài Bán hàng đa kênh là 1) Kiểm kê điểm nghẽn đa kênh; 2) Kiểm contract dữ liệu sản phẩm; 3) Chấm use case theo rủi ro; 4) Vẽ RACI vận hành kênh; 5) Thiết kế bộ case shadow. Chúng không thay nhau: prompt kiểm nguồn không được dùng để viết nội dung; prompt phân tích ngoại lệ không được biến thành lệnh hoàn tiền hay ghi sổ. Mỗi prompt nhận input đã giảm dữ liệu, có mục tiêu, schema đầu ra, ví dụ DEMO và action cấm. Vì vậy nhân viên có thể copy nhưng vẫn biết trường nào cần thay.
Để quản trị phiên bản, lưu prompt_id, prompt_version, model_config, rule_version và test_suite. Khi thay prompt, chạy lại case nguồn thiếu, event lặp, conflict, action vượt quyền và receipt timeout. Chỉ so chất lượng trên expected field; không chấp nhận câu trả lời “nghe hợp lý” nếu thiếu source_ref hoặc tự điền UNKNOWN. Prompt pack chi tiết nằm ở thẻ copy của bài, còn public content giải thích khi nào nên dùng từng prompt.
Công cụ Việt Nam và kiến trúc tối thiểu
Sapo hoặc Haravan làm lớp quản trị kênh; KiotViet giữ bán hàng và kho; Shopee, Lazada, TikTok Shop là adapter; MISA là nguồn kế toán; Google Sheets phục vụ fixture kiểm thử; GHN, GHTK hoặc Viettel Post trả shipment receipt. Kiến trúc tối thiểu gồm source adapter, normalized store, state machine, prompt service, validator, approval queue, action outbox, connector, receipt store và dead-letter queue. Adapter chỉ đọc dữ liệu được cho phép; prompt service không có credential ghi; connector chỉ nhận action đã được policy engine ký cùng approval_id.
Google Sheets phù hợp để chuẩn bị fixture, source register và expected output ở pilot, nhưng không nên làm event store khi nhiều webhook chạy đồng thời. Dashboard phải tách WAITING_SOURCE, WAITING_REVIEW, ERROR_PARTIAL và STOPPED. Cảnh báo ưu tiên theo hậu quả nghiệp vụ, không theo độ tự tin văn phong của mô hình. Sao lưu cấu hình, prompt và policy version để rollback một thay đổi mà không xóa audit.
Ranh giới AI, người duyệt và quyền thực thi
AI đảm nhiệm normalize, extract, compare, classify theo taxonomy đã duyệt, dựng candidate, soạn draft và kiểm field. Nó không có quyền tự diễn giải chính sách, tự quyết định tiền, thay tồn, xác nhận kỹ thuật hoặc giao tiếp với khách ngoài kênh được duyệt. Ở cổng phê duyệt, Agent chỉ lập bản nháp cho listing, giá, khuyến mại, tồn, đơn, shipment, hoàn tiền hoặc đối soát; người có thẩm quyền mới cho phép hành động tương ứng. Khi cần retry, worker phải chạy lại đúng công đoạn bằng idempotency key và kiểm tra target proof trước; mọi thay đổi liên quan tiền phải chuyển cho kế toán hoặc approver được chỉ định.
Quyền duyệt được chia theo artifact: catalog owner chịu mapping và nội dung, channel operator chịu publish, kho chịu tồn và fulfillment, CSKH chịu trao đổi với khách, còn kế toán chịu COD, phí, hoàn tiền và mọi bút toán. Ma trận quyền nên tách người cung cấp nguồn, người duyệt nội dung, người cho phép action và người kiểm toán. Cùng một người có thể giữ hai vai trong nhóm nhỏ nhưng hệ thống vẫn phải ghi rõ vai trò ở từng transition. Khách hàng là chủ thể cấp hoặc rút consent; nhân viên nội bộ chỉ xác minh, ghi nhận và thực thi phạm vi đó, không “cấp consent” thay khách.
Rủi ro thường gặp và cách phục hồi có kiểm soát
Bốn rủi ro cần diễn tập riêng cho Bán hàng đa kênh là 1) cùng một SKU bị tạo listing trùng vì tên gần giống nhưng không có product_id; 2) tồn snapshot cũ được coi là tồn thật khiến hệ thống đề xuất oversell; 3) webhook retry tạo hai đơn hoặc hai shipment vì thiếu idempotency key; 4) phí sàn, COD và hoàn hàng bị ghi đè trước khi kế toán duyệt biên nhận. Mỗi rủi ro cần một fixture DEMO, expected_state, forbidden_action và người đóng sự cố. Kiểm thử cả callback cũ đến muộn, webhook lặp, nguồn đổi version giữa lúc duyệt, connector timeout sau khi đích đã ghi và reviewer từ chối vì thiếu bằng chứng.
Runbook phục hồi bắt đầu bằng FREEZE_ACTION cho entity bị ảnh hưởng, xác định input/rule/prompt version, tra receipt và phạm vi record. Sau đó rollback configuration hoặc action có khóa đảo ngược, không xóa audit. Với ERROR_PARTIAL, replay đúng step còn thiếu; với nguồn sai, hủy candidate đang chờ và dựng lại; với action vượt quyền, thu hồi credential connector trước khi mở lại worker.
Triển khai pilot cho cá nhân và đội nhóm
Ba ngày đầu, đội Bán hàng đa kênh lập source register, authority matrix và 30 fixture DEMO có cả case bình thường lẫn lỗi. Ngày bốn đến bảy chạy shadow mode: Agent tạo candidate nhưng nhân viên vẫn làm quy trình hiện tại, sau đó so field, source coverage, UNKNOWN và expected_state. Không mở publish, gửi, reserve, refund, ghi sổ hay action tài chính ở giai đoạn này.
Tuần hai có thể mở CREATE_DRAFT và CREATE_REVIEW_TASK cho một nhóm nhỏ. Mỗi ngày, reviewer lấy mẫu các output đã approve lẫn reject, đo lỗi theo field và cập nhật test suite trước khi sửa prompt. Mở rộng chỉ khi source có owner, review queue không quá SLA, error branch đã diễn tập và rollback được xác minh. Một kênh hoặc nhóm sản phẩm mới phải đi lại checklist, không kế thừa quyền mặc định.
Kết quả minh họa, chỉ số và câu hỏi thường gặp
Kết quả minh họa: SKU DEMO-BGN-24 khớp hai listing hợp lệ và một listing cũ cần ARCHIVE_REVIEW; event ORD-DEMO-881 retry hai lần nhưng chỉ tạo một order candidate; snapshot kho quá ngưỡng nên không reserve; COD lệch 32.000 đồng được chuyển FINANCE_REVIEW với ba receipt. Đây là dữ liệu minh họa để kiểm thử workflow, không phải số liệu kinh doanh hay cam kết kết quả thực tế.
Đầu ra tốt phải giúp nhân viên trả lời bốn câu: dữ kiện đến từ đâu, trường nào còn UNKNOWN, ai cần duyệt và điều gì xảy ra nếu connector lỗi. Dashboard nên cho phép mở source và receipt ngay từ card review. Báo cáo tuần tách lỗi dữ liệu, lỗi policy, lỗi prompt, lỗi connector và lỗi thao tác; nhờ vậy đội sửa đúng lớp thay vì chỉnh lời prompt cho mọi vấn đề.
Use case nào nên vào pilot đầu tiên?
Chọn việc có nguồn rõ, action đảo ngược được, reviewer đủ năng lực và fixture lỗi đã có expected output; không chọn chỉ vì làm nhiều lần.
Có cần gom mọi hệ thống vào một nguồn duy nhất không?
Không. Mỗi field có source of truth riêng; lớp chuẩn hóa chỉ nối bằng khóa và version, không thay quyền sở hữu của catalog, kho hay kế toán.
Bản đồ nghề có tự mở quyền publish hoặc reserve không?
Không. Bản đồ chỉ xác định candidate use case, rủi ro và approval; action ghi vẫn bị khóa cho tới khi pilot riêng vượt kiểm định.
Ai duyệt độ sẵn sàng của Bán hàng đa kênh?
Catalog owner duyệt mapping và nội dung; channel operator duyệt publish; kho duyệt tồn và fulfillment; CSKH duyệt trao đổi với khách; kế toán duyệt COD, phí, hoàn tiền và mọi bút toán. Cả bốn nhóm cùng ký phạm vi pilot; một nhóm không thể duyệt thay phần việc của nhóm khác.
Đọc thêm hub ngành Bán lẻ – Thương mại điện tử, danh mục AI Agent TMĐT, cụm nghề Bán hàng đa kênh và các bài cùng cụm. Cần thiết kế pilot theo dữ liệu hiện có, hãy liên hệ NganAds hoặc gọi 0983543063.