Sáng T6 17/7 — Thứ Sáu D+2 mid-month, T-8 lương 25/7: 15 phút verify tracking cửa sổ 48h post-peak + shortlist đơn cần ticket sớm
Peak 15/7 đóng lúc 21h thứ Tư. Sáng T5 hôm qua đã chốt sổ + reconcile ledger, nhưng đó mới là mốc 24h post-peak — chưa đủ tin cậy để phân loại từng đơn. Sáng T6 hôm nay đúng mốc 48h post-peak, cửa sổ đầu tiên đủ độ tin cậy để phân đơn nào "HT24H đang batch chậm" (khoan ticket) vs "tracking dead" (cần ticket).
15 phút trước 8h30, chỉ shortlist — không mở ticket sáng T6. Batch cuối HT24H thường update 11h-12h; mở sớm quá dễ auto-close với reply "đơn đang xử lý, không cần khiếu nại". Trưa T6 12:00-13:00 mới là mốc mở ticket đúng — bài trưa T6 sẽ handle mở, sáng T6 chỉ chuẩn bị shortlist gọn.
Vì sao 15 phút sáng T6 chứ không phải sáng T5 hay chiều T5
48h post-peak là ngưỡng batch cadence HT24H đủ tin cậy để phân loại. Trước 48h, con số Pending còn dao động mạnh vì shop confirm rải rác 24-36h + HT24H batch update 2-3 lần/ngày; nhìn quá sớm dễ nhầm "chưa Pending" thành "tracking dead" khi thực ra là "đang trong batch tiếp theo".
Sáng T5 16/7 đã chốt sổ + reconcile 3 dòng ledger (canon Sáng T5 16/7 chốt sổ + reconcile ledger HT24H) — nhưng mới ở mốc 24h post-peak, chỉ đủ để note "cần verify thêm sáng T6". Chiều T5 hôm qua không dùng được vì đang trong ca làm, không có window quiet 15 phút. Sáng T7 18/7 lại quá xa — cửa sổ khiếu nại HT24H bám T-14 mốc 29/7 (đã set từ sáng T5), càng shortlist sớm càng tránh mất buffer verify cuối tuần.
Sáng T6 window quiet trước 8h30, HT24H đã có ít nhất 3 batch update kể từ peak 21h thứ Tư — batch tối 15/7, batch sáng 16/7, batch tối 16/7. Dry-run tracking từ sáng T3 14/7 (canon Sáng T3 14/7 T-1 mid-month refresh ledger HT24H + dry-run checkout SKU nhỏ test tracking) đã xác nhận nhịp batch 2-3 lần/ngày là stable. Đủ nền để so — chưa cần vội mở ticket.
Bài này khác chuỗi post-7-7: Sáng T6 10/7 D+3 sau 7-7 audit HT24H 3 red flag là D+3 sau mega-sale 7-7, cường độ đơn gấp 3-5 lần bình thường + red flag hàng loạt, kịch bản "audit và hành động ngay". Sáng T6 mid-month D+2 hôm nay ở cường độ trung bình — đơn ít hơn 7-7, có 15/7 peak vừa qua nên đủ để cần verify, nhưng buffer batch cadence cho phép "shortlist trước, ticket sau". Khác window (D+2 vs D+3), khác cường độ, khác kịch bản mở ticket.
Việc 1 — Pull danh sách đơn 15/7 đã "Đang giao" trên 3 sàn (7 phút)
Mở Shopee → Lazada → TikTok Shop. Từng sàn, filter đơn ngày 15/7 (peak 0h + slot 21h). Tick 3 trạng thái ship:
- Đã giao (D+2 shop mall giao nhanh): ghi mã đơn + timestamp shop confirm. Nhóm này ưu tiên verify vì cửa sổ refund shop đã bắt đầu đếm.
- Đang giao (D+2 shop batch thường): ghi mã đơn — chưa cần khiếu nại tracking, chuẩn bị để sáng T7 hoặc reminder T2 20/7 audit D+5 (đã set từ trưa T5) verify tiếp.
- Chờ vận chuyển sau 48h (bất thường): mã đơn + sàn — cross-check ở Việc 2, đây thường là dấu hiệu shop out-of-stock ngầm sau slot 21h; có thể liên quan tới tracking miss.
Match từng mã đơn với note "cần khiếu nại" đã lập sáng T5 hôm qua. Nếu mã đơn đã đánh dấu sáng T5 → giữ ưu tiên cao cho Việc 3. Nếu mã đơn mới xuất hiện dạng bất thường sáng T6 → thêm vào note với tag "phát hiện T6".
Chỉ tiêu Việc 1: 1 danh sách phẳng đơn 15/7 với 3 trạng thái ship + tag rõ đơn nào cần verify tracking HT24H ở Việc 2. Không phân tích sâu — chỉ inventory.
Việc 2 — Cross-check HT24H Lịch sử giao dịch: 3 trạng thái Pending (5 phút)
Mở HT24H → Lịch sử giao dịch (không phải tab Ví). Từng mã đơn trong danh sách Việc 1, so 3 trạng thái Pending:
- (a) Vừa hiện đúng số: mã đơn có bản ghi Pending, số cashback trong dải kỳ vọng theo ngành (Beauty 10-18%, Fashion 8-15%, Food 5-12%, Electronics 3-8% — dải theo ngành trên Shopee, không cam kết cứng SKU). Batch chạy đúng — không cần ticket. Đánh dấu OK.
- (b) Trống bản ghi: mã đơn không có bản ghi Pending trên HT24H sau 48h. Đây là dấu hiệu tracking miss có xác suất cao — nhưng CHƯA chắc chắn. Nếu shop mall + đơn D+2 thì batch cuối HT24H có thể vẫn còn 1-2 tiếng nữa mới update. Đánh dấu "chờ ticket trưa T6" — không mở ticket sáng T6.
- (c) Hiện nhưng số cashback lệch kỳ vọng >5%: mã đơn Pending đúng nhưng số VND < hoặc > dải theo ngành >5%. Đây thường là booster campaign kết thúc trước lúc checkout — không phải bug HT24H, không mở được ticket thắng. Đánh dấu "lệch nhưng OK", không thêm ticket.
Ghi 3 nhóm (a/b/c) vào note với đếm số đơn từng nhóm. Nhóm (b) là input chính cho Việc 3.
Việc 3 — Build shortlist "cần ticket trưa T6" (3 phút)
Từ nhóm (b) Việc 2, build shortlist với 5 field mỗi đơn:
- Timestamp checkout tối 15/7 (từ email/SMS xác nhận đơn)
- Shop + tên gian hàng
- Sàn (Shopee / Lazada / TikTok Shop)
- Số VND checkout
- Reference T-14 = 29/7 — mốc cuối cùng mở ticket khiếu nại HT24H trước khi cửa sổ đóng (đã set từ sáng T5)
Shortlist này không mở ticket sáng T6. Chỉ ghi vào note "shortlist trưa T6" với timestamp shortlist = sáng T6 8h30. Trưa T6 12:00-13:00 là window mở ticket đúng — bài trưa T6 handle.
Nếu shortlist chỉ có 0-1 đơn nhóm (b): batch HT24H mid-month chạy ổn, không cần ticket. Nếu shortlist ≥ 3 đơn nhóm (b): có thể tracking dead diện rộng — flag note "verify batch 11h-12h trưa nay trước khi mở ticket, có thể self-heal".
Vì sao không mở ticket sáng T6
Batch cuối HT24H thường update 11h-12h VN (canon từ chuỗi audit tuần trước). Mở ticket sáng T6 8h30 = có nguy cơ đơn tự vào Pending vào batch 11h-12h, ticket bị auto-close với reply "đơn đang xử lý, không cần khiếu nại". Auto-close sớm = phải mở lại ticket lần 2, mất thêm buffer T-14 khiếu nại tới 29/7.
Trưa T6 12:00-13:00 mở ticket đúng vì (1) batch cuối 11h-12h đã chạy, kết quả rõ ràng; (2) HT24H support ca trưa nhận ticket kịp; (3) còn đủ T-12 buffer tới 29/7 để chờ reply mà không sát deadline. Bài trưa T6 sẽ handle: nếu shortlist ≥ 1 đơn nhóm (b) sau batch 12h → mở ticket; nếu batch 12h self-heal hết → close note, không mở.
Sáng T6 chỉ shortlist, không mở. Đây là kỷ luật "quiet Friday morning" hậu peak.
Chốt — trước 8h30 sáng T6
3 output phải có: (1) danh sách phẳng đơn 15/7 với 3 trạng thái ship + tag verify, (2) 3 nhóm (a)/(b)/(c) từ HT24H Lịch sử giao dịch với số đếm rõ, (3) shortlist "cần ticket trưa T6" với 5 field và reference T-14 = 29/7. Chụp màn hình HT24H Lịch sử giao dịch làm baseline trước khi đóng app — để trưa T6 so lại nếu batch 11h-12h thay đổi con số nhóm (b).
Chuỗi canon mid-month 15-20/7: sáng T5 chốt sổ + reconcile ledger → trưa T5 split 3 rổ 15 ngày cuối tháng → sáng T6 verify tracking 48h + shortlist ticket (bài này) → trưa T6 mở ticket đúng batch cuối HT24H → sáng T2 20/7 audit D+5. Sáng T6 là "cửa sổ tin cậy đầu tiên" — shortlist gọn, không hoảng, không mở ticket sớm.