Sáng T4 22/7 — Thứ Tư D+7 mid-month, T-3 lương 25/7: 20 phút phân 3 outcome ticket lần 2 (48h post) và decision path T-11 khiếu nại 29/7

Sáng T2 20/7 đã mở ticket lần 2 cho các case dead-air 60+h (canon Sáng T2 20/7 audit D+5 + ticket lần 2). Trưa T2 pin xong 3 SKU rổ 8-8 với 3 gate cứng. Ca sáng T2, sáng T3 đi làm, ticket lần 2 chờ ở đó. Sáng T4 22/7 hôm nay là phân 3 outcome + decision path — bài chuyên biệt cho việc chuyển từ "đã mở ticket lần 2" sang "đã có 48h data, quyết đơn nào chờ được đến T-11 = 29/7 khiếu nại chính thức, đơn nào giải quyết xong".

20 phút trước 8h30 — không mở app sàn, không refresh voucher, không action mua. Kỷ luật T4 giữa tuần chưa lương (T-3 lương 25/7, T-17 tới 8-8): audit continuation, phân outcome, ghi decision path. Dry-powder 10% vẫn double-lock đến T-14 25/7 payday (canon Trưa CN 19/7 double-lock dry-powder).

Vì sao 20 phút sáng T4 chứ không tối T4 hoặc dời sáng T5 23/7

Sáng T4 = window quiet trước 8h30, đầu tỉnh, đã có 48h data từ ticket lần 2 mở sáng T2 20/7 — vừa đủ để shop có cơ hội reply và HT24H clarify, chưa dài đến mức bỏ lỡ mốc T-11 29/7. Ba lựa chọn thay thế đều xấu hơn:

• Tối T4 về nhà sau ca làm, đầu không đủ tỉnh để phân outcome — dễ đọc nhầm timestamp reply, đưa ticket "chờ shop close" vào nhóm dead-air, hoặc mark nhầm ticket đã resolve. Ba loại nhầm này chỉ xảy ra khi phân dạng liệt kê lúc mệt.
• Sáng T5 23/7 quá gần T-4 lương (T5 24/7 D+8), buffer thu hẹp. Nếu sáng T4 không phân xong, sáng T5 lại chồng thêm "reset ledger pre-payday" — 2 việc đè lên nhau, mất kỷ luật 1 việc/1 slot.
• Dời cuối tuần T7-CN 25-26/7 = quá sát mốc T-11 29/7 (chỉ còn 3-4 ngày). Nếu ticket outcome (c) — cần thêm 1 vòng verify sáng T4 29/7 trước khi khiếu nại — không còn buffer.

Sáng T4 22/7 giữ nguyên slot 20 phút trước 8h30. Không mở tab Home 3 sàn. Không mở tab voucher. Chỉ mở weekly note CN 19/7 + list ticket lần 2 từ sáng T2 20/7.

Việc 1 — Reopen weekly note CN 19/7 + list ticket lần 2 đã mở sáng T2 (3 phút)

Mở weekly note CN 19/7 (canon từ Sáng CN 19/7 weekly note 5 dòng). Cuộn xuống phần cập nhật sáng T2 20/7 — dòng "T2 20/7 audit D+5 done — verify status ticket sáng T3 21/7" đã canon từ bài sáng T2.

Vì sáng T3 21/7 không mở ca verify riêng (chuỗi arc chuyển thẳng sang T4), sáng T4 22/7 là mốc verify đầu tiên — data đã tích luỹ 48h thay vì 24h theo dự kiến ban đầu. Đọc list mã ticket lần 2 đã mở sáng T2, note lại 3 field cho mỗi ticket:

• Mã ticket / mã đơn hoàn tiền.
• Timestamp mở ticket lần 2 (từ note sáng T2).
• Sàn (Shopee / Lazada / Tiki / TikTok Shop) — vì HT24H có 4 sàn và nhịp reply support khác nhau, không SLA numeric đơn nhất (canon giữ nguyên phrasing trung lập từ sáng T2 20/7).

Rank theo thời điểm mở lần 2 — ticket mở đầu slot sáng T2 (VD 08:05) có gap 48h+ nhiều hơn ticket mở cuối slot (VD 08:22). Ưu tiên phân trước cho ticket có gap dài nhất vì cơ hội shop reply đã trôi qua nhiều nhất.

Việc 2 — Phân 3 outcome cho từng ticket 48h post (10 phút)

Đây là core của slot. Mở app HT24H → Support → Ticket của tôi (canon phrasing chuỗi từ 17/7 trở đi). Với mỗi ticket lần 2 trong list Việc 1, check trạng thái reply và phân đúng 1 trong 3 outcome — không phân đôi, không "chờ thêm 1 ngày":

Outcome (a) — Shop replied trong 48h. Có reply từ shop (dù chỉ là "đang kiểm tra kho" hoặc "sẽ phản hồi cụ thể trong X ngày"). Track resolution status: đọc kỹ nội dung reply, phân tiếp thành 2 sub-note:

• Reply thực chất (đã xác nhận nguyên nhân + cam kết action + ETA): note "chờ shop close — verify lại sáng CN 26/7 nếu chưa done".
• Reply hình thức ("đang xử lý" không kèm gì cụ thể): note "cần push — sáng CN 26/7 mở ticket update phản hồi shop, không phải lần 3".

Ghi trực tiếp cạnh dòng ticket trong weekly note. Không mark resolve trên app cho đến khi shop close hoặc HT24H confirm — resolve sớm = mất bằng chứng cho khiếu nại T-11 nếu phải escalate lại.

Outcome (b) — HT24H replied clarifying. Không có reply từ shop nhưng HT24H đã phản hồi (thường request thêm thông tin: screenshot đơn hàng, mã vận đơn, số dư hiện tại app). Verify status trên app cho đúng ticket, note "action HT24H yêu cầu: [nội dung cụ thể], deadline reply [ngày]". Nếu HT24H yêu cầu attach screenshot mới, chuẩn bị attach ở slot khác (không phải sáng T4 20 phút này — chỉ note action, không đính kèm).

Outcome (c) — Cả 2 dead-air. Không reply từ shop, không reply từ HT24H sau 48h post-lần-2. Đây là nhóm cần focus nhất: mark "candidate escalate T-11 = 29/7 khiếu nại chính thức" trong weekly note, kèm 3 field:

• Tổng thời gian dead-air từ ticket lần 1 (từ note sáng T2 = "dead-air 60+h") + 48h lần 2 = 108+h tổng.
• Số tiền cashback treo (từ ledger nguồn 3, không phải dry-powder — canon Trưa CN 19/7 tách 3 nguồn quỹ).
• Shop nhóm (a/b/c) — canon phrasing "không integrate ổn hoặc bỏ qua tracking" cho nhóm (c), không dùng "gian lận" (canon Sáng T2 20/7). Ticket outcome (c) mà shop thuộc nhóm (c) = nguy cơ tracking miss cao, khiếu nại T-11 là đường đi rõ ràng nhất.

Không dùng phrasing "vượt SLA HT24H" hoặc "SLA cấp 2" — HT24H có 4 sàn (Shopee + Lazada + Tiki + TikTok Shop) và mỗi sàn có nhịp reply support khác nhau, không có SLA numeric đơn nhất áp cho toàn bộ. Giữ note trung lập, chỉ ghi con số thời gian thực (108+h) và số dư treo, không cảm xúc.

Việc 3 — Note checkpoint 29/7 + tag verify tiếp (5 phút)

Từ list Việc 2, đếm số ticket outcome (c). Nếu > 0, note vào weekly note dòng riêng:

"Sáng T4 29/7 08:00 — verify status lần cuối các ticket outcome (c) trước khi khiếu nại chính thức T-11. Nếu vẫn dead-air, mở đơn khiếu nại chính thức qua HT24H → Support → Khiếu nại (đường riêng, không phải Ticket của tôi). Không claim T-11 = 29/7 là 'deadline pháp lý' — đây là mốc canon chuỗi để timely thương lượng shop trước khi chuyển kênh chính thức (canon Trưa T5 16/7 3 mốc post-peak)."

Quan trọng: KHÔNG plan mở ticket lần 3 sáng T5 23/7. Ba lý do cứng:

• Gap 48h giữa lần 2 và lần 3 quá ngắn. Shop cần thời gian check kho, xác nhận nội bộ — chỉ 1 ngày sau lần 2 là chưa cho shop cơ hội reply lần cuối.
• Mở lần 3 sớm = giảm giá trị bằng chứng nếu khiếu nại T-11: shop có thể phản hồi "khách mở liên tục, không cho thời gian xử lý" — khiếu nại yếu.
• Chuỗi 2 lần ticket + 1 lần khiếu nại T-11 là canon design; chèn thêm lần 3 sáng T5 làm mờ mốc T-11, mất kỷ luật "mở đủ 2 lần rồi khiếu nại".

Sáng T4 29/7 verify lần cuối là mốc kế tiếp — cách sáng T4 22/7 tròn 7 ngày, cho ticket outcome (a) và (b) đủ window resolve, ticket outcome (c) đủ dead-air data để khiếu nại chắc.

Với ticket outcome (a) "cần push" (không phải "chờ shop close"), tag riêng "sáng CN 26/7 05:00 — mở ticket update phản hồi shop, không phải mở lần 3". Sáng CN 26/7 là post-payday 25/7 + weekend quiet, slot đúng.

Với ticket outcome (b), tag "trong tuần T3 23-24/7 khi có 10 phút quiet — attach thông tin HT24H yêu cầu". Không đè vào slot audit T4/T5 chính.

Vì sao audit D+7 sáng T4 quyết định mốc T-11 = 29/7

Ticket lần 2 mở sáng T2 20/7 → 48h post = sáng T4 22/7 (chính là hôm nay). Nếu bỏ qua sáng T4, mốc verify tiếp theo tự nhiên = sáng T5 23/7 (72h) hoặc sáng CN 26/7 (đã có việc post-payday). Sáng T4 vì thế là slot duy nhất trong tuần T3 đủ điều kiện quiet + đủ data 48h + đủ buffer trước T-11:

• T-11 = 29/7 chỉ còn cách sáng T4 22/7 = 7 ngày.
• Nếu phân outcome sáng T5 23/7 (D+8, T-2 lương), đầu đã bận reset ledger pre-payday, dễ bỏ sót ticket outcome (c).
• Nếu phân outcome sáng CN 26/7 (D+11, post-payday), khoảng cách đến T-11 chỉ còn 3 ngày, chưa kể buffer cho verify lần cuối sáng T4 29/7 — quá sát, không có margin.

Phân xong sáng T4 22/7 nghĩa là từ T5 23/7 đến sáng T4 29/7, kỷ luật là không đụng ticket outcome (c) trừ khi shop chủ động reply. Đây là design canon của chuỗi ticket lần 2 → khiếu nại T-11: cho shop 7 ngày yên tĩnh cuối cùng, quan sát xem có move không, trước khi chuyển kênh chính thức.

Nếu sáng T4 phát hiện tất cả ticket lần 2 đã resolve

Trường hợp tốt nhất: cả list ticket outcome (a) "chờ shop close" hoặc "cần push" nhẹ, không có ticket nào rơi outcome (c). Note ngắn vào weekly note "T4 22/7 phân outcome — 0 candidate T-11 khiếu nại 29/7, chỉ còn X ticket (a) verify sáng CN 26/7", rồi đóng.

Không rush kết luận "hết ticket rồi, dừng audit". Chuỗi audit D+5 → D+7 → D+11 → T-11 là design phòng thủ chống hidden dead-air — có tuần 0 ticket không có nghĩa tuần tới 0. Sáng T4 29/7 vẫn giữ slot verify chuỗi kể cả list trống.

Đóng lại

3 outcome đã phân cho từng ticket lần 2 48h post (a shop replied / b HT24H clarifying / c dead-air), decision path T-11 = 29/7 đã note với 3 field (thời gian dead-air / số dư treo / shop nhóm), tag verify tiếp cho từng nhóm ticket. Weekly note cập nhật "T4 22/7 phân outcome done — verify status lần cuối sáng T4 29/7 các ticket (c) trước khi khiếu nại T-11". Đóng weekly note. Không mở ticket lần 3, không mở tab Home. Vào ca sáng T4, ticket outcome (c) chờ 7 ngày yên tĩnh.

Trưa T4 hôm nay sẽ handle checkpoint 48h post-pin 3 SKU 8-8 với verify baseline giá net drift + set alert weekend 26-27/7 rescan — đường song song cho prep 8/8, không đụng chuỗi ticket.

Nếu bạn đang chờ HT24H hỗ trợ ticket cashback bị treo tương tự, xem ho-tro để hiểu đường support và chinh-sach-hoan-tien cho các mốc thời gian pending → khả dụng.