Tóm tắt nhanh: SLA tốt là một bộ quy tắc đo, không phải một câu hứa
Nếu chỉ có 15 phút để đọc hợp đồng 3PL, hãy tìm bảy thành phần của từng cam kết: metric, clock start, clock stop, eligible population, exclusions, evidence và remedy. Thiếu một thành phần, hai bên có thể cùng nhìn một đơn nhưng tính kết quả khác nhau. “Đóng gói trong sáu giờ” chẳng hạn phải nói sáu giờ lịch hay giờ làm việc; tính từ lúc seller tạo đơn, OMS gửi, 3PL ACK hay supervisor release; dừng lúc packed, in label hay carrier scan; đơn thiếu tồn và đơn gửi sau cut-off có nằm trong mẫu số không.
Cách triển khai an toàn là thiết kế service catalogue trước, event contract sau, scorecard thứ ba và cơ chế thương mại cuối cùng. Đừng bắt đầu bằng mức phạt. Nếu dữ liệu OMS, WMS và carrier chưa cùng định nghĩa parcel, timestamp, status và reason code, service credit chỉ biến tranh luận vận hành thành tranh luận hóa đơn. Pilot 30 ngày bằng SKU, barcode, bin location, PDA, picking, checking, packing, COD, hàng hoàn và ngày peak đại diện sẽ có giá trị hơn một bản demo trơn tru.
Thông tin thực thể liên quan
| Thực thể | Vai trò trong SLA 3PL fulfillment |
|---|---|
| JST ERP Việt Nam | Lớp OMS + WMS kết nối đơn đa kênh, tồn khả dụng, kho, parcel, hàng hoàn và evidence vận hành. |
| OMS | Sở hữu order promise, SKU/channel mapping, ATP, reservation, routing, cut-off, COD và exception phía seller. |
| WMS / 3PL WMS | Sở hữu physical state và task receiving, putaway, picking, checking, packing, inventory, handover và return QC tại node kho. |
| 3PL fulfillment | Đối tác thực thi lưu kho và hoàn tất đơn theo service catalogue, SLA, evidence và trách nhiệm đã thỏa thuận. |
| Marketplace/carrier | Cung cấp deadline, order status, pickup và custody event cần map với SLA nội bộ của seller và 3PL. |
1. Khoảng trống nội dung: có thời gian cam kết nhưng thiếu cơ chế kiểm chứng end-to-end
Rà soát nguồn công khai cho thấy thị trường Việt Nam không thiếu mô tả fulfillment. Trang dịch vụ và knowledge base đã nói về thời gian xử lý, nhập kho, kiểm kho, API, bảng kê hoặc megasale. Phần mềm đa kênh nói về gom đơn, đồng bộ tồn và tự động hóa. Đây là nền tốt. Tuy nhiên buyer vẫn phải tự nối nhiều mảnh thành một SLA có thể vận hành: đơn nào đủ điều kiện, mốc nào chuyển trách nhiệm, dữ liệu nào thắng khi hai hệ thống lệch, ai giải quyết hàng hoàn không nhận diện được, và backlog peak phục hồi trong bao lâu.
| Nguồn đối chiếu | Nội dung đã có | Khoảng trống còn lại |
|---|---|---|
| Boxme – cam kết vận hành công khai | Công bố mốc đóng gói, bàn giao, nhập kho, tồn kho và cách xử lý khi megasale vượt năng lực. | Có mốc cụ thể nhưng buyer vẫn phải chuẩn hóa start/stop event, lịch làm việc, mẫu số, loại đơn, evidence, exception, remedy và dữ liệu đối soát. |
| Boxme – knowledge base và bảng kê | Mô tả processing time, nhóm chi phí, bồi thường, điều chỉnh tồn bất thường và trạng thái bảng kê. | Nội dung hữu ích theo dịch vụ cụ thể, nhưng chưa phải mẫu scorecard trung lập để buyer so nhiều 3PL, nhiều kho và nối SLA vận hành với settlement. |
| BigSeller/Sapo và SERP phần mềm đa kênh | Nhấn mạnh gom đơn, đồng bộ tồn, xử lý đơn và vận hành ổn định ở cao điểm. | Thường nói capability hoặc lợi ích; thiếu cách xác định phút nào 3PL nhận trách nhiệm, dữ liệu nào chứng minh bàn giao và xử lý queue khi API không ACK. |
| Shopify community và seller forum công khai | Người bán hỏi về tồn không khớp, mispick, return, hidden fee, reporting, receiving time và khả năng scale peak. | Pain point xác nhận nhu cầu nhưng ý kiến cá nhân không phải benchmark; cần chuyển câu hỏi thành metric, test case, evidence và acceptance gate có thể đo. |
Thảo luận seller công khai lặp lại bốn nhóm đau: nhận hàng không khớp, mispick, return chậm và năng lực peak. Những thảo luận này chỉ được dùng để xác nhận loại câu hỏi, không dùng con số cá nhân làm chuẩn ngành. Bài viết chuyển câu hỏi thành định nghĩa, công thức và acceptance test. Mọi target phải được hai bên thay bằng baseline thật, service class thật và ràng buộc hợp đồng thật trước khi áp dụng.
So sánh nhanh theo mức độ vận hành: bản đồ 12 miền SLA 3PL
Nhiều hợp đồng tập trung vào pick-pack vì đây là phần dễ nhìn thấy. Nhưng seller có thể vẫn mất doanh thu khi hàng đã đến kho mà chưa sellable, tồn sai khiến OMS phát ATP quá mức, hàng hoàn nằm chờ QC, hoặc API không trả event. SLA phải theo vòng đời SKU và đơn, từ inbound appointment đến settlement. Một chỉ số on-time outbound cao không bù được tồn sai hoặc return aging dài.
| Miền SLA | Điều cần đo | Bằng chứng tối thiểu | Điểm dễ hiểu sai |
|---|---|---|---|
| Inbound appointment | Xe/ASN đến đúng slot và đủ chứng từ | appointment ID, ASN, check-in, dock-in | Không đồng nhất với receiving hoàn tất |
| Receiving | Từ kiện được 3PL nhận đến khi quantity discrepancy được ghi | ASN line, unit/case/pallet, damage, timestamp | Blind count hay theo ASN phải ghi rõ |
| Putaway / available | Từ receiving hoàn tất đến khi tồn đủ điều kiện bán | SKU, lot/serial, bin, status, putaway task | Received không mặc định là sellable |
| Inventory accuracy | Khớp quantity, location và status theo phạm vi kiểm | cycle count, adjustment, reason, approval | Không dùng một tỷ lệ tổng che SKU rủi ro |
| Order acknowledgement | Từ OMS gửi request hợp lệ đến ACK/reject | order ID, request ID, ACK, reason code | Không ACK không được xem là accepted |
| Pick–check–pack | Từ accepted/released đến packed đúng và có parcel | task, user, scan, weight, label, parcel ID | Tách standard, combo, bulky, B2B, special handling |
| Carrier handover | Từ packed đến scan manifest/handover hợp lệ | manifest, parcel, carrier, pickup, signer | Printed label không phải bằng chứng bàn giao |
| Return receiving | Từ carrier giao hoàn đến 3PL scan đúng kiện | return ID, parcel, seal, weight, photos | Carrier delivered không phải return QC |
| Return QC | Từ nhận hoàn đến disposition A/B/C/rework/claim | SKU/serial, condition, reason, photo, operator | Chỉ A/sellable mới được tăng ATP |
| Claim and compensation | Từ claim đủ hồ sơ đến quyết định và settlement | claim ID, evidence checklist, decision, amount | Tách phản hồi đầu tiên và đóng claim |
| Data/API | Event, inventory snapshot, report đúng hạn và đầy đủ | event ID, schema version, latency, retry, export | Availability không đồng nghĩa dữ liệu đúng |
| Peak capacity | Sản lượng/giờ hoặc ngày được reserve theo profile | forecast, commitment, release, backlog, recovery | Không dùng “xử lý linh hoạt” làm quota |
Tùy mô hình, carrier có thể là nhà thầu của seller, của 3PL hoặc của marketplace. Vì thế clock handover phải gắn với chuyển custody thực tế, không tự động quy toàn bộ last-mile cho kho. Tương tự, 3PL có thể chịu trách nhiệm đếm nhận nhưng seller chịu master data; hoặc 3PL chịu return QC còn seller quyết disposition. SLA tốt tách rõ service do ai kiểm soát và dependency do ai cung cấp.
3. Viết clock start–stop trước khi thương lượng tỷ lệ
Clock là xương sống của SLA. Mỗi clock phải dùng timestamp machine-readable, cùng timezone Asia/Ho_Chi_Minh hoặc UTC có quy tắc chuyển đổi, đồng thời nói rõ lịch làm việc. Nếu “giờ làm việc” dừng vào tối, cuối tuần hoặc ngày lễ thì calendar phải là dữ liệu cấu hình và có version. Nếu campaign dùng lịch đặc biệt, hai bên phải chốt trước, không sửa sau khi đã biết kết quả.
| Clock | Start | Stop | Exclusion/pause hợp lệ |
|---|---|---|---|
| Order ACK | OMS tạo request hợp lệ và nhận HTTP/gateway receipt | 3PL trả accepted hoặc rejected có reason | Đơn test, duplicate, thiếu master data, ngoài scope nếu reject đúng |
| Fulfillment on-time | 3PL accepted và order released trước cut-off | Packed hoặc carrier handover theo service đã chốt | Customer hold, fraud hold, thiếu chứng từ do seller nếu có evidence |
| Receiving | 3PL scan nhận shipment/ASN tại dock | Kết thúc count và phát discrepancy report | ASN sai, không appointment, hàng cần QC đặc biệt theo rule |
| Inventory available | Receiving line accepted | Putaway xong và status sellable phát về OMS | Quarantine, damage, lot/serial lỗi, chưa đủ tài liệu |
| Return QC | Return parcel scan nhận | Tất cả return line có disposition | Kiện không nhận diện được chuyển exception nhưng clock riêng vẫn chạy |
| Claim closure | Claim đủ evidence theo checklist | Quyết định cuối và bù trừ/thanh toán ghi nhận | Khoảng thời gian seller bổ sung hồ sơ chỉ pause khi có request rõ |
Pause clock là nơi KPI dễ bị làm đẹp. Chỉ pause khi có event, reason code, người tạo, thời gian bắt đầu, yêu cầu cần seller thực hiện và thời gian resume. Một email hoặc tin nhắn “đơn có vấn đề” không đủ nếu không map về order ID. Đơn ở trạng thái UNKNOWN vẫn phải nằm trong backlog; không được loại khỏi mẫu số chỉ vì chưa tìm ra nguyên nhân.
4. Chọn đúng mẫu số: order, order line, unit hay parcel?
Một đơn ba dòng hàng có thể tạo hai kiện và năm unit. Nếu đo accuracy theo order, chỉ một unit sai làm cả order sai; nếu đo theo unit, 999 unit đúng có thể che một đơn VIP giao sai hoàn toàn. Không có grain duy nhất cho mọi mục đích. Outbound on-time thường nên báo theo order và parcel; picking accuracy theo line hoặc unit; inventory theo SKU-location-status; claim theo incident và giá trị.
| Metric | Công thức nền | Điều kiện chống hiểu sai |
|---|---|---|
| On-time rate | số item/đơn đạt stop event trước deadline ÷ tổng item/đơn đủ điều kiện | Định nghĩa grain là order, line hay parcel; không đổi giữa kỳ |
| Order accuracy | đơn giao đúng SKU, unit, condition, tài liệu ÷ đơn được kiểm chứng | Ghi gross trước rework; không xóa lỗi vì đã gửi bù |
| Inventory accuracy | điểm kiểm khớp theo metric đã chọn ÷ tổng điểm kiểm | Báo riêng quantity, location, status và SKU rủi ro cao |
| Backlog aging | số đơn open theo dải 0–2h, 2–4h, 4–8h, quá cut-off | Snapshot theo giờ và trước pickup, không chỉ cuối ngày |
| API event completeness | event hợp lệ nhận đủ ÷ event phải nhận theo control total | Kiểm missing, duplicate, out-of-order và schema reject |
| Claim closure on-time | claim đủ hồ sơ đóng trong deadline ÷ claim đủ hồ sơ | Báo thêm số ngày và giá trị tiền đang mở |
| Peak capacity attainment | good units/lines/parcel hoàn tất trong cửa sổ ÷ capacity đã commit | Good output phải qua accuracy và handover gate |
On-time fulfillment = eligible order hoặc parcel đạt stop event trước deadline ÷ toàn bộ eligible order hoặc parcel.
Gross accuracy phải ghi nhận lỗi khi phát sinh; net customer impact báo riêng sau rework, không dùng net để xóa lỗi quy trình.
Hai bên cần khóa grain theo metric trong data dictionary. Nếu tháng này tính order còn tháng sau tính parcel, xu hướng không so được. Khi thay đổi định nghĩa, giữ version, effective date và backfill nếu có thể. Scorecard nên hiển thị cả numerator, denominator và excluded count; chỉ hiển thị phần trăm khiến người đọc không biết KPI cao vì vận hành tốt hay vì mẫu số bị thu nhỏ.
5. Ví dụ thay số: vì sao 97,2% on-time không kể hết câu chuyện
Giả sử trong một kỳ minh họa có 10.000 đơn hợp lệ trước cut-off. Có 9.720 đơn đã có bằng chứng handover đúng hạn, 210 đơn bàn giao trễ và 70 đơn chưa có handover proof tại thời điểm chụp. On-time bằng 9.720 chia 10.000, tức 97,20%. Không được bỏ 70 đơn open ra khỏi mẫu số, vì chính chúng là rủi ro SLA. Đây chỉ là ví dụ toán học, không phải target phù hợp cho mọi doanh nghiệp.
| Thành phần minh họa | Số lượng | Cách đọc |
|---|---|---|
| Đơn eligible trước cut-off | 10.000 | Đã trừ test order và reject hợp lệ; không trừ đơn khó |
| Bàn giao đúng hạn | 9.720 | On-time = 97,20% |
| Bàn giao trễ | 210 | Giữ trong mẫu số và phân reason |
| Chưa có handover proof lúc snapshot | 70 | Là backlog/open, không được tính đạt |
| Đơn có lỗi fulfillment gross | 46 | Accuracy gross = 99,54%; lỗi đã rework vẫn là lỗi gross |
| Đơn khách nhận sai sau khi đã bàn giao | 8 | Điều tra thêm carrier/tamper nhưng không xóa khỏi queue chất lượng |
Cùng kỳ đó, 46 đơn có lỗi gross trong kho. Accuracy theo order là 99,54%, nhưng buyer vẫn phải xem lỗi tập trung ở SKU nào, ca nào, station nào và khách có bị ảnh hưởng không. Tám đơn khách nhận sai có thể liên quan tamper hoặc carrier; chúng vào queue điều tra riêng chứ không bị xóa. Hai KPI phải đọc cùng backlog aging, P95 duration và error severity. Một tỷ lệ cao không tự động có nghĩa trải nghiệm tốt nếu lỗi ít nhưng giá trị lớn.
6. Trung bình che đơn trễ: dùng percentile và backlog aging
Nếu 95 đơn mất một giờ còn 5 đơn mất 21 giờ, thời gian trung bình là hai giờ. Báo cáo “average 2h” nghe tốt nhưng năm khách cuối chịu chờ gần một ngày. Median còn đẹp hơn nhưng che phần đuôi mạnh hơn. Vì vậy, SLA nên kết hợp tỷ lệ đúng hạn, P90/P95 hoặc P99 và số đơn open theo dải tuổi. Percentile không thay thế deadline; nó giúp thấy phân phối và thiết kế công suất.
| Thước đo | Ý nghĩa | Cách dùng đúng |
|---|---|---|
| Average | Tổng duration ÷ số đơn | Dễ hiểu nhưng bị đơn cực nhanh che đơn rất trễ |
| Median/P50 | 50% đơn nhanh hơn hoặc bằng mốc này | Mô tả đơn điển hình, không bảo vệ phần đuôi |
| P90 | 90% đơn nhanh hơn hoặc bằng mốc này | Hữu ích cho vận hành thường ngày và capacity |
| P95/P99 | Đo phần đuôi chậm | Giúp phát hiện queue, API lỗi, SKU khó hoặc cut-off miss |
| Maximum | Đơn chậm nhất | Dùng điều tra incident, không nên là KPI duy nhất |
Backlog aging cần snapshot theo giờ, trước từng pickup và cuối ngày. Tách accepted-not-released, released-not- picked, picked-not-packed, packed-not-manifested và manifested-not-scanned. Nếu chỉ có tổng backlog, quản lý không biết bottleneck ở replenishment, picking, checking, packing, staging hay carrier. OMS xác định promise và priority; WMS cung cấp task state. Hai lớp kết hợp mới cho phép recovery plan có owner.
7. Inventory accuracy: một tỷ lệ 99,x% có thể vẫn bán sai tồn
Tồn kho phải được đo ít nhất ở ba chiều: quantity, location và status. SKU có đủ tổng unit nhưng nằm sai bin làm picker short; unit đúng bin nhưng đang damaged mà hệ thống ghi sellable làm OMS phát ATP sai; tổng giá trị khớp nhưng SKU A thừa bù SKU B thiếu vẫn gây overselling. Hợp đồng phải nói kiểm theo SKU, SKU-bin, unit, line hay value, phương pháp chọn mẫu, cadence và cách xử lý hàng đang move hoặc quarantine.
Quantity-location-status accuracy = số điểm kiểm khớp đủ ba chiều ÷ tổng điểm kiểm trong scope; báo riêng SKU rủi ro cao.
Cycle count cần risk-based: SKU bán nhanh, giá trị cao, nhiều adjustment, nhiều return hoặc hay short-pick được đếm thường xuyên hơn. Mỗi adjustment cần reason, evidence, approver và liên kết claim nếu có. “Kiểm kho mỗi quý” là cadence, chưa phải cách tính accuracy. Seller phải có quyền export snapshot, count result và adjustment history để đối soát, đặc biệt trước kỳ hóa đơn, campaign hoặc khi rút hàng khỏi 3PL.
OMS không nên cộng thẳng on-hand của 3PL thành tồn bán. ATP cần trừ reservation, safety stock, hold, damaged, return pending QC, transfer và channel quota. Nếu 3PL WMS chỉ gửi một trường available không có as-of timestamp, seller phải chốt rõ nghĩa và freshness. Khi feed quá cũ, rule fail-safe có thể hạ tồn phát sàn thay vì tiếp tục hứa bán bằng snapshot không đáng tin.
8. Outbound SLA: tách accepted, released, packed và handed over
Order created trên sàn chưa chắc đã sẵn sàng cho 3PL. OMS có thể còn fraud hold, payment hold, address validation, allocation hoặc bundle explosion. Chỉ khi payload hợp lệ được 3PL ACK thì trách nhiệm tích hợp mới chuyển bước. Sau ACK, seller hoặc OMS release theo rule; WMS tạo wave/task; picker scan SKU và bin; checker xác nhận unit; packer tạo parcel; staging phân lane; dispatch scan manifest. Mỗi mốc giải thích một loại chậm khác nhau.
Hợp đồng cần service class: standard B2C, priority, same-day, B2B, bulky, special handling, lot/serial, dangerous or restricted goods nếu được phép. Không nên lấy một clock chung rồi loại dần các đơn khó. Mỗi class có eligibility, cut-off và capacity. Nếu seller gửi order mix khác forecast, 3PL có thể áp trigger đã chốt; nhưng trigger phải dựa dữ liệu, không phải câu “đơn tăng đột biến” sau sự cố.
Printed label không phải packed nếu kiện chưa qua check; packed không phải handed over nếu kiện còn staging; manifest created không phải custody transfer nếu carrier chưa scan hoặc ký nhận. Marketplace SLA thường quan tâm mốc của sàn/carrier, còn SLA nội bộ cần đủ mốc để biết ai đang giữ kiện. Hai khái niệm phải được map, không nhập làm một.
9. Hàng hoàn: bài kiểm tra thật của 3PL và nguồn gây tồn ảo
Return cần ít nhất ba clock: carrier delivered-to-3PL, return receiving và return QC/disposition. Carrier báo giao về không chứng minh đúng kiện; scan nhận kiện không chứng minh sản phẩm bán lại được; refund tài chính không tự động tăng tồn vật lý. Mỗi return line phải map original order line, SKU/serial nếu có, reason, condition, photo và disposition. Chỉ event sellable được phép tạo bút toán tăng ATP, với idempotency để không cộng hai lần.
Hợp đồng cần định nghĩa unmatched return, partial return, empty parcel, wrong item, missing accessory, seal broken, damaged, refurbish/rework và disposal/claim. Với ngành mỹ phẩm, điện tử, thời trang hoặc hàng có hạn dùng, checklist QC khác nhau. Không nên dùng một SLA “xử lý hoàn trong X ngày” nếu không nói mức kiểm tra. Chi phí inspection, photo, repack, relabel, restock và disposal cũng phải map với event để finance đối soát.
Scorecard return nên có inbound parcels, matched rate, receiving on-time, QC on-time, disposition mix, A-grade return-to-stock, unknown aging, claim value và double-restock exception. Tỷ lệ A/B/C không dùng để so 3PL nếu policy sản phẩm khác; nó dùng phát hiện thay đổi và điều tra. Seller vẫn là owner của policy, 3PL là executor có evidence.
10. Scorecard phải dẫn đến hành động, không phải slide cuối tháng
| Nhóm | Metric cốt lõi | Cadence | Owner |
|---|---|---|---|
| Receiving | Dock-to-count, discrepancy report, putaway-to-sellable | Hằng ngày/tuần | Inbound lead + inventory controller |
| Inventory | Quantity/location/status accuracy, adjustment value, negative stock | Tuần/tháng | 3PL inventory lead + seller ops |
| Outbound | ACK, on-time pack, on-time handover, backlog aging | Theo giờ/ngày | 3PL outbound lead + seller ecommerce |
| Quality | Gross mispick, missing unit, damage, document/label error | Ngày/tuần | Quality owner |
| Returns | Return receiving, QC aging, disposition mix, unmatched parcel | Ngày/tuần | Reverse logistics owner |
| Data | API latency, completeness, duplicates, rejects, report timeliness | Realtime/ngày | IT/integration owners |
| Commercial | Bill accuracy, open dispute, claim value, service credit | Kỳ invoice | Finance/procurement |
| Peak | Forecast accuracy, committed capacity, attainment, recovery hours | Trước/trong/sau campaign | Both operations managers |
Báo cáo theo tháng là quá chậm cho SLA marketplace. Outbound backlog, API queue và carrier handover cần theo giờ; inventory và returns theo ngày/tuần; invoice và claim theo kỳ. Steering tháng dùng để xem xu hướng, capacity, RCA và thương mại, không thay thế daily control. Mỗi KPI đỏ phải drill-down được đến order/line/parcel/SKU và event, nếu không đội vận hành chỉ tranh luận về phần trăm.
Một scorecard tốt có actual, target, numerator, denominator, excluded count, trend, reason distribution, top impact, action, owner và due date. Đồng thời phải có data quality banner: control total có khớp không, snapshot tới mấy giờ, event thiếu bao nhiêu, schema version nào. Nếu data completeness không đạt, KPI phải đánh dấu provisional thay vì tự động coi là xanh hoặc đỏ.
11. Reason code và exclusion: kiểm soát nơi KPI dễ bị làm đẹp nhất
| Reason code | Ý nghĩa | Evidence yêu cầu |
|---|---|---|
| SELLER_DATA | SKU/barcode/địa chỉ/chứng từ do seller thiếu hoặc sai | Payload, validation response, timestamp, owner request |
| 3PL_CAPACITY | Thiếu người, thiết bị, station, vật tư hoặc slot nội bộ | Capacity plan, shift, queue, downtime, recovery |
| INVENTORY_NOT_FOUND | Hệ thống có tồn nhưng không tìm thấy tại bin | Pick task, bin scan, cycle count, adjustment |
| API_OR_DATA | Missing/duplicate/out-of-order/rejected event | Request ID, log, schema, retry, reconciliation |
| CARRIER | Carrier đến trễ, từ chối kiện hoặc thiếu capacity pickup | Appointment, manifest, scan, rejection reason |
| FORCE_MAJEURE | Sự kiện ngoài kiểm soát theo hợp đồng | Incident notice, phạm vi, thời gian, mitigation |
| CUSTOMER_OR_PLATFORM | Khách/sàn hold, hủy hoặc thay đổi hợp lệ | Platform event, user, timestamp |
| UNKNOWN | Chưa xác định | Chỉ dùng tạm; phải có hạn RCA, không được trở thành bucket mặc định |
Reason code nên hữu hạn, mutually understandable và có owner. Free text dùng bổ sung, không thay taxonomy. Một đơn có thể có nhiều contributing factor nhưng cần primary cause để báo cáo và secondary cause để học. UNKNOWN chỉ là trạng thái tạm với hạn RCA. Nếu cuối tháng UNKNOWN chiếm lớn, scorecard chưa đủ tin cậy và không nên dùng để quyết service credit tự động.
Seller-caused không có nghĩa tự động loại. Chỉ loại khi dependency được ghi trong hợp đồng, 3PL phát validation đúng hạn, evidence đủ và clock pause/resume có log. Ví dụ barcode master sai có thể là seller cause; nhưng nếu 3PL đã nhận hàng, không báo discrepancy và đến lúc pick mới phát hiện, trách nhiệm cần phân tích theo control gate.
12. Service credit, claim và corrective action: ba cơ chế khác nhau
Service credit bù một phần phí dịch vụ khi KPI dưới band; claim xử lý mất, hỏng, sai hoặc chi phí cụ thể; corrective action sửa hệ thống để tránh tái diễn. Gộp ba thứ khiến buyer nghĩ một khoản credit nhỏ đã đóng xong lỗi tồn hoặc mispick. Hợp đồng nên chốt cap, cách tính, thời hạn nộp, evidence và trường hợp không giới hạn theo luật/hợp đồng chuyên môn; phần pháp lý cần được cố vấn phù hợp rà soát.
| Mức | Phản ứng vận hành | Governance |
|---|---|---|
| Mức 1 – sai lệch nhỏ, lần đầu | Thông báo, containment trong ca, cập nhật reason | Owner ca + due time |
| Mức 2 – dưới target hoặc lặp lại | RCA 5-Why/fishbone, corrective action, kiểm tra 7–14 ngày | Ops manager hai bên |
| Mức 3 – ảnh hưởng SLA/khách hàng lớn | Incident bridge, ưu tiên backlog, reroute/overflow, báo cáo sau sự cố | Leadership + account owner |
| Mức 4 – mất hàng, sai dữ liệu nghiêm trọng, tái diễn | Bồi thường/service credit theo hợp đồng, audit, improvement plan hoặc exit trigger | Contract owners |
Với KPI trượt nhẹ, ưu tiên containment và learning. Khi lặp lại, cần RCA có dữ liệu: process, people, system, equipment, material, environment. Action phải có expected effect và verification period. Khi incident đe dọa SLA sàn, hai bên cần playbook reroute, overtime/flex labor, overflow, cut-off change có phê duyệt và communication. Exit trigger chỉ dùng khi failure nghiêm trọng hoặc improvement plan thất bại, đồng thời phải có data export và inventory handback plan.
13. API “realtime” phải được định nghĩa bằng latency, completeness và reconciliation
Realtime không phải yes/no. Một event inventory tới sau 30 giây có thể chấp nhận ở ngày thường nhưng nguy hiểm trong flash sale; order ACK chậm làm trùng gửi; event handover mất khiến CSKH nghĩ kiện còn kho. SLA dữ liệu cần ít nhất availability, latency percentile, completeness, correctness, idempotency, ordering, retry/replay, schema change và export/reconciliation.
| Đối tượng dữ liệu | Trường tối thiểu | Test bắt buộc |
|---|---|---|
| Create order | order ID, request ID, channel, cut-off, service, lines, COD | ACK/reject, idempotency, duplicate test |
| Inventory snapshot | SKU, location/node, on-hand, reserved, hold, sellable, as-of | Control total, freshness, negative/unknown state |
| Task/status event | event ID, order/line/parcel, event type, occurredAt, reason | Out-of-order, retry, replay and missing event |
| Parcel/handover | parcel ID, label, weight/dimension, manifest, carrier scan | Một đơn nhiều kiện, relabel, carrier reject |
| Return | return ID, original line, received, QC, disposition, photo | Unknown parcel, partial return, duplicate restock |
| Adjustment/claim | SKU, quantity/value, reason, approver, claim link | Permission, audit trail and monthly close |
Mỗi request/event cần unique ID, occurredAt và receivedAt. Consumer lưu last processed ID hoặc idempotency key; duplicate không tạo đơn hoặc tăng tồn lần hai. Out-of-order event phải theo state transition rule. Dead-letter queue có owner và aging. Reconciliation hằng ngày so control total: order created, accepted, rejected, canceled, parcels, handover, returns, adjustments. API chạy 99,9% nhưng mất một nhóm event quan trọng vẫn không đạt data SLA.
Schema change cần notice, sandbox, version coexistence và rollback. Khi 3PL portal là nơi duy nhất xem dữ liệu, buyer cần quyền export machine-readable cả master, event, inventory history, open order, return và claim. Ảnh chụp dashboard không đủ cho audit hoặc migration. Đây cũng là điều kiện thoát, không chỉ điều kiện tích hợp ban đầu.
14. Campaign peak: chốt capacity bằng profile và cửa sổ, không bằng “gấp X lần”
Công suất phải mô tả good output theo giờ hoặc cửa sổ cut-off, không chỉ tổng đơn/ngày. 10.000 đơn single-line SKU nhỏ khác 10.000 đơn multi-line, combo, quà tặng và hàng cồng kềnh. Forecast cần order, lines/order, units/line, SKU concentration, service class, carrier mix, hourly arrival curve và return/inbound cạnh tranh tài nguyên. 3PL phản hồi committed capacity theo profile, notice window và assumptions.
Required peak capacity = forecast eligible workload trong cửa sổ + backlog đầu kỳ + buffer được duyệt; đo ở bottleneck, không chỉ tổng kho.
Hai bên nên có base, peak và stress scenario. Base là volume thông thường; peak là campaign forecast đã reserve; stress là deviation có trigger. Nếu volume vượt band, playbook nói rõ ưu tiên order, đổi cut-off, flex labor, overflow, carrier quota và recovery time. Thông báo “gia hạn xử lý” chỉ hợp lệ khi có trigger, phạm vi order, deadline mới và ảnh hưởng marketplace được duyệt trước hoặc theo incident governance.
Capacity reservation có thể có phí hoặc minimum; đây là quyết định thương mại. Buyer nên so phí năng lực dự phòng với contribution margin, nguy cơ hủy/trễ, chi phí overtime và phương án hybrid. Với top SKU, có thể giữ buffer ở kho nội bộ/3PL thứ hai, nhưng không nên chia toàn bộ inventory tùy tiện vì transfer và ATP phức tạp. OMS cần routing rule, WMS/3PL cần event và stock visibility chung.
15. OMS-only hay OMS + WMS khi thuê 3PL?
Thuê 3PL không có nghĩa doanh nghiệp không cần hệ thống. OMS vẫn cần gom đơn Shopee, Lazada, TikTok Shop, website và social commerce; chuẩn hóa SKU; giữ tồn; phân kho; theo dõi cut-off; quản lý COD, hủy, refund và seller promise. Nếu 3PL có WMS tốt và trả đủ event, seller có thể dùng OMS-only làm orchestration layer. Điều kiện là seller nhìn được inventory state, task/parcel milestone, return, adjustment, claim và có API/export đủ để đối soát.
OMS + WMS hoặc mô hình WMS tương đương cần thiết hơn khi doanh nghiệp có kho nội bộ song song, nhiều 3PL, cần cùng taxonomy bin/PDA/task, muốn điều phối replenishment/picking/checking/packing, hoặc return QC phức tạp. WMS của seller không nhất thiết thay WMS 3PL; hai hệ thống có thể phân vai. Điều quan trọng là source of truth: OMS sở hữu promise, ATP/routing; WMS mỗi node sở hữu execution và physical state; event contract nối chúng.
Nếu chỉ vài chục đơn, ít SKU và một đối tác có portal rõ, file/API nhẹ có thể đủ trong giai đoạn đầu. Khi seller phải tải báo cáo nhiều lần, hỏi nhóm chat để biết kiện ở đâu, tự cộng trừ hàng hoàn hoặc không phân biệt accepted với handed over, chi phí kiểm soát đã là tín hiệu cần hệ thống hóa. Ngưỡng không nằm ở số đơn duy nhất mà ở exception, data ownership, number of nodes và SLA risk.
16. Pilot 30 ngày: từ data gate đến invoice reconciliation
Đừng đưa toàn bộ SKU và đơn sang 3PL sau buổi demo. Chọn cohort đại diện: SKU bán nhanh/chậm, gần giống nhau, combo, serial/lot nếu có, bulky, nhiều carrier, COD, prepaid và return. Giữ safety stock hoặc rollback path. Pilot phải đi hết vòng đời inbound–outbound–delivery/return–QC–claim–invoice; nếu chỉ test outbound đẹp, phần khó vẫn chưa xuất hiện.
| Giai đoạn | Nội dung | Gate |
|---|---|---|
| Ngày 0–5: data gate | SKU/barcode/UoM, service map, cut-off, order/return reason, API credentials, RACI | Control total và test data được ký xác nhận |
| Ngày 6–10: inbound | ASN đúng/sai, thừa/thiếu, damage, lot/serial, putaway, sellable event | Receiving và inventory evidence khớp |
| Ngày 11–15: outbound chuẩn | Single/multi-line, COD/prepaid, nhiều carrier, split parcel, cancel | ACK, task, pack và handover clock đo được |
| Ngày 16–20: ngoại lệ | Barcode lỗi, short pick, label hỏng, API down, duplicate, out-of-order | Queue, reason, retry và escalation hoạt động |
| Ngày 21–25: returns/claim | Complete/partial/unknown return, A/B/C, damage, claim, settlement | Không double restock; evidence đủ đối soát |
| Ngày 26–30: load và close | Tăng tải theo bậc, pickup window, backlog recovery, invoice sample | SLA/quality/data/cost cùng đạt gate |
Mỗi gate có criteria trước khi chạy: event completeness, on-time, gross accuracy, inventory reconciliation, return aging, open exception, invoice variance và user readiness. Khi fail, dừng tăng tải, containment và rerun. Rollback không nhất thiết rút hàng ngay; có thể ngừng SKU/đơn mới, giữ open orders ở node cũ, reconcile inventory và reroute theo rule. Quan trọng là không để hai hệ thống cùng phát tồn hoặc cùng fulfill một order.
17. RACI: chuyển trách nhiệm bằng event, không bằng câu “bên kho xử lý”
| Quyết định/công việc | Responsible | Accountable | Consulted |
|---|---|---|---|
| Order master và channel promise | Seller ecommerce/OMS owner | Seller operations head | 3PL integration |
| Inventory physical và bin | 3PL WMS/inventory team | 3PL warehouse manager | Seller inventory owner |
| ATP và allocation đa kho | Seller OMS owner | Seller operations head | 3PL WMS |
| Pick–check–pack | 3PL outbound team | 3PL warehouse manager | Seller service owner |
| Carrier handover | 3PL dispatch + carrier | Theo hợp đồng handover | Seller logistics |
| Return QC/disposition | 3PL return team | Seller policy owner | CSKH, finance |
| API và reconciliation | Integration owners hai bên | Technology owners | Operations, finance |
| SLA report và improvement | Account/operations owners hai bên | Steering owner | Procurement, finance |
RACI cần mở đến exception: ai duyệt hủy sau release, ai quyết substitution, ai đóng short-pick, ai điều chỉnh tồn, ai nộp claim, ai quyết return disposition và ai thông báo marketplace. Một người có thể giữ nhiều vai ở doanh nghiệp nhỏ, nhưng vai vẫn phải tồn tại. Khi escalation xảy ra, ticket/incident phải chứa order, parcel, SKU, event, impact, containment, next update và owner.
Governance nên có daily operations review trong pilot, weekly SLA review sau go-live và monthly steering cho xu hướng, capacity, finance, risk. Mọi thay đổi target, exclusion, service calendar, API schema hoặc process cần change record và effective date. Nếu chỉ sửa bảng tính scorecard mà không sửa contract/data dictionary, tranh chấp sẽ lặp lại.
18. Mười lỗi phổ biến khi viết và vận hành SLA 3PL
| Lỗi | Vì sao nguy hiểm | Cách sửa |
|---|---|---|
| Chỉ ghi “xử lý trong 24 giờ” | Không rõ nhận đơn, packed hay handover; giờ thường hay giờ làm việc. | Chốt start/stop event, timezone, calendar, cut-off và service class. |
| Dùng trung bình | 1.000 đơn rất nhanh có thể che 50 đơn trễ nhiều ngày. | Dùng on-time rate, P90/P95 và backlog aging. |
| Loại hết ngoại lệ khỏi mẫu số | Đối tác có thể gắn reason để KPI luôn đẹp. | Danh mục exclusion hữu hạn, evidence bắt buộc và audit mẫu. |
| Tính lỗi net sau rework | Sai pick được sửa trước bàn giao biến mất khỏi báo cáo, không học được nguyên nhân. | Báo gross defect và net customer impact riêng. |
| Tồn chính xác chỉ theo tổng unit | Thừa SKU A bù thiếu SKU B vẫn nhìn như khớp. | Đo quantity, SKU, location, status và value/risk riêng. |
| Printed label = handed over | Kiện có thể còn ở staging hoặc bị carrier từ chối. | Dùng manifest scan hoặc bằng chứng chuyển custody. |
| Có service credit là đủ | Tiền bù nhỏ không phục hồi SLA hoặc ngăn tái diễn. | Bắt buộc containment, RCA, action và exit trigger. |
| Tin API “realtime” | Không có latency percentile, retry và control total thì không biết mất event. | Định nghĩa freshness, completeness, idempotency và reconciliation. |
| Để OMS và WMS cùng sửa tồn | Hai source of truth tạo oversell và adjustment không giải thích được. | Chốt ownership từng state và event contract. |
| Mở toàn bộ lưu lượng sau demo | Demo không tạo ra campaign, return hay outage thật. | Pilot theo SKU/đơn, tăng tải theo gate và có rollback. |
Lỗi chung của các câu trả lời mơ hồ là dùng “thường”, “tùy” hoặc “có thể” mà không đưa điều kiện. Thực tế có phần phụ thuộc, nhưng phải biến phụ thuộc thành input: profile đơn, cut-off, notice, calendar, service class, data quality, carrier appointment và capacity band. Khi chưa đủ dữ liệu, câu trả lời đúng là chạy baseline/pilot, không phải tự tạo benchmark hoặc cam kết không có bằng chứng.
19. Checklist buyer: năm hành động có thể làm ngay
- Xuất 8–12 tuần order, order line, parcel, return, inventory adjustment, cut-off và campaign theo giờ; phân tầng standard, combo, bulky, lot/serial, COD và ngoại lệ.
- Lập service catalogue: dịch vụ nào, ngày làm việc nào, cut-off nào, start/stop event nào, exclusion nào và evidence nào; không thương lượng KPI trước khi thống nhất định nghĩa.
- Gửi cùng một bộ 20–30 test case cho các 3PL: receiving lệch, multi-line, cancel, short pick, label lỗi, carrier reject, return thiếu, duplicate event và API outage.
- Chốt scorecard cùng control total giữa OMS, WMS/3PL và carrier; chạy shadow report ít nhất hai kỳ trước khi gắn service credit hoặc quyết định mở tải.
- Pilot 30 ngày theo gate dữ liệu–inbound–outbound–returns–invoice; chỉ tăng SKU hoặc phần trăm đơn khi SLA, accuracy, data completeness và cost đều đạt.
Nếu chưa chọn 3PL, dùng checklist để so cùng một workload và event contract. Nếu đã vận hành, chọn một metric đang tranh cãi nhất rồi viết lại đủ bảy thành phần. Sau đó backtest 2–4 tuần bằng raw event. Đừng sửa toàn bộ hợp đồng trong một lần nếu dữ liệu chưa đủ; ưu tiên order ACK, handover proof, inventory adjustment và return-to-stock vì đây là các điểm tác động trực tiếp đến SLA, overselling, COD và trải nghiệm khách.
20. JST ERP hỗ trợ kiểm soát 3PL fulfillment như thế nào?
JST ERP có thể đóng vai trò OMS orchestration cho đơn đa kênh, SKU mapping, ATP, reservation, cut-off, routing, COD, return và exception; đồng thời kết nối WMS nội bộ hoặc WMS 3PL để nhận inventory, task, parcel, handover, return QC và adjustment event. Giá trị không nằm ở việc có thêm dashboard, mà ở việc mỗi trạng thái có ID, timestamp, reason, owner và control total để đối soát cùng đối tác.
Phạm vi triển khai cần khảo sát API và quy trình thật. JST ERP không nên cam kết thay 3PL đạt một tỷ lệ cụ thể nếu chưa có baseline, data access và quyền kiểm soát quy trình. Cách an toàn là chuẩn hóa data dictionary, test event, chạy pilot, lập scorecard và mới mở rộng volume. Nếu doanh nghiệp dùng hybrid, OMS giữ phân bổ và tồn khả dụng; từng WMS/node giữ thao tác vật lý và trả evidence.
Để chuẩn bị buổi tư vấn, doanh nghiệp có thể xem sản phẩm OMS + WMS, giải pháp bán hàng đa kênh, giải pháp vận hành kho, cam kết dịch vụ, FAQ, khung chọn kho nội bộ hay 3PL, khung fulfillment giao trong ngày và khung hàng hoàn–return QC. Hãy mang theo 8–12 tuần order/parcel/return, hợp đồng hiện tại, file invoice, danh sách exception và ba tình huống gây tranh cãi nhất.