Kiến thức / Bán lẻ – Thương mại điện tử / Bán lẻ / TMĐT

Workflow AI cho Đồ gia dụng: 7 bước có kiểm duyệt

Workflow từ dữ liệu sản phẩm đến vận hành gian hàng đa kênh dành cho Đồ gia dụng

Tình huống gian hàng: workflow phải bắt đầu từ product master

Khi khách hỏi qua Zalo hoặc Messenger rồi chốt đơn từ Shopee, Lazada hay TikTok Shop, gian hàng thường vướng ở chỗ rất nhỏ: cùng một kích thước nhưng không nói là phủ bì hay lòng sản phẩm, một bundle không có danh sách component, hoặc một listing giữ claim từ tài liệu cũ. Khi đơn phát sinh, lỗi catalog lan sang tồn, đóng gói, ship, giao lắp và hậu mãi. Vì vậy workflow AI cho Đồ gia dụng không bắt đầu bằng “viết mô tả hay hơn”; nó bắt đầu bằng một product master có khóa, loại thuộc tính, nguồn và version.

Ví dụ DEMO-CHAO-28 có thông số 280 mm trong file nhà cung cấp, 28 cm trong PIM và “lòng chảo 28 cm” trên sàn. Hai số tương đương về đơn vị nhưng không chắc tương đương về định nghĩa. Agent phải tạo SOURCE_CONFLICT thay vì chọn câu nghe hợp lý. Bundle DEMO-BDL-12 còn thiếu một ly ở kho HN, nên order candidate phải BLOCK dù tổng số gói trên dashboard vẫn dương. Những trạng thái này là đầu ra đúng, không phải thất bại của AI.

Dữ liệu và việc giao cho AI trong contract SKU, variant, bundle

Contract sản phẩm cần product_id, SKU, variant_id, barcode, title_version, dimension_type, value, unit, material_source, care_guide_version, approved_claim_id và catalog_owner. Contract bundle cần bundle_id, component_sku, quantity, optional flag, substitution policy và effective_at. Tồn theo kho có available, reserved, damaged, snapshot_at và owner. Order event có event_id, channel_order_id, occurred_at, received_at và idempotency_key.

Giao hàng thêm package dimensions, weight source, fragile flag, address constraint, carrier code, install service code và receipt. Warranty/return thêm order line, serial nếu có, customer statement, evidence refs, policy version, delivery receipt, refund state và decision owner. Schema tách rõ fact hệ thống, lời khách và candidate của AI. Nếu trộn ba lớp này, người duyệt dễ coi một câu mô tả là kết luận đủ điều kiện.

Luồng bảy bước từ dữ liệu sản phẩm đến gian hàng

Bước một nhận product master và kiểm source; bước hai ánh xạ variant cùng bundle; bước ba tạo listing candidate; bước bốn nhận order event và kiểm tồn cấu phần; bước năm lập brief giao fragile/lắp; bước sáu gom warranty/return packet; bước bảy đối soát receipt cùng ngoại lệ. Mỗi bước ghi state_before, proposed_state, source_refs, rule_version, reviewer và receipt cần có. Không bước nào được ngầm coi output văn bản là action.

State machine có các nhánh rõ: STOP_SOURCE cho fact thiếu nguồn; CATALOG_REVIEW cho variant conflict; BLOCK_BUNDLE cho component thiếu; STALE_INVENTORY cho snapshot quá hạn; WAITING_INFO cho địa chỉ hoặc điều kiện lắp chưa đủ; DAMAGE_REVIEW cho kiện hư; POLICY_REVIEW cho bảo hành/đổi trả; FINANCE_REVIEW cho COD, phí và refund. Transition chỉ tiếp tục khi đúng owner ký và input version chưa đổi.

Workflow bảy bước từ product master đến đối soát ngoại lệ cho Đồ gia dụng — Sơ đồ minh họa hiển thị đầy đủ bước, điều kiện dừng, nhánh lỗi và điểm người phụ trách duyệt; không phải dữ liệu vận hành thực tế.

Rủi ro, nhánh lỗi và rollback không tạo tác động kép

Kênh có thể gửi cùng order event nhiều lần. Worker dùng idempotency key theo action và entity; trước retry phải tra target proof. Nếu pick task đã có receipt, event lặp đóng DUPLICATE_IGNORED. Nếu listing draft đã tạo nhưng callback bị mất, không tạo draft thứ hai; hệ thống tìm theo idempotency key. Nếu bước order hoàn tất nhưng bước delivery brief lỗi, trạng thái ERROR_PARTIAL giữ receipt order và chỉ replay delivery step.

Rollback khác nhau theo action. Candidate listing có thể hủy; review task có thể đóng; cấu hình prompt có thể quay về version trước. Không được “rollback” bằng xóa audit hoặc sửa trực tiếp số tài chính. Khi claim sai đã được publish ngoài pilot, FREEZE connector, xác định listing bị ảnh hưởng, chuyển channel operator xử lý và ghi correction receipt. Khi oversell bundle, kho/CSKH xử lý case thật; AI chỉ gom phạm vi và bằng chứng.

Năm prompt gắn trực tiếp với năm cổng kiểm soát

Prompt chuẩn hóa product row chạy trước mapping; prompt bundle chạy trước khi order tiến sang fulfillment; prompt listing chạy sau khi facts đã VALID; prompt delivery chạy khi có package và địa chỉ; prompt return chạy khi có yêu cầu hậu mãi. Việc đặt prompt đúng cổng tránh dùng một prompt “đa năng” để vừa bịa thuộc tính, vừa viết quảng cáo, vừa quyết định đổi trả. Mỗi prompt trả schema khác và reviewer khác.

Prompt service chỉ nhận dữ liệu tối thiểu. Trường tài chính hoặc thông tin khách không cần cho catalog bị loại trước khi gửi. Validator kiểm source_ref, forbidden claim, action verb và trạng thái. Output có “hoàn tiền”, “bảo hành chắc chắn”, “lắp miễn phí” hoặc “an toàn tuyệt đối” mà không có policy/action approval phải BLOCKED_ACTION. Người duyệt xem diff chứ không chỉ xem đoạn văn cuối.

Kết nối KiotViet, Sapo, sàn và hệ thống chứng từ

KiotViet, Sapo hoặc Haravan làm nguồn catalog/OMS tùy kiến trúc hiện có; Shopee, Lazada và TikTok Shop là channel adapter. Google Drive giữ product sheet, care guide và policy có version; Google Sheets giữ fixture và expected output; MISA là nguồn chứng từ, không phải nơi AI tự ghi điều chỉnh. Carrier adapter lấy shipment event và proof, còn approval queue tách catalog, kho, vận hành, CSKH và finance.

Adapter cần schema version và dead-letter queue. Một field mới của sàn không được tự map vào thuộc tính gần giống; nó vào SCHEMA_REVIEW. Đồng bộ tồn phải lưu snapshot_at, không chỉ một con số. Dashboard hiển thị tuổi dữ liệu, entity, state, blocker, next_owner và SLA. Cảnh báo theo hậu quả—claim sai, oversell, tiền—thay vì theo “độ tự tin” của lời mô hình.

Bảng trạng thái listing, bundle, giao kiện dễ vỡ, bảo hành và đổi trả Đồ gia dụng — Bảng triển khai minh họa dùng mã DEMO, nguồn có version và trạng thái review để đội vận hành kiểm tra trước khi áp dụng.

Human-in-the-loop theo từng field và transition

Catalog owner duyệt kích thước, vật liệu, care guide, variant mapping và claim. Kho duyệt tồn cấu phần, đóng gói và pick discrepancy. Vận hành giao lắp duyệt service scope, access constraint và carrier escalation. CSKH duyệt nội dung liên hệ và tách lời khách khỏi kết luận. Policy owner quyết định bảo hành/đổi trả; finance duyệt COD, phí, refund và bút toán. Reviewer chỉ thấy task thuộc quyền mình.

Approval lưu approver_id, role, scope, input_hash, approved_at và expiry. Nếu price, inventory, policy hay product version đổi sau khi duyệt, approval hết hiệu lực. Với case rủi ro cao, hệ thống có thể yêu cầu hai vai: policy owner xác nhận điều kiện và finance xác nhận khoản tiền. Agent không được tự diễn giải một approval cũ cho entity khác.

Kiểm thử trước khi mở quyền ghi

Bộ fixture phải có đơn vị đổi đúng nhưng dimension_type sai; material_source thiếu; hai variant trùng barcode; bundle thiếu component; snapshot tồn cũ; event order lặp; connector timeout sau khi đích đã ghi; kiện fragile thiếu ảnh; yêu cầu lắp ngoài vùng; và return thiếu delivery receipt. Mỗi case ghi expected_state, forbidden_action, reviewer và receipt mong đợi.

Đo field accuracy sau review, source coverage, conflict detection, duplicate prevention, review time, queue age, correction rate và rollback time. Không dùng số doanh thu minh họa để chứng minh hiệu quả. Một pilot đạt yêu cầu khi lỗi nghiêm trọng bị chặn, reviewer hiểu vì sao task xuất hiện và đội có thể phục hồi. Nếu Agent viết hay hơn nhưng tăng SOURCE_CONFLICT bị bỏ qua, pilot chưa đạt.

Runbook triển khai theo nhóm sản phẩm

Tuần đầu chạy một nhóm ít variant và không có lắp đặt phức tạp. Shadow mode giữ quy trình hiện tại, Agent chỉ normalize và tạo review task. Sau khi catalog gate ổn định mới nối bundle; sau bundle mới nối order event; giao lắp và hậu mãi mở sau cùng vì hậu quả với khách cao hơn. Mỗi lần mở một transition, giữ retry budget nhỏ và feature flag riêng.

Khi lỗi lặp vượt ngưỡng nội bộ, freeze đúng transition, không tắt toàn hệ thống nếu các phần khác an toàn. Tra source, rule, prompt và connector version; xác định phạm vi; rollback cấu hình; chạy lại fixture; rồi mới replay case chưa có receipt. Review sau sự cố phải tạo test mới. Không sửa prompt để che vấn đề data contract hoặc authority.

Kết quả minh họa và checklist nghiệm thu trước triển khai

Kết quả minh họa: DEMO-CHAO-28 được normalize 280 mm thành 28 cm nhưng vẫn SOURCE_CONFLICT vì listing gắn sai dimension_type. DEMO-BDL-12 thiếu LY-02 nên BLOCK_BUNDLE. Event ORD-DGD-DEMO-71 đến hai lần nhưng receipt pick task đã tồn tại, do đó lần hai đóng DUPLICATE_IGNORED. Kệ kính DEMO-KG-04 chờ thông tin thang máy và OPS_REVIEW, chưa có lời hứa lắp.

Sau giao, khách báo kiện móp. Workflow lưu nguyên văn phản ánh, ảnh timestamp và delivery receipt; thiếu biên bản carrier nên DAMAGE_REVIEW. CSKH soạn tin xác nhận đã tiếp nhận, không xác nhận đủ điều kiện đổi. Policy owner duyệt hướng xử lý, finance chỉ tham gia nếu có khoản hoàn. Toàn bộ đường đi có source, owner, state và receipt để đối soát.

Kiểm đủ mười điểm: product key ổn định; dimension_type rõ; material/claim có nguồn; bundle có component mapping; snapshot tồn có freshness; order action idempotent; listing không tự publish; giao lắp có scope; hậu mãi không tự hứa; và tài chính có review riêng. Thêm kiểm tra mobile dashboard, log không lộ dữ liệu không cần thiết, queue có SLA và rollback không xóa audit.

Chỉ nhân rộng khi ba nhóm cùng đồng ý: người sở hữu dữ liệu xác nhận nguồn, người vận hành xác nhận quy trình và người kiểm soát xác nhận quyền. Đọc bài bản đồ nghề để chọn use case và bài prompt pack để copy từng tác vụ. Workflow này là khung kiểm soát; đội phải thay schema, policy, SLA và role bằng dữ liệu thật đã được phê duyệt.

Vì sao phải kiểm dimension_type?

Hai số cùng 28 cm vẫn có thể là phủ bì và lòng sản phẩm; đổi đơn vị đúng chưa đủ để tư vấn đúng.

Retry order thế nào để không tạo tác động kép?

Tra idempotency key cùng target proof; có receipt thì đóng DUPLICATE_IGNORED, chưa có mới replay đúng bước.

AI có xác nhận phạm vi lắp đặt không?

Không. Agent lập brief; vận hành xác nhận theo policy, địa chỉ và năng lực thực tế.

Khi khách yêu cầu hoàn thì dừng ở đâu?

Case chuyển POLICY_REVIEW hoặc FINANCE_REVIEW. Cần rà workflow theo hệ thống hiện có, hãy liên hệ NganAds.

Workflow

Bước 1: Nhận product master có version — Validator kiểm product_id, SKU, variant, loại kích thước, đơn vị, material_source và care guide; thiếu nguồn thì STOP_SOURCE.
Bước 2: Ánh xạ variant và bundle — Tạo mapping candidate theo component SKU; conflict hoặc substitution ngoài policy chuyển CATALOG_REVIEW, không tự gộp.
Bước 3: Duyệt listing candidate — Claim register chặn an toàn, độ bền, vật liệu và tương thích chưa có nguồn; catalog owner duyệt DRAFT trước publish.
Bước 4: Nhận order event an toàn — Order dùng idempotency key; kiểm tồn từng component có freshness và target proof trước khi tạo pick candidate.
Bước 5: Chuẩn bị giao fragile hoặc lắp — Lập packing/access brief; thiếu điều kiện địa chỉ hoặc install scope thì WAITING_INFO và vận hành duyệt.
Bước 6: Gom warranty/return packet — Tách lời khách, evidence và policy version; CSKH/policy owner quyết định, Agent không hứa đổi, bảo hành hay hoàn tiền.
Bước 7: Đối soát và phục hồi ngoại lệ — Tra receipt, giữ bước đã thành công, replay đúng step trong retry budget; khoản tiền chuyển FINANCE_REVIEW.

Prompt mẫu

Chuẩn hóa product row trước mapping

MỤC TIÊU: Đưa một SKU và các variant về schema thống nhất trước khi tạo listing candidate.
[ĐẦU VÀO]: [PRODUCT_ROW], [DIMENSION_DEFINITIONS], [MATERIAL_SOURCE], [VARIANTS], [UNIT_RULES], [OWNER].
RÀNG BUỘC: Không tự đổi loại kích thước; không suy vật liệu hay tương thích; conflict tạo SOURCE_REVIEW; chỉ catalog owner xác nhận.
ĐỊNH DẠNG ĐẦU RA: VALID/CONFLICT | normalized fields | source_ref | unknown | conflicting rows | reviewer.
VÍ DỤ ĐIỀN SẴN: DEMO-CHAO-28: 280 mm đổi thành 28 cm; listing ghi lòng 28 cm nhưng nguồn nói phủ bì → CONFLICT.

Kiểm component của bundle theo snapshot

MỤC TIÊU: Chặn đơn bundle khi thiếu cấu phần hoặc dữ liệu tồn đã cũ.
[ĐẦU VÀO]: [BUNDLE_ID], [COMPONENT_RULES], [WAREHOUSE_SNAPSHOTS], [FRESHNESS_SLA], [SUBSTITUTION_POLICY].
RÀNG BUỘC: Không cộng tồn khác kho tùy ý, không reserve, không tự thay quà; snapshot quá hạn phải hỏi kho.
ĐỊNH DẠNG ĐẦU RA: READY/BLOCK/STALE | component table | missing | captured_at | warehouse owner | safe next step.
VÍ DỤ ĐIỀN SẴN: DEMO-BDL-12 cần LY-02 x2; kho HN còn 1, snapshot mới → BLOCK, tạo WAREHOUSE_REVIEW.

Soát listing theo claim register

MỤC TIÊU: Tạo bản listing được phép từ product master đã duyệt.
[ĐẦU VÀO]: [NORMALIZED_PRODUCT], [APPROVED_CLAIMS], [CARE_GUIDE], [CHANNEL_LIMITS], [FORBIDDEN_TERMS].
RÀNG BUỘC: Chỉ dùng fact có source; không viết claim an toàn, độ bền hoặc tương thích nếu chưa duyệt; output chỉ là DRAFT.
ĐỊNH DẠNG ĐẦU RA: title_draft | bullets | spec table | removed_claims | unknown | source_ref | catalog review.
VÍ DỤ ĐIỀN SẴN: Loại “chống xước tuyệt đối”; giữ kích thước 28 cm và care guide từ DOC-v3; DRAFT_ONLY.

Tạo brief giao kiện fragile và lắp

MỤC TIÊU: Chuẩn bị dữ kiện đóng gói, tiếp cận và dịch vụ để vận hành duyệt.
[ĐẦU VÀO]: [PACKAGE_PROFILE], [FRAGILE_FLAG], [ORDER_ADDRESS_CONTEXT], [ACCESS_ANSWERS], [INSTALL_POLICY], [CARRIER].
RÀNG BUỘC: Không hứa ngày giao, không kết luận có lắp; thiếu tải trọng, thang máy hoặc vùng phục vụ phải WAITING_INFO.
ĐỊNH DẠNG ĐẦU RA: packing checklist | access gaps | install scope candidate | carrier question | approver | receipt needed.
VÍ DỤ ĐIỀN SẴN: Kệ kính DEMO-KG-04 lên tầng năm, chưa rõ thang máy → WAITING_INFO rồi OPS_REVIEW.

Lập packet ngoại lệ bảo hành/đổi trả

MỤC TIÊU: Gom facts, policy và chứng từ để đúng người quyết định hậu mãi.
[ĐẦU VÀO]: [ORDER_LINE], [CUSTOMER_REPORT], [MEDIA_REFS], [DELIVERY_RECEIPT], [POLICY_VERSION], [PAYMENT_STATE].
RÀNG BUỘC: Không chẩn đoán lỗi, không xác nhận bảo hành, không duyệt đổi hoặc hoàn; lời khách phải phân biệt với fact hệ thống.
ĐỊNH DẠNG ĐẦU RA: case summary | verified facts | customer statement | missing evidence | policy_ref | reviewer | prohibited action.
VÍ DỤ ĐIỀN SẴN: Kiện DEMO-RET-44 móp; ảnh có timestamp, thiếu biên bản carrier → DAMAGE_REVIEW; chưa hứa hoàn.

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

Vì sao workflow phải kiểm dimension_type chứ không chỉ đổi đơn vị?

Hai số có thể cùng 28 cm nhưng một số là phủ bì, số kia là lòng sản phẩm. Đổi đơn vị đúng vẫn có thể tư vấn sai nếu định nghĩa field khác nhau.

Retry order event thế nào để không tạo tác động kép?

Dùng idempotency key và tra target proof; có receipt thì đóng DUPLICATE_IGNORED, chưa có mới replay đúng bước trong retry budget.

AI có được xác nhận phạm vi lắp đặt không?

Không. AI lập brief và câu hỏi còn thiếu; vận hành giao lắp xác nhận theo policy, địa chỉ và năng lực thực tế.

Khi khách yêu cầu đổi hoặc hoàn thì workflow dừng ở đâu?

Agent gom packet và chuyển POLICY_REVIEW hoặc FINANCE_REVIEW; không kết luận điều kiện, không hứa đổi hay hoàn tiền.

Bài liên quan

Muốn cài AI Agent cá nhân 499K (support 7 ngày)? Inbox / Zalo 0983543063.