Tóm tắt nhanh
Đơn bị hủy sau khi kiện đã bàn giao cho hãng vận chuyển không thể xử lý như đơn hủy trước đóng gói. Nếu đội chăm sóc khách hàng chỉ “đồng ý hủy” trên chat mà không có trạng thái riêng, yêu cầu chặn giao và quy trình nhận hàng hoàn, shop vừa mất phí hai chiều, vừa có tồn ảo và kiện hoàn không ai đối chiếu.
- Tạo trạng thái riêng “yêu cầu hủy khi đang vận chuyển”, không chuyển thẳng sang hủy và không cộng lại tồn khả dụng.
- Phân luồng theo kênh: đơn sàn theo chính sách hủy/từ chối nhận của sàn; đơn fanpage, website, Zalo thì shop chủ động yêu cầu hãng chặn giao.
- Gửi yêu cầu chặn giao theo mã vận đơn trong cùng ca, ghi người gửi, thời gian và phản hồi của hãng.
- Theo dõi kiện ở trạng thái “đang hoàn”, có hạn chót về kho theo hãng; quá hạn thì mở hồ sơ thất lạc.
- Nhận kiện hoàn bằng quét mã vận đơn, kiểm SKU, số lượng, niêm phong; chỉ hàng đạt mới cộng lại tồn.
- Đo tỷ lệ chặn thành công, số ngày hoàn về và chi phí hủy sau bàn giao theo kênh và lý do.
Khi nào doanh nghiệp nên dùng giải pháp này?
Owner cần giải pháp khi báo cáo phí vận chuyển có một khoản “hoàn không giao” tăng dần mà không biết từ kênh nào, lý do gì. Operations manager cần khi đơn fanpage, livestream và Zalo chiếm tỷ trọng lớn, khách đổi ý nhiều, và mỗi người chăm sóc khách hàng xử lý hủy một kiểu.
Warehouse manager cần khi kho nhận kiện hoàn mà không biết đây là đơn khách hủy chủ động, đơn giao thất bại hay hàng bị đánh tráo, và tồn trên OMS lệch so với kệ sau mỗi đợt hoàn. Đội ecommerce cần khi sàn vẫn bán tiếp những sản phẩm đang nằm trên xe của hãng vì hệ thống đã “cộng lại tồn” quá sớm.
Giải pháp phù hợp nhất với shop có từ vài chục đơn hủy sau bàn giao mỗi tuần, bán nhiều qua kênh riêng có COD, hoặc dùng nhiều hãng vận chuyển với chính sách hoàn khác nhau.
So sánh nhanh theo mức độ vận hành: các cách xử lý đơn hủy sau bàn giao
| Cách làm | Điểm mạnh | Rủi ro chính | Phù hợp với |
|---|---|---|---|
| Đồng ý hủy trên chat, chờ khách từ chối nhận | Không tốn thao tác | Kiện vẫn đi hết tuyến, phí hai chiều, không ai theo dõi kiện hoàn | Vài đơn mỗi tháng |
| Chuyển đơn sang hủy trong OMS ngay | Báo cáo đơn “sạch” nhanh | Tồn được cộng lại khi hàng chưa về kho, bán vượt trên sàn | Không khuyến nghị |
| Gọi hãng chặn giao, ghi chú trong Excel | Giảm được một phần phí | Không liên kết với đơn, không đo được tỷ lệ chặn, dễ sót khi đổi ca | Một hãng, ít đơn |
| OMS + WMS: trạng thái hủy khi đang vận chuyển, yêu cầu chặn theo mã vận đơn, theo dõi kiện hoàn và nhận kiểm trước khi cộng tồn | Tồn không ảo, biết kiện nào đang hoàn, đo được chi phí theo kênh và lý do | Cần kỷ luật ghi lý do và mốc gửi hãng | Nhiều kênh, nhiều hãng, hủy hằng ngày |
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. OMS tổng hợp đơn từ marketplace channel như Shopee, Lazada, TikTok Shop, livestream và kênh riêng (website, fanpage, Zalo), quản lý trạng thái đơn, mã vận đơn và tồn khả dụng đồng bộ lên sàn. WMS quản lý thực thi trong kho: picking, checking, đóng gói, quét bàn giao theo hãng và nhận hàng hoàn vào bin location.
Đơn hủy sau bàn giao nằm giữa ba bên: khách và kênh bán quyết định hủy, hãng vận chuyển giữ kiện, kho nhận lại hàng. OMS giữ trạng thái và lý do, WMS xác nhận hàng thật đã về và đạt kiểm. Nếu mắt xích nào tự đóng đơn trước, tồn và đối soát sẽ lệch.
Xem thêm xử lý đơn hủy sau picking (putback), kiểm soát bàn giao vận chuyển, giảm đơn bom hàng COD, phát hiện hàng hoàn bị đánh tráo, sản phẩm OMS + WMS và giải pháp vận hành kho.
Đơn hủy ở từng giai đoạn cần xử lý khác nhau
| Thời điểm khách hủy | Hàng đang ở đâu | Xử lý trên OMS | Xử lý trong kho |
|---|---|---|---|
| Trước khi phát lệnh lấy hàng | Trên kệ | Hủy, nhả giữ tồn ngay | Không cần thao tác |
| Sau picking, trước đóng gói | Trong tote hoặc bàn checking | Hủy, tạo lệnh putback | Trả hàng về đúng bin location, quét xác nhận |
| Đã đóng gói, chưa bàn giao | Khu chờ bàn giao | Hủy, hủy vận đơn với hãng | Rút kiện khỏi khu bàn giao, mở kiện, putback |
| Đã bàn giao, kiện đang trên tuyến | Trong tay hãng | Yêu cầu hủy khi đang vận chuyển, tồn chưa cộng lại | Chờ kiện hoàn, chưa có thao tác |
| Đã giao cho khách | Khách đang giữ | Chuyển sang luồng trả hàng/hoàn tiền | Nhận hàng trả theo luồng hàng hoàn |
Quy trình xử lý đơn hủy sau khi đã bàn giao
1. Tiếp nhận và phân loại yêu cầu hủy
Người chăm sóc khách hàng mở yêu cầu trên OMS, chọn lý do chuẩn: đặt nhầm biến thể, đổi ý, giao lâu, trùng đơn, tìm giá rẻ hơn. Với lỗi đặt nhầm size hoặc màu, đề xuất đổi hàng sau khi nhận có thể rẻ hơn hủy và hoàn. Không dùng ô ghi chú tự do làm lý do chính, vì sẽ không thống kê được.
2. Phân luồng theo kênh và chính sách
Đơn Shopee, Lazada, TikTok Shop đi theo luồng hủy hoặc từ chối nhận mà sàn cho phép ở thời điểm đó; người bán không tự sửa trạng thái trên sàn. Đơn website, fanpage, Zalo, livestream ngoài sàn do shop chủ động: kiểm tra đã thu tiền trước hay COD, và có nên chặn giao hay không dựa trên giá trị đơn và phí hoàn.
3. Gửi yêu cầu chặn giao theo mã vận đơn
Yêu cầu được gửi cho hãng theo mã vận đơn, qua API nếu dự án có kết nối, hoặc qua cổng của hãng. OMS lưu thời gian gửi, người gửi, mã phiếu yêu cầu và phản hồi. Ca tối có một người chịu trách nhiệm gom và gửi toàn bộ yêu cầu trong khung giờ đã chốt, để không còn yêu cầu nằm trên chat đến sáng hôm sau.
4. Giữ tồn ở trạng thái “đang hoàn”
Số lượng của đơn không quay về tồn khả dụng, mà nằm ở trạng thái đang hoàn, gắn với SKU, đơn gốc và hãng. Báo cáo tồn cho owner hiển thị riêng số này để biết bao nhiêu hàng đang trên đường về và không bị sàn bán tiếp.
5. Theo dõi hạn chót kiện hoàn
Mỗi hãng có thời gian hoàn tham chiếu, ví dụ 3–7 ngày nội tỉnh hoặc lâu hơn liên tỉnh. Kiện quá hạn chưa về chuyển sang danh sách cảnh báo, sau đó mở hồ sơ thất lạc hoặc bồi thường với hãng kèm chuỗi bằng chứng chiều đi.
6. Nhận và kiểm kiện hoàn tại kho
Nhân viên nhận hoàn quét mã vận đơn; WMS hiển thị đơn gốc, danh sách SKU và lý do hủy. Kiểm niêm phong, quét từng barcode, đếm số lượng, phân loại: nguyên vẹn, cần đóng gói lại, lỗi hoặc sai hàng. Kiện có dấu hiệu bị mở hoặc thiếu hàng được cách ly và mở hồ sơ với hãng.
7. Cất hàng và đóng đơn
Hàng đạt kiểm được cất vào bin location bằng quét vị trí, lúc này tồn mới chuyển sang khả dụng và đồng bộ lên sàn. Đơn chuyển sang trạng thái hủy hoàn tất, ghi phí chiều đi, phí hoàn và kết quả kiểm để đội kế toán đối soát COD và phí vận chuyển.
Chỉ số nên theo dõi hằng tuần
| Chỉ số | Cách tính | Ý nghĩa |
|---|---|---|
| Tỷ lệ hủy sau bàn giao | Đơn hủy sau bàn giao ÷ đơn đã bàn giao, theo kênh | Kênh nào khách đổi ý nhiều, cần xác nhận đơn kỹ hơn |
| Thời gian từ yêu cầu đến gửi hãng | Giờ gửi yêu cầu chặn − giờ khách báo hủy | Đo kỷ luật ca chăm sóc khách hàng |
| Tỷ lệ chặn thành công | Kiện được hoàn trước khi phát ÷ yêu cầu chặn đã gửi, theo hãng | So sánh hãng và mốc gửi hiệu quả |
| Số ngày hoàn về kho | Ngày nhận kiện hoàn − ngày gửi yêu cầu | Ước lượng tồn bị “treo” trên đường |
| Kiện quá hạn chưa về | Số kiện đang hoàn vượt hạn chót của hãng | Danh sách mở hồ sơ thất lạc |
| Chi phí hủy sau bàn giao | Phí đi + phí hoàn + hàng hỏng, theo kênh và lý do | Căn cứ điều chỉnh chính sách xác nhận đơn và COD |
Checklist UAT trước khi áp dụng
- Bàn giao 20 kiện, sau đó tạo 3 yêu cầu hủy; 3 đơn chuyển sang “yêu cầu hủy khi đang vận chuyển”, không sang hủy.
- Tồn khả dụng của các SKU liên quan không tăng; báo cáo hiển thị đúng số lượng ở trạng thái đang hoàn.
- Đơn sàn và đơn fanpage đi đúng hai luồng khác nhau; đơn sàn không bị sửa trạng thái ngoài chính sách sàn.
- Mỗi yêu cầu chặn có mã vận đơn, người gửi, thời gian và phản hồi của hãng.
- Một kiện quá hạn chót xuất hiện trong danh sách cảnh báo thất lạc.
- Quét mã vận đơn kiện hoàn hiển thị đúng đơn gốc; một SKU thiếu được đưa vào khu cách ly, không cộng tồn.
- Sau khi cất hàng đạt kiểm vào bin location, tồn khả dụng tăng đúng số lượng và đồng bộ lên sàn.
JST ERP Việt Nam có thể hỗ trợ như thế nào?
JST ERP Việt Nam có thể cùng đội chăm sóc khách hàng, ecommerce và kho rà lại số đơn hủy sau bàn giao trong một tháng gần nhất, chuẩn hóa lý do hủy, thiết kế trạng thái đơn và trạng thái tồn đang hoàn, quy trình gửi yêu cầu chặn giao theo hãng và quy trình nhận kiểm kiện hoàn trên OMS + WMS. Buổi tư vấn hiệu quả nhất khi có danh sách đơn hủy sau bàn giao, hãng vận chuyển và phí hoàn tương ứng.
Mức độ hỗ trợ cho yêu cầu chặn giao qua API, trạng thái đơn tùy biến và theo dõi kiện hoàn phụ thuộc phiên bản, cấu hình, phạm vi triển khai và kết nối với từng sàn, từng hãng. Doanh nghiệp nên xác nhận trong demo phần nào có sẵn và phần nào cần quy trình thủ công bổ sung.
Liên hệ JST ERP Việt Nam để được tư vấn. Bạn cũng có thể xem phạm vi sản phẩm, quản lý marketplace đa kênh, giải pháp kho OMS + WMS và bài đối soát bồi thường vận chuyển.