Tỷ lệ hủy đơn TikTok Shop chỉ có ích khi được tách thành ba lớp: ai khởi tạo hủy (người mua, người bán hay hệ thống), hủy lúc nào (trước hay sau khi gửi hàng), và lý do gì. Riêng lý do "Giao gói hàng thất bại" phải tách ra thành chỉ số riêng. Mỗi lớp trỏ tới một bộ phận khác nhau.
Bài toán: vì sao một con số hủy gộp dễ làm họp sai hướng?
Vì con số gộp trộn những đơn có nguyên nhân hoàn toàn khác nhau. Khách đổi ý sau năm phút, kho không kịp gửi hàng, và đơn vị vận chuyển không giao được đều có thể nằm chung trong cột "đã hủy".
Khi chỉ thấy tỷ lệ hủy tăng, người quản lý thường hỏi đội chăm sóc khách trước. Nhưng nếu phần tăng nằm ở đơn hệ thống tự hủy vì quá hạn gửi hàng, đó là việc của kho. Nếu nằm ở đơn giao thất bại, đó là việc của khâu xác nhận đơn và vận chuyển. Giao việc khi chưa tách số là giao cho người không sửa được.
Mẹo nhỏ đầu tiên: đọc tài liệu của TikTok Shop về cách sàn tính chỉ số hủy do lỗi người bán ngay trong Trung tâm nhà bán hàng. Ngưỡng và cách tính có thể thay đổi theo thời kỳ, nên lấy số ở đó làm chuẩn, không lấy số truyền miệng.
Lớp 1: ai khởi tạo lệnh hủy?
Dữ liệu đơn TikTok Shop có sẵn câu trả lời. Mỗi đơn đã hủy mang trường cancellation_initiator với ba giá trị: BUYER, SELLER, SYSTEM. Ở mức dòng hàng còn có cancel_user, thêm giá trị OPERATOR cho trường hợp sàn can thiệp.
| Người khởi tạo | Thường xảy ra khi | Bộ phận cần xem |
|---|---|---|
| Người mua | Đổi ý, đặt nhầm mẫu, tìm được giá rẻ hơn, chờ lâu | Nội dung, giá, tốc độ xử lý đơn |
| Người bán | Hết hàng, niêm yết sai giá, sai tồn | Mua hàng, kho, người quản lý gian hàng |
| Hệ thống | Quá hạn gửi hàng, quá hạn lấy hàng, quá hạn giao | Kho vận, đơn vị vận chuyển |
Hai trường đáng chú ý khác là is_buyer_request_cancel và request_cancel_time. Chúng cho biết người mua đã xin hủy và xin lúc nào. Một đơn khách xin hủy nhưng shop chậm duyệt cũng là tín hiệu về tốc độ phản hồi, không riêng về sản phẩm.
Cả hai cách đọc đơn đều đi qua API chi tiết đơn TikTok Shop hoặc API tìm đơn theo khoảng thời gian.
Lớp 2: đơn bị hủy trước hay sau khi gửi hàng?
Thời điểm hủy cho biết đơn rơi ở khâu nào. So cancel_time với các mốc của đơn: rts_time (người bán xác nhận gửi), collection_time (đơn vị vận chuyển lấy hàng), delivery_time (giao thành công).
Hủy khi đơn còn ở trạng thái UNPAID hoặc ON_HOLD gần như luôn là quyết định của khách. Ở ON_HOLD người mua vẫn được quyền hủy, nên phần này khó tránh hoàn toàn. Hủy ở AWAITING_SHIPMENT là vùng nguy hiểm nhất: hàng đã được giữ, đội kho có thể đã đóng gói, và nếu người bán hủy vì hết hàng thì shop vừa mất đơn vừa có thể bị tính vào chỉ số hủy do lỗi người bán.
TikTok Shop cũng ghi rõ các hạn chót tự hủy: shipping_due_time, collection_due_time, delivery_due_time. Quá hạn mà đơn chưa sang trạng thái kế tiếp thì sàn tự hủy. Nghĩa là phần lớn đơn hệ thống hủy có thể nhìn thấy trước, nếu theo dõi khoảng cách tới hạn chót thay vì chờ đơn đã mất.
Ví dụ minh họa: kỳ có 1.000 đơn, 80 đơn hủy. Trong đó 50 đơn người mua hủy trước khi gửi, 18 đơn hệ thống hủy vì quá hạn gửi, 12 đơn người bán hủy vì hết hàng. Tỷ lệ hủy gộp 8% nghe như chuyện khách. Thực ra 30 trên 80 đơn là chuyện kho và tồn.
Lớp 3: vì sao "Giao gói hàng thất bại" phải đứng riêng?
Vì đó không phải hủy theo nghĩa thông thường. Khách chưa nhận hàng, hàng đã đi đường và quay về. TikTok Shop ghi loại đơn này là đơn hủy do hệ thống, lý do "Giao gói hàng thất bại".
Gộp vào tỷ lệ hủy sẽ gây hai sai lệch. Tỷ lệ hủy bị thổi lên bởi một nguyên nhân thuộc khâu giao. Còn tỷ lệ giao thất bại thì bị giấu đi, trong khi đây là loại tốn tiền nhất: phí vận chuyển đã phát sinh, hàng nằm đường nhiều ngày. Bài phân biệt đơn hoàn và giao thất bại giải thích vì sao mỗi kênh ghi nhận loại đơn này khác nhau.
Quy ước nên chốt một lần: tỷ lệ hủy tính trên đơn hủy trừ nhóm giao thất bại; tỷ lệ giao thất bại tính trên đơn đã gửi đi. Trên dashboard của Quantri360, "Giao hàng thất bại" là chỉ số riêng ở trang kênh TikTok và không lẫn vào đơn hoàn, theo bảng mỗi số liệu tính trên loại đơn nào.
Tư duy dẫn đường, máy làm phần đếm lặp lại
Phần tư duy là chọn cách chia và định nghĩa mẫu số. Phần còn lại là đếm mỗi ngày theo đúng cách chia đó, việc máy làm nhanh và không mệt.
Cách làm thực tế: đơn được kéo thẳng từ sàn, không đi qua bảng tính của người báo cáo. Trang phân tích đơn hủy cho tỷ lệ hủy theo kênh, lý do hủy phổ biến và thời gian trung bình từ đặt đến hủy. Cảnh báo hoàn hủy báo ngay khi có đơn mới chuyển sang hủy, xem công cụ cảnh báo. Nếu muốn tự dựng bảng chia theo người khởi tạo, có thể kéo đơn qua API Partner vào Google Sheets rồi lọc theo cancellation_initiator.
AI giúp ở bước gom lý do. Lý do hủy và tin nhắn khách thường viết tự do, đọc từng dòng rất mất thời gian. Khi dữ liệu đã tách sẵn theo người khởi tạo, AI sẽ gom được nhóm có ý nghĩa thay vì một danh sách lộn xộn. Cách làm tương tự với lý do hoàn ở bài dùng AI gom lý do hoàn hàng.
Kết quả nào cần đo sau khi tách?
Đo riêng từng nhóm, mỗi nhóm có một người chịu trách nhiệm. Không đo lại tỷ lệ hủy tổng để đánh giá việc sửa.
| Chỉ số | Mẫu số | Người theo dõi |
|---|---|---|
| Hủy do người bán | Tổng đơn trong kỳ | Mua hàng, quản lý gian hàng |
| Hủy do hệ thống vì quá hạn | Tổng đơn trong kỳ | Kho vận |
| Hủy do người mua trước khi gửi | Tổng đơn trong kỳ | Nội dung, giá, chăm sóc khách |
| Giao thất bại | Đơn đã gửi đi | Xác nhận đơn, vận chuyển |
Theo dõi theo tuần và theo mã sản phẩm. Một mã có nhiều đơn người bán hủy là dấu hiệu tồn trên sàn lệch với tồn thật, xem thêm bài tồn kho đa kênh bị lệch. Một khung giờ có nhiều đơn hệ thống hủy là dấu hiệu ca đóng gói thiếu người.
Đọc thêm: quản trị bằng số liệu · thương mại điện tử đa kênh — bài tổng quan của chủ đề này.
Tóm lại
- Tách đơn hủy theo người khởi tạo: người mua, người bán, hệ thống.
- So thời điểm hủy với các mốc gửi, lấy, giao để biết đơn rơi ở khâu nào.
- Đưa "Giao gói hàng thất bại" ra thành chỉ số riêng, tính trên đơn đã gửi.
- Theo dõi khoảng cách tới hạn chót tự hủy để cứu đơn trước khi mất.
- Giao mỗi chỉ số cho đúng một bộ phận; nếu doanh thu đang giảm, đọc thêm năm câu hỏi tách nguyên nhân.
