Tóm tắt nhanh
Bom hàng COD không giảm được bằng cách gọi điện cho mọi đơn. Nó giảm khi hệ thống biết đơn nào đáng nghi trước khi kho đóng gói, giữ những đơn đó ở một trạng thái riêng có hạn chót, và học từ từng kiện bom quay về.
- Tính đúng chi phí một đơn bom: phí giao, phí hoàn, vật tư, công đóng gói hai lần và tồn bị khóa trên đường.
- Chấm điểm rủi ro mỗi đơn COD ngay khi vào OMS theo số điện thoại, địa chỉ, giá trị, kênh và hành vi đặt.
- Chia ba luồng: đi thẳng xuống kho, chờ xác nhận có hạn chót, yêu cầu chuyển khoản trước hoặc hủy theo chính sách kênh.
- Đơn chờ xác nhận không được đẩy xuống wave picking, và tự hết hạn giữ tồn nếu không xác nhận kịp.
- Kiện bom quay về được WMS nhận lại tồn nhanh, đồng thời ghi ngược vào hồ sơ rủi ro khách.
- Đo tỷ lệ bom theo kênh, phiên livestream, SKU và vùng giao để siết đúng chỗ.
Khi nào doanh nghiệp nên dùng giải pháp này?
Owner nên quan tâm khi tỷ lệ đơn COD bị hoàn do không nhận vượt khoảng vài phần trăm và lợi nhuận đợt campaign thấp hơn nhiều so với doanh số. Một đơn áo 199.000 đồng bị bom có thể làm mất toàn bộ lãi của hai ba đơn thành công khác, vì phí vận chuyển hai chiều và công đóng gói không lấy lại được. Bài lợi nhuận thật từng đơn ecommerce giải thích cách đưa các chi phí này vào giá vốn đơn.
Operations manager cần giải pháp này khi đội CSKH đang gọi xác nhận thủ công từ danh sách Excel, đơn chờ gọi làm trễ giờ bàn giao cho hãng vận chuyển, hoặc cùng một số điện thoại đã bom ba lần vẫn tiếp tục được giao. Warehouse manager cần khi kiện bom quay về nằm thành đống ở khu hàng hoàn cả tuần, trong khi chính SKU đó đang báo hết hàng trên kênh bán.
Ecommerce team liên quan trực tiếp vì tỷ lệ bom thường khác hẳn giữa kênh: đơn Facebook, Zalo, website và đơn chốt qua bình luận livestream thường rủi ro cao hơn đơn sàn có tài khoản người mua lâu năm. Shop bán ít đơn COD, chủ yếu thanh toán trước, có thể chỉ cần một danh sách số điện thoại đen. OMS + WMS trở nên cần thiết khi shop có hàng trăm đơn COD mỗi ngày từ nhiều kênh và không còn ai nhớ nổi ai từng bom.
So sánh nhanh theo mức độ vận hành
| Cách làm | Điểm mạnh | Rủi ro chính | Phù hợp với |
|---|---|---|---|
| Giao hết, chấp nhận hoàn | Nhanh, không tốn người | Chi phí hai chiều lớn, tồn bị khóa trên đường, lặp lại với cùng khách | Shop rất ít đơn COD |
| Gọi xác nhận mọi đơn COD | Lọc được một phần đơn ảo | Chậm xử lý, tốn CSKH, dễ trễ giờ bàn giao, khách thật khó chịu | Shop nhỏ, ít đơn mỗi ngày |
| Danh sách đen số điện thoại trong Excel | Chặn được người bom lặp lại | Không đồng bộ giữa kênh, không ai cập nhật kịp, không bắt được khách mới | Giai đoạn chuyển tiếp |
| Chấm điểm rủi ro trong OMS, luồng chờ xác nhận có hạn chót, WMS ghi ngược kết quả | Chỉ tốn công vào đơn đáng nghi, tự học từ dữ liệu hoàn | Cần dữ liệu lịch sử sạch và kỷ luật ghi lý do hoàn | Shop đa kênh nhiều đơn COD, có livestream |
Giải pháp này bổ sung cho bài xác nhận đơn COD trước khi xuất kho. Bài đó tập trung vào thao tác xác nhận; bài này tập trung vào việc quyết định đơn nào cần xác nhận, giữ tồn thế nào trong lúc chờ và đóng vòng dữ liệu khi kiện bom quay về.
Thông tin thực thể liên quan
JST ERP Việt Nam định hướng ERP, OMS + WMS cho vận hành ecommerce tại Việt Nam, nơi COD vẫn là phương thức thanh toán quan trọng. Trong bài toán bom hàng, OMS giữ dữ liệu phía đơn: đơn từ các marketplace channel như Shopee, Lazada, TikTok Shop và từ kênh social hoặc website, số điện thoại, địa chỉ, phương thức thanh toán, giá trị đơn, lịch sử đặt và nhận hàng của khách, điểm rủi ro và trạng thái xác nhận.
WMS giữ dữ liệu phía vật lý: SKU, barcode, bin location, trạng thái tồn khả dụng, tồn đã giữ cho đơn, tồn đang trên đường hoàn và kết quả kiểm khi kiện quay về. Hai hệ thống gặp nhau ở hai điểm: khi OMS quyết định đơn có được đẩy xuống wave picking hay không, và khi WMS ghi nhận kiện hoàn với lý do "từ chối nhận" để OMS cập nhật hồ sơ khách.
Xem thêm sản phẩm OMS + WMS, giải pháp marketplace đa kênh và giải pháp vận hành kho.
Bước 1: tính đúng một đơn bom tốn bao nhiêu
Nhiều shop chỉ nhìn phí hoàn của hãng vận chuyển nên đánh giá thấp bài toán. Chi phí thật của một đơn bom nên được tách như sau:
| Khoản chi phí | Ghi nhận ở đâu | Ghi chú |
|---|---|---|
| Phí giao chiều đi | Đối soát hãng vận chuyển | Thường vẫn bị tính dù khách không nhận |
| Phí hoàn chiều về | Đối soát hãng vận chuyển | Mức phí tùy hợp đồng và hãng |
| Vật tư đóng gói | Định mức vật tư theo loại kiện | Hộp, túi, băng keo, chèn thường không dùng lại được |
| Công picking, packing và nhận hoàn | Năng suất WMS theo thao tác | Một đơn bom tốn công hai lần mà không có doanh thu |
| Tồn bị khóa trên đường | Số ngày từ xuất kho tới nhận hoàn nhân với SKU | Có thể gây hết hàng giả và mất đơn khác trong campaign |
| Hàng hư hỏng khi hoàn | Kết quả kiểm nhận hoàn trong WMS | Móp hộp, bẩn, mất tem khiến hàng phải hạ loại |
Khi tổng các khoản này được tính theo từng đơn, owner sẽ thấy rõ một điểm rủi ro nên đặt ngưỡng ở đâu: gọi xác nhận một đơn tốn vài phút công CSKH, còn một đơn bom tốn cả phí vận chuyển hai chiều. Cách đối soát phí hoàn được trình bày trong bài đối soát COD, phí sàn và hàng hoàn.
Bước 2: chấm điểm rủi ro khi đơn vào OMS
Điểm rủi ro không cần mô hình phức tạp. Một bảng quy tắc cộng điểm, được hiệu chỉnh mỗi tháng bằng dữ liệu hoàn thực tế, đã đủ cho phần lớn shop.
| Tín hiệu | Cách nhận biết trong OMS | Mức ảnh hưởng gợi ý |
|---|---|---|
| Số điện thoại từng từ chối nhận | Lịch sử đơn hoàn có lý do từ chối nhận theo số điện thoại | Rất cao, thường đủ để vào luồng chờ xác nhận |
| Nhiều đơn cùng số điện thoại trên nhiều kênh | Gộp theo số điện thoại trong 24 đến 48 giờ | Cao, có thể là đặt nhiều nơi rồi chọn một |
| Địa chỉ thiếu phường xã hoặc quá ngắn | Kiểm tra độ đầy đủ của trường địa chỉ | Trung bình, đồng thời là rủi ro giao thất bại |
| Đặt nhiều size hoặc màu cùng một mẫu | Nhiều biến thể cùng mẫu trong một đơn | Trung bình, khách có thể nhận một và từ chối phần còn lại |
| Giá trị đơn cao bất thường so với tệp khách | So với giá trị đơn trung bình của kênh | Trung bình, ảnh hưởng thiệt hại nếu bom |
| Đơn từ bình luận livestream hoặc tin nhắn, không có tài khoản sàn | Kênh nguồn của đơn | Trung bình, tùy lịch sử kênh |
| Khách có nhiều đơn nhận thành công | Lịch sử giao thành công theo số điện thoại | Trừ điểm, ưu tiên đi thẳng |
Điểm quan trọng là dữ liệu phải gộp được giữa các kênh. Một số điện thoại bom trên Facebook rồi đặt tiếp trên website sẽ không bị phát hiện nếu mỗi kênh là một file riêng. Cách nhận diện cùng khách đặt nhiều kênh được trình bày trong bài kiểm soát đơn trùng khách đặt nhiều kênh. Hồ sơ rủi ro chỉ nên dùng cho mục đích vận hành, phân quyền xem hạn chế và tuân thủ quy định bảo vệ dữ liệu cá nhân hiện hành.
Bước 3: ba luồng xử lý theo mức rủi ro
- Rủi ro thấp, đi thẳng: đơn được giữ tồn và đẩy xuống wave picking như bình thường, không tốn công CSKH.
- Rủi ro trung bình hoặc cao, chờ xác nhận: OMS chuyển đơn sang trạng thái chờ xác nhận, giữ tồn nhưng không cho vào wave. CSKH gọi hoặc nhắn xác nhận theo hàng đợi sắp theo giờ cắt bàn giao. Xác nhận xong, đơn tự quay về luồng bình thường.
- Rủi ro rất cao: với đơn website hoặc social, có thể yêu cầu chuyển khoản trước, đặt cọc phí vận chuyển hoặc từ chối COD theo chính sách của shop. Với đơn sàn, chỉ gắn cảnh báo và ưu tiên xác nhận, vì quyền hủy của người bán bị ràng buộc bởi chính sách sàn.
Luồng chờ xác nhận bắt buộc có hạn chót. Nếu quá thời gian cấu hình mà không xác nhận được, OMS nhả tồn đã giữ để bán cho đơn khác và chuyển đơn sang trạng thái cần quyết định. Không có hạn chót, đơn chờ sẽ khóa tồn nhiều ngày và gây hết hàng giả, đặc biệt trong campaign. Nếu cần hủy sau khi hàng đã được lấy khỏi kệ, áp dụng quy trình trong bài xử lý đơn hủy sau khi đã picking.
Bước 4: nhận lại kiện bom và đóng vòng dữ liệu
- Quét mã vận đơn chiều về: WMS ghép đơn gốc, lấy SKU, số lượng và cân nặng đóng gói lúc xuất.
- Kiểm niêm phong và cân kiện: kiện bom thường chưa được mở; nếu băng keo hoặc tem bị cắt, hoặc cân nặng lệch, nâng lên kiểm đầy đủ.
- Nhận lại tồn: kiện nguyên vẹn được mở, quét barcode từng SKU và putaway về bin location, tồn khả dụng tăng và đồng bộ lên kênh bán ngay trong ngày.
- Ghi lý do hoàn có cấu trúc: từ chối nhận, không liên lạc được, sai địa chỉ, khách hẹn quá số lần. Không dùng một trạng thái "hoàn" chung.
- Cập nhật hồ sơ rủi ro: OMS cộng điểm cho số điện thoại và địa chỉ theo lý do hoàn, để đơn tiếp theo của khách này được chấm đúng.
Tách lý do hoàn là điểm hay bị bỏ qua nhất. Đơn giao thất bại vì hãng vận chuyển sai tuyến hoặc địa chỉ lỗi cần xử lý theo bài xử lý đơn giao thất bại và giao lại, không nên bị tính là khách bom. Nếu gộp chung, hệ thống sẽ phạt oan khách tốt và bỏ sót khách xấu.
Đo lường để biết giải pháp đang hiệu quả
| Chỉ số | Cách tính | Ý nghĩa |
|---|---|---|
| Tỷ lệ bom COD | Đơn hoàn do từ chối nhận hoặc không liên lạc được chia tổng đơn COD đã giao | Mức độ vấn đề theo kênh, phiên livestream, vùng giao |
| Tỷ lệ bom trong nhóm đã xác nhận | Đơn đã xác nhận nhưng vẫn bị bom chia tổng đơn đã xác nhận | Chất lượng cuộc gọi hoặc tin nhắn xác nhận |
| Tỷ lệ bom trong nhóm đi thẳng | Đơn rủi ro thấp bị bom chia tổng đơn rủi ro thấp | Quy tắc chấm điểm có bỏ lọt hay không |
| Thời gian đơn nằm chờ xác nhận | Từ lúc vào trạng thái chờ tới lúc xác nhận hoặc hết hạn | Luồng xác nhận có đang làm trễ SLA không |
| Số ngày kiện bom quay lại tồn khả dụng | Từ lúc hãng báo hoàn tới lúc putaway xong | Tồn bị khóa bao lâu |
| Chi phí bom trên mỗi đơn thành công | Tổng chi phí đơn bom chia số đơn giao thành công | Tác động thật lên biên lợi nhuận |
Nếu tỷ lệ bom trong nhóm đi thẳng cao, hãy chỉnh trọng số tín hiệu trước khi tăng số cuộc gọi. Nếu tỷ lệ bom trong nhóm đã xác nhận vẫn cao, vấn đề nằm ở cách xác nhận: cần xác nhận cả địa chỉ, thời gian nhận và tổng tiền phải trả, không chỉ hỏi "anh chị có đặt đơn không".
Checklist UAT trước khi áp dụng
- Tạo đơn COD từ một số điện thoại có lịch sử từ chối nhận; OMS phải gắn điểm rủi ro cao và chuyển sang chờ xác nhận.
- Tạo hai đơn cùng số điện thoại trên hai kênh trong cùng ngày; hệ thống phải nhận ra và cảnh báo.
- Xác nhận đơn chờ không xuất hiện trong wave picking cho tới khi được xác nhận.
- Để một đơn chờ quá hạn chót; tồn đã giữ phải được nhả và kênh bán nhận lại số tồn đúng.
- Nhận hoàn một kiện bom còn nguyên niêm phong; tồn khả dụng phải tăng và đồng bộ lên kênh trong ngày.
- Nhận hoàn một kiện có tem bị cắt hoặc lệch cân nặng; WMS phải chặn nhập tồn và yêu cầu kiểm đầy đủ.
- Ghi lý do hoàn "từ chối nhận" và "sai địa chỉ do hãng"; chỉ lý do đầu làm tăng điểm rủi ro của khách.
- Xuất báo cáo tỷ lệ bom theo kênh và theo phiên livestream cho một tuần thử nghiệm.
JST ERP Việt Nam có thể hỗ trợ như thế nào?
JST ERP Việt Nam có thể cùng doanh nghiệp rà soát dữ liệu đơn hoàn để tách đơn bom khỏi đơn giao thất bại, xác định tín hiệu rủi ro phù hợp với tệp khách và kênh bán, cấu hình trạng thái chờ xác nhận có hạn chót trong OMS, quy trình nhận lại kiện bom trong WMS và báo cáo chi phí bom hàng theo kênh, SKU và phiên livestream.
Mức độ hỗ trợ native cho quy tắc chấm rủi ro, danh sách khách cần chú ý, giữ và nhả tồn theo hạn chót, lý do hoàn có cấu trúc và báo cáo theo lý do phụ thuộc phiên bản và phạm vi triển khai. Tổng đài gọi xác nhận hoặc nhắn tin tự động thường là tích hợp bên thứ ba. Doanh nghiệp nên yêu cầu demo bằng chính dữ liệu một phiên livestream gần nhất và xác nhận rõ phần nào là native, phần nào là tích hợp, phần nào là quy trình thủ công. Bài nền cho cụm hàng hoàn là quản lý hàng hoàn về kho bằng WMS.
Liên hệ JST ERP Việt Nam để được tư vấn quy trình giảm bom hàng COD. Bạn cũng có thể xem phạm vi sản phẩm, quản lý marketplace đa kênh và giải pháp kho OMS + WMS trước buổi tư vấn.