Workflow từ dữ liệu sản phẩm đến vận hành gian hàng đa kênh dành cho Bán hàng đa kênh
Tình huống workflow khi order callback đến sai thứ tự
Lúc 8 giờ 05, Shopee gửi ORDER_CREATED cho ORD-DEMO-881; bốn phút sau webhook retry cùng event_id, trong khi Haravan đã tạo pick task nhưng chưa nhận shipment receipt. Đến 9 giờ, snapshot tồn của KiotViet quá ngưỡng freshness và carrier trả COD callback trước trạng thái giao thành công. Workflow phải giữ một order candidate, không tạo shipment lặp, không reserve từ tồn cũ và không chuyển COD sang sổ khi chuỗi receipt chưa đủ.
“workflow AI cho Bán hàng đa kênh” trong bài này là một state machine nghiệp vụ, không phải chuỗi prompt chạy nối nhau. Mỗi entity product, listing, inventory snapshot, order, shipment, return và reconciliation packet có trạng thái riêng. Transition chỉ được mở khi đủ source, version, role và receipt. Nhờ vậy một callback đến muộn không kéo order quay về trạng thái cũ và một lần retry không tạo tài nguyên thứ hai.
Luồng kết thúc ở action đã được người phụ trách duyệt cùng receipt của hệ thống đích. Nó không tự publish listing, đổi giá, reserve tồn, tạo shipment, duyệt refund hay ghi MISA. Nếu không chứng minh được action đã chạy hay chưa, worker dừng ở RECOVERY_REVIEW thay vì thử lại theo phỏng đoán.
Việc giao cho AI trong state machine và quyền giữ lại
AI đọc event envelope, chuẩn hóa SKU/listing candidate, so version giá, đánh dấu snapshot tồn quá hạn, tách order variance và soạn return/COD packet. Nó có thể đề xuất current_state, proposed_state, blocker và next_owner; policy engine kiểm transition; worker mới thực hiện action kỹ thuật. Tách ba lớp này giúp câu trả lời của mô hình không trở thành lệnh ghi ngoài ý muốn.
Catalog owner duyệt mapping; channel operator duyệt publish; kho xác nhận available/reserved và pick; CSKH duyệt trao đổi hoặc hồ sơ return; kế toán duyệt COD, phí, refund và bút toán. Một transition có ảnh hưởng tiền hay tồn phải lưu actor, authority, reason_code và before/after. Khách hàng cấp hoặc rút consent; nhân viên chỉ xác minh và thực thi đúng phạm vi đó.
Action whitelist ban đầu chỉ gồm READ_SOURCE, CREATE_DRAFT và CREATE_REVIEW_TASK. CREATE_ORDER, RESERVE_STOCK, CREATE_SHIPMENT, APPROVE_RETURN, REFUND và LEDGER_WRITE đều bị chặn. Khi validator thấy proposed_action ngoài whitelist, nó trả BLOCKED_ACTION và giữ nguyên state hiện tại.
Dữ liệu sự kiện, khóa idempotency và receipt cần chuẩn bị
Product master cần product_id, SKU, variant_id, barcode và lifecycle_state. Mapping table cần channel, listing_id, mapped_product_id, title_version, price_version và mapping_status. Inventory record tách on_hand, available, reserved, damaged, location, snapshot_at và owner; không dùng một cột “tồn” thiếu thời điểm để điều khiển fulfillment.
Order envelope gồm event_id, channel_order_id, event_type, occurred_at, received_at, payload_version và idempotency_key. Mỗi action target có action_id, target_system, target_key, request_hash, approval_id và receipt_id. Shipment, return, COD và fee cũng dùng khóa riêng để webhook retry không tạo hai shipment, hai hồ sơ hoàn hoặc hai ghi chú đối soát.
Source register quy định catalog là nguồn thuộc tính, policy table là nguồn giá/khuyến mại, kho hoặc OMS là nguồn tồn, marketplace là nguồn event đơn, carrier là nguồn shipment/COD receipt và MISA là nguồn sổ. Thiếu owner hoặc freshness SLA thì trạng thái là SOURCE_REVIEW; không lấy Google Sheets cũ hay nội dung listing làm nguồn thay thế.
Workflow bảy bước từ product master đến đối soát
Bước 1 — Nhận product master: kiểm schema, version và vòng đời SKU; record lỗi vào QUARANTINE. Bước 2 — Mapping listing: AI tạo candidate theo product_id, barcode và variant; catalog owner xác nhận MAP_APPROVED hoặc giữ MAPPING_REVIEW. Bước 3 — Giá và tồn: so price/promotion version cùng snapshot_at; nguồn cũ trả PRICE_REVIEW hoặc INVENTORY_REVIEW, tuyệt đối chưa publish hay reserve.
Bước 4 — Order ingest: event inbox ghi bất biến, tra idempotency key và target proof; callback lặp đóng DUPLICATE_IGNORED. Bước 5 — Fulfillment: sau khi kho duyệt tồn, outbox tạo pick/pack candidate; shipment chỉ được tạo một lần và phải trả receipt. Bước 6 — Return/COD: gom order line, return evidence, carrier status, COD và fee version thành packet, không tự quyết refund hay điều chỉnh.
Bước 7 — Exception queue: SOURCE_CONFLICT về catalog, INVENTORY_STALE về kho, ERROR_PARTIAL về vận hành, RETURN_POLICY_REVIEW về CSKH/policy owner và FINANCE_REVIEW về kế toán. Case chỉ CLOSED khi receipt đã đối soát và close_condition được ghi. Nếu nguồn hoặc approval đổi trong lúc chờ, candidate cũ hết hiệu lực và quay lại cổng thích hợp.
Năm prompt điều phối dành cho từng cổng workflow
Năm prompt hỗ trợ luồng là: chuẩn hóa product master; tạo mapping candidate; kiểm giá/tồn; phân giải order event lặp; lập return/COD packet. Prompt không quyết định state bằng văn bản tự do. Nó trả enum ALLOW_DRAFT, BLOCK, REVIEW, DUPLICATE hoặc ERROR_PARTIAL cùng source_ref và reviewer; state machine chỉ chấp nhận enum được rule version cho phép.
Prompt order phải nhận event_id, idempotency_key, target proof và receipts. Prompt inventory phải nhận snapshot_at với freshness rule. Prompt reconciliation phải tách expected, actual, variance và missing_receipts, đồng thời ghi prohibited_action=NO_LEDGER_WRITE. Khi output thiếu source_ref hoặc đề xuất action vượt quyền, validator dừng trước outbox.
Công cụ và kiến trúc event-driven cho đội vận hành
Sapo, Haravan hoặc KiotViet cung cấp product, order và kho; Shopee, Lazada, TikTok Shop cung cấp listing/event; GHN, GHTK, Viettel Post cung cấp shipment/COD receipt; MISA giữ chứng từ. Google Sheets chỉ dùng fixture và source register ở pilot. Adapter của từng hệ thống chuẩn hóa event nhưng vẫn giữ raw_reference để tra lại.
Kiến trúc gồm immutable event inbox, entity state store, rule engine, prompt service chỉ đọc, approval queue, transactional outbox, connector, receipt store và dead-letter queue. Outbox row chỉ được tạo khi transition có approval_id hợp lệ. Connector gửi idempotency key cho hệ thống đích; callback cập nhật receipt, không trực tiếp viết đè state.
Dashboard hiển thị tuổi snapshot, pending transition, retry budget, target proof và owner. WAITING_SOURCE, WAITING_REVIEW, ERROR_PARTIAL, STOPPED phải tách màu và bộ lọc. Không dùng độ tự tin của mô hình để ưu tiên; dùng hậu quả nghiệp vụ, SLA và số record chịu ảnh hưởng.
Người duyệt tại các cổng product, tồn, giao và tiền
MAPPING_REVIEW cho catalog owner xem SKU, listing, matched fields và conflict. PRICE_REVIEW hiển thị version, effective_at, điều kiện khuyến mại và người ban hành. INVENTORY_REVIEW hiển thị location, available, reserved, snapshot_at và freshness. Reviewer phải mở được nguồn gốc, không chỉ đọc phần tóm tắt do AI viết.
FULFILLMENT_REVIEW thuộc kho; RETURN_POLICY_REVIEW thuộc CSKH và policy owner; FINANCE_REVIEW thuộc kế toán. Giao diện có APPROVE, EDIT, REQUEST_SOURCE, REASSIGN và STOP. Mỗi quyết định lưu actor, time, reason, before/after và action scope. Một approval của catalog không được tái dùng cho giá, tồn hay refund.
Lỗi thường gặp, retry đúng bước và rollback
Lỗi thứ nhất là webhook order lặp sau khi OMS đã tạo record. Worker tra target proof; có receipt thì không chạy lại. Lỗi thứ hai là CRM/OMS ghi thành công nhưng connector shipment timeout: state ERROR_PARTIAL giữ order/pick receipt và chỉ replay shipment step. Lỗi thứ ba là snapshot tồn đổi sau approval: hủy candidate cũ, không cố hoàn tất fulfillment.
Lỗi đối soát không được “sửa” bằng cách lấy con số gần nhất. Packet phải giữ expected, actual, fee version, return status và receipt; kế toán quyết định. Nếu action vượt quyền từng lọt vào outbox, FREEZE_ACTION, thu hồi credential, xác định request_hash bị ảnh hưởng, rollback theo khóa và chạy test hồi quy trước khi mở worker.
Dead-letter case cần error_code, attempts, first/last_seen, owner, retry_after và close_condition. Không có target proof thì không retry mù. Khi replay, giữ cùng idempotency key; khi rollback, không xóa audit. Case tài chính chỉ đóng khi receipt và ledger state được người có thẩm quyền đối chiếu.
Triển khai workflow bằng fixture và shadow mode
Tuần đầu dựng ít nhất 30 case DEMO: mapping đúng/sai, price version cũ, inventory quá hạn, event lặp, callback đến sai thứ tự, shipment timeout, return thiếu evidence và COD lệch. Mỗi case có expected_state, forbidden_action, expected_receipt và owner. Chạy state machine offline trước khi kết nối tài khoản thật.
Shadow mode nhận event thật đã giảm dữ liệu nhưng chỉ tạo transition candidate. Đội so expected với actual, kiểm duplicate prevented, source coverage, ERROR_PARTIAL và reviewer edit rate. Tuần hai chỉ mở CREATE_REVIEW_TASK và một connector không gây thay đổi tài chính. Publish, reserve, shipment, refund và ledger vẫn khóa.
Mở rộng theo một kênh và một nhóm SKU mỗi lần. Điều kiện mở gồm freshness đạt SLA, không có duplicate action, retry/rollback drill thành công và hàng đợi review không quá tải. Nếu số case SOURCE_CONFLICT tăng, quay lại sửa mapping/source thay vì tăng retry hoặc cho AI tự chọn.
Kết quả minh họa, chỉ số vận hành và câu hỏi thường gặp
Kết quả minh họa: ORD-DEMO-881 đi từ INGESTED sang DUPLICATE_IGNORED cho callback thứ hai; pick task cũ được giữ bằng target proof. Snapshot tồn hết hạn đưa luồng về INVENTORY_REVIEW. Khi shipment receipt đến, return packet được dựng lại; COD lệch 32.000 đồng dừng ở FINANCE_REVIEW, chưa ghi MISA. Đây là kịch bản minh họa để kiểm state và recovery, không phải số liệu bán hàng thực tế.
Dashboard nên theo dõi event lặp bị chặn, tuổi snapshot tồn, transition bị block theo lý do, ERROR_PARTIAL, replay success có target proof, packet thiếu receipt và thời gian chờ từng owner. Không suy từ số order xử lý sang cam kết doanh thu. Báo cáo tuần phải kèm mẫu audit để biết luồng nhanh hơn có còn đúng và phục hồi được hay không.
Webhook order retry được xử lý ở bước nào?
Ngay cổng ingest: tra event_id, idempotency key và target proof. Có receipt thì DUPLICATE_IGNORED; chưa có mới replay đúng step trong retry budget.
Điều gì xảy ra khi tồn kho đổi sau approval?
Candidate cũ hết hiệu lực. Workflow quay về INVENTORY_REVIEW với snapshot mới; không dùng approval cũ để reserve hoặc tiếp tục fulfillment.
ERROR_PARTIAL có chạy lại toàn workflow không?
Không. State giữ receipt của phần thành công và chỉ replay công đoạn lỗi; nếu không có target proof thì STOP để owner kiểm tra.
Human-in-the-loop nằm ở đâu trong luồng?
Nằm trước mapping/publish, tồn/fulfillment, trao đổi khách và tài chính. Mỗi cổng có role, evidence, reason_code và transition được phép.
Xem bản đồ nghề Bán hàng đa kênh, bộ prompt theo artifact, landing nghề hoặc liên hệ NganAds qua 0983543063.