Tóm tắt nhanh
- Mỗi đơn cần một deadline riêng từ policy có phiên bản; không dùng một số giờ chung cho tất cả sàn.
- Trừ standard minutes còn lại và buffer khỏi deadline để tạo latest safe start cho từng công đoạn.
- OMS quản lý clock, reservation, routing và exception; WMS chứng minh pick–check–pack–staging–handover bằng scan.
- Điều hành theo at-risk backlog, slack time và capacity coverage thay vì chờ tỷ lệ LDR/LSR xấu.
- Giữ source time, event time, receive time, policy version và evidence để RCA hoặc appeal.
Thông tin thực thể liên quan
| Thực thể | Vai trò trong kiểm soát SLA |
|---|---|
| Shopee, Lazada, TikTok Shop | Nguồn order, deadline, holiday/cut-off rule, trạng thái tính KPI, exclusion và enforcement. |
| OMS | Hợp nhất shop/order line, policy clock, ATP reservation, routing, priority, exception và platform acknowledgement. |
| WMS | Thực thi bin, PDA, barcode, picking, checking, packing, staging, manifest và handover evidence. |
| Kho nội bộ hoặc 3PL | Cung cấp capacity, task status, parcel evidence, pickup slot, ACK/reject và escalation. |
| Ecommerce ops, kho, vận chuyển, IT | Sở hữu policy, backlog, công suất, carrier, tích hợp, RCA và acceptance gate. |
1. Khoảng trống nội dung: thấy điểm shop nhưng chưa điều hành được từng đơn
Nội dung công khai của các công cụ đa sàn thường trả lời tốt câu hỏi thao tác: đơn nào chờ xác nhận, chờ in, đã hủy; cách in hàng loạt; cách đồng bộ; cách đẩy vận chuyển. Tài liệu sàn trả lời câu hỏi chính sách: chỉ số nào được tính, cửa sổ bao nhiêu ngày, event nào được xem là giao, ngưỡng nào dẫn tới cảnh báo hoặc giới hạn. Hai lớp này đều cần, nhưng ở giữa còn thiếu một lớp quyết định vận hành: với backlog hiện tại, đơn nào có nguy cơ; cần bắt đầu trước mấy giờ; công đoạn nào đang thiếu phút; ai có quyền đổi wave, chuyển kho hoặc giảm nhận đơn; và bằng chứng nào đủ để chứng minh lỗi thuộc kho, carrier, API hay policy.
| Nguồn đã kiểm tra | Nội dung hữu ích | Khoảng trống còn lại |
|---|---|---|
| BigSeller | Công khai các luồng gom đơn, wave, barcode, xử lý đơn hủy và nội dung nhấn mạnh LDR/LSR. | Thiếu một control model nối policy version, latest safe start, năng lực theo phút, evidence ladder, risk budget và RCA đa sàn. |
| Ginee | Tổng quan hiển thị chờ xác nhận, chờ giao, chờ in, hủy; tài liệu cho phép hủy và theo dõi kết quả. | Queue trạng thái giúp nhìn việc nhưng chưa trả lời đơn nào sẽ trễ trước, vì sao trễ, ai xử lý, cần bao nhiêu năng lực và bằng chứng nào đủ. |
| Sapo và phần mềm lân cận | Nhấn mạnh tạo đơn, đẩy vận chuyển, lựa chọn hãng và theo dõi giao hàng. | Kết nối vận chuyển chưa đồng nghĩa với kiểm soát deadline từ order ingest qua kho tới carrier acceptance và platform acknowledgement. |
| TikTok Shop Seller University | Công bố công thức LDR theo 7 ngày, mục tiêu dưới 4%, cut-off theo giờ đặt và ví dụ giới hạn sản lượng khi LDR cao. | Buyer vẫn phải chuyển chính sách thành clock từng đơn, cảnh báo sớm, capacity-to-deadline, holiday calendar, scan evidence và recovery playbook. |
| Lazada Open Platform | Nêu hủy do lỗi seller có thể ảnh hưởng rating/order volume; hủy theo order item và trạng thái cho phép. | Cần kiểm soát line/parcel, không chỉ order header; đồng thời giữ policy/version và lý do để ngăn lỗi tồn hoặc sai giá tái diễn. |
| SERP và thảo luận seller công khai | Lặp lại câu hỏi về đơn đứng ở Ready to Ship, hết tồn, carrier không lấy, trễ sau campaign và giới hạn đơn. | Dùng để xác nhận pain point, không dùng tỷ lệ cộng đồng hoặc lời kể đơn lẻ làm benchmark ngành. |
Ví dụ, tài liệu TikTok Shop Việt Nam công khai ngày 20/08/2026 mô tả Late Dispatch Rate trên cửa sổ 7 ngày, mục tiêu dưới 4% và công thức loại đơn hủy trước deadline khỏi mẫu số. Đây là dữ liệu chính sách hữu ích, nhưng không nên biến thành hằng số cho mọi thời kỳ hoặc mọi sàn. Nguồn TikTok Shop Seller University phải được lưu cùng ngày kiểm tra, effective date và người duyệt. Lazada Open Platform lại cho thấy hủy có thể áp dụng ở order item, ảnh hưởng rating và giới hạn đơn; vì vậy data model không thể chỉ có một trạng thái order header. Seller discussion xác nhận nỗi đau về Ready to Ship bị đứng, carrier không lấy và kho thiếu hàng, nhưng không được dùng làm chuẩn tỷ lệ ngành.
2. Kết luận đầu tiên: quản lý SLA bằng đồng hồ từng đơn và “latest safe start”
Deadline sàn chỉ là điểm cuối. Để cứu đơn, doanh nghiệp phải đi ngược từ điểm cuối qua buffer đồng bộ, carrier pickup, staging, packing, checking, picking và thời gian chờ wave. Nếu đơn phải đạt event đích lúc 23:59, carrier pickup cuối lúc 20:00 và kho cần tổng cộng 55 phút hữu dụng, hệ thống không thể đợi 19:50 mới báo đỏ. “Latest safe start” phải sớm hơn pickup đủ 55 phút cộng buffer biến động, chẳng hạn 25 phút. Khi thời gian hiện tại đi qua mốc 18:40 trong ví dụ này mà đơn chưa được release, đơn đã at-risk dù dashboard sàn vẫn chưa ghi trễ.
Slack âm nghĩa là với phương án hiện tại đơn không còn đủ thời gian dự kiến. Hành động đúng không nhất thiết là “đẩy lên đầu”: nếu SKU thực tế hết hoặc carrier đã đóng chuyến, ưu tiên một đơn không thể cứu có thể làm trễ nhiều đơn khác. Queue cần cả slack, feasibility và action code. Đơn không thể cứu phải chuyển sớm sang re-route, substitute, customer/platform action hoặc quyết định hủy có kiểm soát; không được nằm im trong wave.
3. Tạo policy registry thay vì hard-code quy định sàn
Policy registry tối thiểu có platform, market, shop type, fulfillment method, order type, payment state, event bắt đầu, event kết thúc, cut-off, working-day calendar, exclusion, evaluation window, target, enforcement, source URL, effective-from, effective-to, reviewer và timestamp kiểm tra. Một rule không có nguồn hoặc ngày hiệu lực chỉ là giả định. Khi sàn đổi chính sách, hệ thống tạo version mới; không sửa đè lịch sử khiến cùng một đơn hôm nay được tính khác hôm qua.
Mỗi đơn lưu policy_version_id ngay lúc đủ điều kiện xử lý. Nếu rule đổi giữa tuần, đơn trước effective date giữ version cũ, đơn sau dùng version mới. Dashboard có thể hiển thị “operational target” nội bộ chặt hơn platform target để tạo vùng an toàn, nhưng phải tách hai trường. Ví dụ đội vận hành đặt guardrail nội bộ 2% không có nghĩa sàn chính thức yêu cầu 2%. Cách tách này tránh biến mục tiêu quản trị thành thông tin sai về chính sách.
Calendar cũng phải có version. “Ngày làm việc” của sàn không nhất thiết trùng lịch kho, carrier hoặc văn phòng. Cần mô hình ít nhất ba lịch: platform policy calendar, warehouse operating calendar và carrier pickup calendar. Một ngày sàn tính là làm việc nhưng carrier không có chuyến ở vùng đó là capacity exception cần được chặn từ lúc nhận đơn, không phải lý do chữa cháy cuối ngày.
4. Event model: trạng thái không đủ, phải có thời gian và bằng chứng
| Mốc | Định nghĩa vận hành | Bằng chứng tối thiểu |
|---|---|---|
| Order received | Sàn/API ghi nhận đơn đủ điều kiện xử lý | OMS event id, source timestamp, received timestamp |
| Order accepted/reserved | OMS giữ ATP và chốt nguồn xuất | reservation id, SKU, warehouse, expiry, reason |
| Released to warehouse | Đơn đủ dữ liệu và được phát task | release timestamp, wave, priority, rule version |
| Picked | PDA xác nhận đúng bin–barcode–quantity–tote | user, device, location, SKU, scan time, exception |
| Checked | Đối chiếu order line và hàng thật | checker, barcode/serial/lot, pass/fail, photo nếu cần |
| Packed | Đủ hàng, vật tư, nhãn và kiện | parcel id, label version, weight/dimension, packing scan |
| Staged/manifested | Kiện ở đúng làn/chuyến/hãng | staging bin, manifest id, carrier, cut-off |
| Carrier accepted | Hãng/3PL xác nhận nhận kiện | pickup scan, handover count, ACK, signature/image |
| Platform acknowledged | Sàn phản ánh trạng thái được tính theo policy | channel event, status, event time, sync lag |
Mỗi event cần ba thời gian: source_event_time do nguồn tạo, received_time khi hệ thống nhận và processed_time khi rule chạy. Nếu chỉ giữ processed_time, lỗi API 30 phút sẽ bị hiểu thành kho xử lý chậm. Event phải có idempotency key; webhook gửi lại không được tạo hai lần Shipped, hai bút toán tồn hoặc hai task. Trạng thái order header chỉ là view được tổng hợp từ order line, parcel và event, không phải nguồn sự thật duy nhất.
Evidence ladder nên xếp từ yếu tới mạnh: nút bấm hoặc nhãn đã in; WMS task complete; scan barcode/serial; parcel sealed; staging scan; manifest count; carrier pickup scan/ACK; platform acknowledgement. Tùy tranh chấp, một bậc có thể đủ cho quản trị nội bộ nhưng chưa đủ cho appeal. Retention cần theo chính sách dữ liệu và thời hạn claim, không giữ vô hạn mọi ảnh nếu không cần.
5. Từ KPI trễ sang risk budget có thể hành động
Một tỷ lệ rolling có đặc tính “ngân sách lỗi”. Nếu cửa sổ hiện có N đơn đủ điều kiện, mục tiêu nội bộ tối đa r, và đã có L đơn lỗi, số lỗi còn có thể chịu về mặt số học là floor(r × N) − L. Tuy nhiên mẫu số còn thay đổi khi đơn mới vào hoặc bị loại theo policy, nên risk budget chỉ là dự báo; không được dùng để cố tình cho phép đơn trễ. Giá trị của nó là giúp đội thấy khoảng cách tới guardrail và kích hoạt action sớm.
Ví dụ minh họa: cửa sổ dự báo 1.000 đơn đủ điều kiện, guardrail nội bộ 2%, tức 20 lỗi. Đã có 7 lỗi được xác nhận và 18 đơn at-risk. Nếu xác suất trễ ước tính của nhóm at-risk lần lượt tạo expected late bằng 11, risk budget kỳ vọng còn 2. Điều này không nói rằng có thể bỏ hai đơn; nó nói team gần hết vùng đệm và phải bật playbook. Nếu dùng target 4% từ một chính sách cụ thể, phải ghi rõ platform, version và date; không áp sang Shopee/Lazada.
| Chỉ số | Cách tính | Cách phân tầng |
|---|---|---|
| On-time dispatch rate | Đơn đạt dispatch event trước deadline / đơn đủ điều kiện | Tách sàn, shop, loại fulfillment, kho, carrier và ngày policy |
| At-risk backlog | Đơn chưa đạt mốc / tổng backlog, phân theo buffer còn lại | Nhóm <30, 30–60, 60–120, >120 phút thay vì một tổng đỏ |
| Deadline attainment P50/P90/P95 | Phân vị thời gian từ order eligible tới event đích | Đuôi P95 cho thấy nghẽn mà trung bình che mất |
| First-pass yield | Đơn qua pick–check–pack không rework / đơn xử lý | Tách lỗi SKU, quantity, barcode, label, vật tư và dữ liệu |
| Carrier acceptance gap | Packed nhưng chưa được carrier ACK | Phân theo manifest, pickup window, lane, 3PL và tuổi backlog |
| Cancellation controllability | Hủy seller-controlled / tổng hủy có phân loại | Không trộn buyer cancel, fraud/risk hoặc platform cancel nếu policy loại trừ |
| Capacity coverage | Phút năng lực hữu dụng còn lại / phút công việc cần trước deadline | <1 là thiếu năng lực; phải hành động trước khi đồng hồ hết |
| Evidence completeness | Đơn có đủ evidence bắt buộc / đơn cần bằng chứng | Dùng cho RCA, claim, appeal và nghiệm thu hệ thống |
6. Capacity-to-deadline: đổi backlog thành phút công việc
Đếm 300 đơn chờ không cho biết kho có kịp hay không. Ba trăm đơn single-line dễ lấy khác hoàn toàn 300 đơn nhiều line, combo, bulky, serial, FEFO hoặc quà campaign. Hãy gán standard minutes theo order profile và công đoạn, rồi tính earned workload. Standard minutes phải đến từ time study có phương pháp chuẩn, đủ mẫu, tách thời gian ngoại lệ và dùng nhịp bền vững; không lấy ca nhanh nhất làm chuẩn.
Giả sử trước 18:00 có 1.000 đơn: 650 single-line × 1,8 phút; 250 multi-line × 3,6 phút; 70 combo × 5 phút; 30 bulky × 8 phút. Direct workload là 2.660 phút. Cộng 12% indirect và 6% expected rework thành khoảng 3.139 phút. Mười hai người còn 4,5 giờ tạo 3.240 phút danh nghĩa; sau attendance 95% và sustainable utilization 85% chỉ còn khoảng 2.616 phút. Coverage 0,83 cho thấy thiếu khoảng 523 phút. Dashboard “12 người xử lý 1.000 đơn” nghe có vẻ đủ, nhưng mô hình theo phút chỉ ra sẽ trễ nếu không giảm tải hoặc thay đổi phương án.
Cần tính riêng constraint theo picking, checking, packing, replenishment và carrier staging. Tổng người đủ không cứu được bàn checking chỉ có hai máy quét. Bottleneck capacity là min của các công đoạn nối tiếp sau khi quy đổi theo flow. Khi bottleneck chuyển trong ngày, điều người phải dựa vào kỹ năng và thiết bị; đưa thêm người chưa được đào tạo vào packing có thể làm rework tăng nhanh hơn năng lực.
7. Ưu tiên đơn: earliest deadline chưa đủ
| Quy tắc | Khi phù hợp | Rủi ro cần chặn |
|---|---|---|
| FIFO | Đơn tương đồng, deadline gần như nhau | Bỏ sót loại đơn có cut-off sớm hoặc cần nhiều phút hơn |
| Earliest deadline first | Nhiều deadline khác nhau và dữ liệu policy tin cậy | Có thể kéo đơn không thể cứu lên đầu, làm trễ đơn có thể hoàn tất |
| Least slack time | Có standard minutes còn lại theo trạng thái | Cần time study và cập nhật queue chính xác |
| Risk-weighted slack | Vận hành đa kênh, nhiều SKU/kho/carrier | Phải giải thích trọng số, chống ưu tiên tùy tiện hoặc thiên lệch |
| Wave optimization | Nhiều line có thể gom đường đi hoặc SKU | Không để hiệu suất wave làm đơn deadline gần bị chờ |
Công thức thực dụng có thể bắt đầu đơn giản: priority score tăng khi slack giảm, giá trị rủi ro tăng, carrier cut-off gần và đơn có thể hoàn tất; giảm khi đang thiếu hàng hoặc chờ dữ liệu bắt buộc. Không nên dùng mô hình bí ẩn không giải thích được. Mọi trọng số cần owner, version, test và giới hạn công bằng: không để đơn giá trị thấp bị trì hoãn có hệ thống, không vi phạm cam kết khách hàng và không dùng thuộc tính nhạy cảm không liên quan.
Hot wave chỉ dành cho đơn sắp hết slack và có thể cứu. Các đơn còn slack lớn được gom wave theo zone/SKU để giữ productivity. Nếu hot wave chiếm quá nhiều, đó là tín hiệu upstream planning hoặc capacity sai, không phải thành tích. KPI nên theo dõi tỷ lệ hot wave và nguyên nhân; mục tiêu dài hạn là giảm nhu cầu chữa cháy.
8. Quy trình end-to-end từ nhận đơn tới platform acknowledgement
- Ingest và chuẩn hóa: OMS nhận order/order line, ghi source time, xác thực shop, payment, service, address và policy version.
- Giữ tồn: map listing SKU sang master SKU, tính ATP, tạo reservation idempotent theo kho; lỗi vào exception, không âm thầm nhận.
- Tính clock: lấy deadline, carrier cut-off, calendar và standard minutes để tạo latest safe start cùng slack hiện tại.
- Route và release: chọn kho đủ ATP, capability, capacity và cut-off; phát WMS task với priority/version.
- Pick: PDA bắt scan bin–barcode–quantity–tote; short pick tạo quyết định re-route/substitute/cancel.
- Check và pack: kiểm line, serial/lot nếu cần, vật tư, label, cân nặng; reprint phải vô hiệu nhãn cũ.
- Stage và manifest: scan đúng lane/carrier/pickup; control total giữa packed parcel và manifest.
- Handover: đối chiếu số kiện, pickup time, carrier ACK/reject; thiếu ACK mở escalation trước cut-off.
- Acknowledge và reconcile: đối chiếu platform status với WMS/carrier event; retry/DLQ không được làm mất hoặc nhân đôi event.
- Close và learn: phân loại late/cancel theo controllability, owner và root cause; cập nhật policy/capacity/process khi có bằng chứng.
9. Exception queue phải chỉ rõ owner và next action
| Nhóm nguyên nhân | Tín hiệu | Hành động | Owner chính |
|---|---|---|---|
| Sai hoặc thiếu tồn | Reservation fail, short pick, bin empty, quarantine | SKU mapping, cycle count, ATP buffer, hold listing, replenishment | Inventory owner + warehouse |
| Đơn vào hệ thống muộn | Source time sớm nhưng OMS receive time trễ | API SLO, retry, DLQ, reconciliation, degraded mode | Integration owner |
| Dữ liệu đơn không hợp lệ | Thiếu address, service, label, payment state | Validation queue, reason code, customer/platform action | Ecommerce ops |
| Kho thiếu công suất | Capacity coverage <1, queue age tăng, pick rate giảm | Re-wave, điều người, overtime đã duyệt, cap đơn, chuyển kho | Warehouse lead |
| SKU khó hoặc layout kém | Travel time cao, replenishment chờ, scan exception | Slotting, forward-pick, pre-pack, kitting, route review | Warehouse engineering |
| Checking/packing rework | First-pass yield giảm, label reprint, thiếu vật tư | Barcode gate, packing standard, material replenishment, coaching | QC/packing lead |
| Carrier không lấy/ACK | Packed aging, missed pickup, manifest mismatch | Escalate carrier, backup lane, handover evidence, claim | Transport/3PL owner |
| Policy cấu hình sai | Deadline dự báo khác Seller Center | Version registry, sample reconciliation, effective-date rollback | Marketplace admin |
| Thao tác ngoài hệ thống | Có kiện nhưng không có scan hoặc status nhảy cóc | Chặn bypass, supervisor override có reason, audit | Process owner |
| Campaign vượt forecast | Arrival rate vượt plan, top SKU/congestion | Intake cap, campaign overlay, labor trigger, priority policy | Commercial + operations |
Mỗi exception cần order/line/parcel, policy deadline, slack, reason code, evidence, owner, due time, next action và escalation. “Đang xử lý” không phải trạng thái đủ. Reason code phải đủ chi tiết để hành động nhưng không quá vụn: nhóm chính cố định, subreason có quản trị. Free text chỉ bổ sung bối cảnh. Sau một tháng, Pareto theo controllable minutes lost và số đơn giúp chọn cải tiến có đòn bẩy, thay vì tranh luận bằng cảm giác.
Khi một exception chuyển owner, hệ thống giữ lịch sử; không reset tuổi backlog. Ví dụ kho đã packed đúng hạn nhưng carrier missed pickup, owner chuyển từ warehouse sang transport, song timeline kho vẫn được khóa để tránh quy trách nhiệm sai. Nếu carrier ACK đến trễ vì API, phải phân biệt physical acceptance time với system receive time.
10. So sánh nhanh theo mức độ vận hành: OMS-only hay OMS + WMS?
| Phạm vi | Khi có thể đủ | Giới hạn phải chấp nhận |
|---|---|---|
| Seller Center/Excel | Một shop, ít đơn, chủ shop trực tiếp làm, một kho rất nhỏ | Đổi tab thủ công, deadline/policy phân tán, không có reservation hoặc scan evidence đầy đủ. |
| OMS-only | Nhiều shop/kênh nhưng kho đơn giản; tồn, trạng thái và carrier feed đáng tin | Có thể thấy clock/queue nhưng không chứng minh bin, pick, check, pack hoặc short-pick nếu kho không trả event. |
| OMS + WMS | Có nhân viên kho, bin, barcode/PDA, nhiều zone, wave, checking, packing, return hoặc nhiều kho | Cần master data, thiết bị, process discipline, UAT và quyền override rõ. |
| OMS + WMS + 3PL integration | Kho thuê ngoài hoặc hybrid; cần SLA/ACK/evidence xuyên biên giới hệ thống | Phải có data contract, request id, retry, reconciliation, escalation và retention. |
Chọn OMS-only khi câu hỏi chính là “đơn nào, shop nào, deadline nào, kho nào và ai xử lý”. Chọn OMS + WMS khi lỗi xảy ra trong hàng thật: bin rỗng, lấy sai SKU, thiếu số lượng, checking fail, label nhầm, vật tư thiếu, staging sai lane, manifest lệch hoặc carrier chưa nhận. Một dashboard đẹp không thay thế scan. Ngược lại, WMS tốt nhưng không có policy clock đa sàn sẽ tối ưu đường đi mà vẫn có thể làm sai thứ tự SLA.
11. Kế hoạch campaign: ngăn vi phạm trước khi đơn vào
Trước campaign, lập forecast theo giờ và order profile, không chỉ tổng ngày. Ghép demand với usable capacity từng công đoạn, fast-pick replenishment, số PDA/máy in, packing material, staging cube, carrier pickup slot và 3PL cap. Tạo ba kịch bản base/upside/downside. Với mỗi giờ, định nghĩa trigger: coverage dưới 1,1 thì điều người/re-wave; dưới 1,0 thì giảm intake hoặc chuyển nguồn; backlog dưới 60 phút slack vượt ngưỡng thì đóng campaign SKU rủi ro hoặc giảm ads theo thẩm quyền đã duyệt.
Pre-pack/kitting chỉ áp dụng cho cấu hình đơn ổn định và không vi phạm label/order binding. Fast-pick phải đủ tới lần replenishment kế tiếp; đẩy quá nhiều hàng vào mặt pick làm tắc lối và tăng nhầm. Carrier cần booking capacity và fallback. 3PL cần ACK capacity bằng cửa sổ cụ thể, không dùng câu “có thể đáp ứng”. Sau campaign, so forecast với arrival, standard minutes với actual, backlog theo slack, late reason, cancellation reason và hàng hoàn để hiệu chỉnh.
12. 3PL và carrier: SLA nội bộ không kết thúc ở cửa kho
Handover cần manifest id, parcel count, carrier/service, pickup window, cut-off, scan/ACK, discrepancy và owner. “Đã đặt ở khu chờ” không chứng minh carrier nhận. “Carrier đã nhận” cũng chưa chắc platform đã acknowledge. Ba trạng thái phải tách: physically staged, carrier accepted, platform reflected. Nếu hợp đồng 3PL chỉ nói xử lý “trong ngày” mà không định nghĩa start, stop, calendar, exclusion và evidence, không thể dùng để điều hành hoặc claim.
Với kho hybrid, OMS phải route theo ATP, capability, capacity và cut-off; không chỉ chọn kho gần nhất. Nếu đổi nguồn sau reservation, reverse task và hold cũ trước khi tạo allocation mới. Nếu một đơn tách nhiều kiện, SLA và handover phải ở parcel level nhưng roll-up order cần rule rõ: một kiện trễ có làm cả order trễ không, policy sàn hiện hành quyết định thế nào.
13. Common mistakes: sửa các câu trả lời mơ hồ thường gặp
| Cách làm sai | Vì sao sai | Cách sửa |
|---|---|---|
| Chỉ xem tỷ lệ cuối tuần | Khi tỷ lệ xấu thì deadline của đơn đã qua. | Theo dõi order-level clock và at-risk backlog theo phút. |
| Coi in nhãn là hoàn tất | Nhãn có thể nằm trên bàn; kiện chưa pick, pack hoặc bàn giao. | Dùng evidence ladder và event đích đúng theo policy. |
| Một deadline cho mọi đơn | Sai với cut-off, ngày nghỉ, preorder, fulfillment và campaign khác nhau. | Policy registry theo effective date và order attributes. |
| Đơn cũ nhất luôn làm trước | Đơn trẻ hơn có thể hết slack sớm hơn vì carrier cut-off hoặc xử lý dài. | Ưu tiên theo slack/risk, vẫn giữ fairness guardrail. |
| Đổ mọi lỗi cho kho | Đơn có thể vào OMS muộn, tồn sai, label/API lỗi hoặc carrier không ACK. | RCA theo owner và evidence timestamp. |
| Tăng ca là phương án mặc định | Không sửa nghẽn SKU, layout, rework, API hoặc pickup. | Tính capacity gap theo công đoạn và dùng playbook theo nguyên nhân. |
| Lấy tỷ lệ trung bình làm năng lực | Campaign thay order mix; multi-line, bulky, serial và gift khác nhau. | Dùng standard minutes theo profile và phân vị nhịp bền vững. |
| Hard-code ngưỡng của sàn | Chính sách đổi làm cảnh báo sai mà không ai biết. | Lưu source, version, effective date, reviewer và rollback. |
| Xóa đơn hủy khỏi báo cáo | Có thể làm đẹp tỷ lệ nội bộ nhưng che lỗi tồn và mất doanh thu. | Giữ mọi hủy, phân controllable/excluded theo policy riêng. |
| Không giữ bằng chứng | Khó appeal, claim 3PL hoặc chứng minh hệ thống đúng. | Giữ event id, scan, manifest, ACK, log và retention policy. |
Một câu “hãy chuẩn bị đủ hàng và giao đúng hạn” đúng nhưng không đủ để vận hành. Buyer cần biết đủ hàng là sellable ATP nào; đúng hạn là event nào; bắt đầu lúc nào; capacity bao nhiêu; ai hành động; và evidence nào chứng minh. Tương tự, “tùy quy mô” phải được thay bằng order profile, standard minutes, headcount hữu dụng, bottleneck thiết bị, pickup slot và risk budget.
14. Bộ UAT bắt buộc trước khi dùng clock để điều hành thật
| Tình huống kiểm thử | Kết quả chấp nhận |
|---|---|
| Đơn TikTok Shop trước và sau cut-off | Deadline khác nhau đúng rule version; ngày nghỉ được tính theo calendar hiện hành. |
| Policy mới có effective date giữa tuần | Đơn cũ giữ version cũ, đơn mới dùng version mới; báo cáo không restate âm thầm. |
| Một order Lazada có hai order item | Hủy/fulfillment theo line đúng, roll-up order không che một line lỗi. |
| OMS nhận đơn chậm 20 phút | Hiển thị source time và receive lag; không cộng lỗi tích hợp vào thời gian kho. |
| Tồn có nhưng ở quarantine | Không reserve/pick; listing cap hoặc exception được kích hoạt. |
| PDA short-pick một SKU | Dừng task đúng line, mở substitute/re-route/cancel decision có owner. |
| Đơn đã in nhãn nhưng chưa pick | Không được đánh dấu hoàn tất hoặc giảm at-risk backlog. |
| Kiện packed trước hạn, carrier không ACK | Tách warehouse on-time và carrier acceptance; escalation giữ manifest evidence. |
| Carrier ACK đến muộn do API | Giữ event time và receive time; reconciliation tránh phạt sai nội bộ. |
| Hai webhook Shipped giống nhau | Idempotency chặn duplicate; deadline attainment chỉ đếm một lần. |
| 1.000 đơn campaign, order mix đổi | Capacity dùng weighted standard minutes; alert trước khi coverage xuống dưới gate. |
| Một wave tối ưu đường đi nhưng chứa đơn rất gấp | Priority guard tách đơn sắp hết slack hoặc tạo hot wave. |
| Label reprint ba lần | Giữ version, reason, user; checker chặn nhãn cũ. |
| Đơn chuyển kho sau reservation | Reverse allocation/task cũ trước khi phát mới; không giữ tồn kép. |
| Mất kết nối Seller Center | Dữ liệu stale được gắn cờ; fail safe, reconcile khi phục hồi. |
| Appeal một đơn bị tính trễ | Xuất được timeline nguồn–OMS–WMS–manifest–carrier–platform và file bằng chứng. |
UAT không chỉ kiểm màn hình. Cần ghi input, policy version, expected deadline, expected priority, event/evidence, owner, actual output và pass/fail. Chạy cùng các vai trò ecommerce, kho, transport, IT và finance nếu cancellation tác động tiền. Với thay đổi policy, regression test lại ít nhất các case cut-off, holiday, cancel exclusion, multi-line, split parcel và stale event.
15. Buyer execution checklist: 5 việc có thể làm trong 14 ngày
- Ngày 1–2: xuất 14–28 ngày order/line/parcel với source time, status time, cancel reason, shop, warehouse, carrier; lấy policy hiện hành từ Seller Center và gắn ngày kiểm tra.
- Ngày 3–5: vẽ timeline từ eligible tới platform acknowledgement; đo P50/P90/P95 và receive lag, tách event nào có bằng chứng thật.
- Ngày 6–8: time study 5–8 order profile tại pick–check–pack–stage; tính capacity coverage theo giờ và xác định bottleneck.
- Ngày 9–11: tạo at-risk queue với slack bands, 8–12 reason code, owner, due time và playbook; chạy shadow không tự đổi thứ tự thật.
- Ngày 12–14: test UAT, đối chiếu một mẫu đơn với Seller Center, sửa policy/capacity sai; sau sign-off mới mở cảnh báo và priority theo phạm vi nhỏ.
16. Dashboard cho ba nhịp: trong ca, hằng ngày và hằng tuần
Trong ca, màn hình cần at-risk backlog theo slack, công đoạn, kho, carrier và action; capacity coverage theo giờ; packed-not-accepted; oldest exception; hot-wave share. Hằng ngày, review on-time theo policy version, first-pass yield, cancel controllability, receive lag, missed pickup và evidence completeness. Hằng tuần, xem Pareto root cause, repeat SKU/bin/carrier, standard-minute variance, policy changes, appeal outcome và cost của recovery.
Không xếp hạng nhân viên chỉ bằng số đơn/giờ. Một người xử lý bulky, serial hoặc exception sẽ thấp hơn người làm single-line. Dùng earned hours theo profile, quality, rework và safety. Dashboard phải cho phép drill-down tới event/evidence nhưng phân quyền dữ liệu khách hàng. KPI vận hành không được khuyến khích scan giả hoặc chuyển lỗi sang ca sau.
17. Ứng phó khi hệ thống hoặc dữ liệu bị gián đoạn
Khi API sàn chậm, gắn data stale và dùng last-known policy/version; không coi không có đơn mới là demand bằng 0. Khi WMS/PDA lỗi, offline procedure cần số thứ tự kiểm soát, phạm vi SKU/order, người phê duyệt và reconciliation sau phục hồi. Khi label service lỗi, chặn packing sai nhãn; không in từ nguồn ngoài rồi bỏ qua trace. Khi carrier API lỗi nhưng pickup vật lý diễn ra, giữ manifest và pickup evidence, sau đó reconcile event.
Degraded mode có trigger và exit gate. Ví dụ chỉ nhận SKU có ATP buffer, đóng listing tồn thấp, giới hạn order volume nội bộ, ưu tiên một kho đã xác minh và dừng auto-re-route. Recovery chỉ hoàn tất khi control total chứng minh mọi order/event được ingest đúng, duplicate bằng 0 theo key và backlog exception có owner; “API đã xanh” chưa đủ.
18. Nghiệm thu và lộ trình triển khai 30–60 ngày
Tuần 1–2 chuẩn hóa policy registry, event map, SKU/warehouse/carrier master và baseline. Tuần 3 chạy shadow clock trên một shop và một kho, không tác động thứ tự thật. Tuần 4 mở alert cùng exception owner. Tuần 5–6 thêm capacity coverage và priority cho nhóm đơn đại diện; giữ manual approval. Sau ít nhất một chu kỳ bình thường và một peak nhỏ, mới cân nhắc auto-wave hoặc intake cap trong guardrail đã duyệt.
Acceptance gate gồm: deadline đối chiếu đúng với mẫu Seller Center; event không mất/nhân đôi; P95 receive lag trong SLO; priority giải thích được; WMS scan trace tới line/parcel; manifest control total khớp; exception có owner; policy rollback được; UAT pass; và báo cáo không restate lịch sử âm thầm. Chỉ số cải thiện phải so cùng order mix và policy version. Không dùng dữ liệu khách hàng giả hoặc claim giảm bao nhiêu phần trăm nếu chưa có baseline thật.
19. Kết nối OMS + WMS của JST ERP Việt Nam
Giải pháp marketplace đa kênh là lớp phù hợp để hợp nhất shop, order line, policy clock, reservation, routing và exception. Giải pháp vận hành kho đi sâu vào bin location, PDA, barcode, picking, checking, packing, staging và bằng chứng bàn giao. Trang sản phẩm giúp xác định phạm vi OMS-only hay OMS + WMS; dịch vụ triển khai và hỗ trợ nêu cách khảo sát, UAT và đồng hành go-live.
Đọc thêm SLA đồng bộ tồn kho đa sàn để kiểm reliability và degraded mode; định biên nhân sự kho để đổi workload thành phút; SLA 3PL fulfillment để thiết kế evidence/scorecard; fulfillment giao trong ngày để triển khai cut-off; và tồn kho an toàn cho campaign để giảm hủy do hết SKU.
Xem câu trả lời ngắn tại FAQ OMS + WMS. Khi cần khảo sát, hãy chuẩn bị mẫu đơn đã che dữ liệu nhạy cảm, policy hiện hành, timestamp từ OMS/WMS/carrier, order profile và một ca campaign đại diện rồi đăng ký tư vấn. Các ngưỡng nền tảng phải được xác minh lại theo Seller Center tại thời điểm triển khai.