TIKTOK SHOP U.S. · AFTERSALES OPERATIONS
Before You Reject a TikTok Shop Return, Check the Evidence and ISRR Risk
Direct answer: before rejecting a return, verify the order facts, current eligibility, readable evidence and the next clock. A rejection is not a customer-service phrase or a button state. It is an operating decision that may be reviewed later, so the record must explain why the request was in scope, what evidence was read, who owned the decision and what finally happened.
Read ISRR as a quality signal, not a rejection quota
The current Requirements for Invalid Seller Rejection Rate define ISRR as the percentage of eligible seller-reviewed aftersales requests where the seller rejects a request and that rejection is later determined invalid. The requirements describe a weekly evaluation using a rolling eight-week window. That makes ISRR a feedback signal about decision quality across a defined population, not a simple count of how often a team says no.
The useful operating question is not, “How many rejections are still allowed?” It is, “Which rejections did not survive a later facts-and-evidence review?” A team can lower risk by making every refusal reproducible. Another reviewer should be able to open the same order, see the same rule, read the same evidence and understand the same conclusion without reconstructing the case from chat.
Separate metric scope from case truth
The official ISRR material identifies excluded scenarios, including logistics-related reasons, malicious buyer or buyer-abuse cases, high-value buyer cases decided by the platform, and certain Auction or Final Sale buyer-fault cases in the U.S. calculation. Scope matters because a blended dashboard can hide whether a problem comes from seller judgment, logistics evidence or a platform-managed path.
An exclusion does not mean evidence is unnecessary. The customer still needs a correct outcome, and the seller still needs a readable record. Treat scope as a routing rule: first determine which process owns the case, then apply the evidence and review requirements for that process. Do not use an exclusion list as permission to make a less careful decision.
Gate one: confirm the order and request
Begin with the exact order, product, variant, quantity, delivery state, request type, buyer reason and current case status. A warehouse photo of a similar unit is not evidence for this unit. A tracking event from another package is not evidence for this shipment. The identifiers must connect before the reviewer interprets the content.
Record what is known and what is still missing. If a serial number, package label, component list or delivery event is needed to distinguish the case, name it as a required fact. Do not quietly convert “unknown” into “buyer fault” merely because the review clock is short.
Gate two: read the current policy and eligibility
Place the case against the current return, refund, replacement, category and order rules. Team memory and an old screenshot can be useful clues, but neither proves the live rule. The policy path should identify why the request is eligible or ineligible, which remedy is available and whether a category, order type or platform-managed exception changes the reviewer’s authority.
Store the rule name or version with the decision. When policy changes, that record separates a correct historical decision from a new operating rule. It also prevents reviewers from using the latest wording to rewrite what was actually available when the decision was made.
Gate three: test whether the evidence tells one story
Useful evidence is connected, timed and mutually intelligible. Product photos should identify the relevant item and claimed condition. Inspection records should say who inspected what, when and against which acceptance criteria. Logistics events should correspond to the same order and package. Communication records should preserve the buyer’s actual reason rather than a compressed internal label.
More files do not automatically create stronger evidence. Ten ambiguous images can be weaker than one labeled photo plus a complete inspection entry. Read evidence for and against the proposed refusal. If a carrier scan conflicts with warehouse intake or the buyer’s image cannot be linked to the item, stop and resolve the conflict rather than selecting the evidence that supports the preferred answer.
Gate four: define the terminal outcome
A click on Reject is not terminal proof. Read back whether the request was rejected, returned for more information, placed in platform review, appealed, reversed, refunded or otherwise completed. Keep the final order state, amount, timestamps and owner with the evidence card. This is what turns a decision attempt into an auditable operating result.
The official requirements distinguish the ISRR metric from appealable platform-initiated aftersales decisions. Sellers cannot appeal the metric itself, while eligible decisions can follow the standard appeal path. Retain order-level material because a dashboard screenshot cannot explain or support an individual appeal.
Do not turn thresholds into permission
The current requirements state that an Overall ISRR of 20% or higher triggers a warning, while Refund-only and Return and Refund requests must remain below 30%. They also describe platform-managed review for eligible aftersales requests when relevant thresholds are exceeded. These are control thresholds, not a budget for invalid refusals.
When the metric rises, segment the invalid decisions by request reason, SKU, category, warehouse, reviewer and missing evidence field. Then repair the recurring source of error. Training may be appropriate, but the root cause might instead be an unclear listing, a weak warehouse inspection step, missing identifiers or a review queue that forces decisions before evidence arrives.
Use three explicit decision paths
Continue review only when required facts are complete, the current rule is clear and evidence is coherent. Pause and complete when the case needs a named missing record or a conflict resolved. Escalate when the rule boundary is unclear, a special category or fraud-sensitive signal appears, the deadline is close, or platform review or appeal is involved.
Each path needs an owner and clock. “Manual review” without a named person or due time is not a safe stop condition. Preserve the material already gathered when a case moves between paths so the next reviewer does not restart from an incomplete support conversation.
Build a six-field rejection evidence card
- Order and request facts, including identifiers and current status.
- The current rule and eligibility path used for the decision.
- Evidence supporting and contradicting the proposed refusal.
- Capture time, source and linkage for each material record.
- Named reviewer, remaining deadline and required next action.
- Submitted action, platform response and terminal order outcome.
The card is not extra paperwork for its own sake. It creates a consistent review unit for training, appeals, weekly root-cause analysis and future automation. If a field repeatedly remains blank, fix the system that should produce it rather than teaching reviewers to write around the absence.
An operating example
This is a hypothetical operating example, not a client result. A return request says an item arrived damaged. Warehouse photos show damaged packaging but contain no order label, serial reference or intake timestamp. The team should not turn “damaged packaging” into a refusal reason. It should link the order, confirm the item and applicable rule, obtain the intake record and compare the buyer’s evidence. If the facts cannot be completed before the clock, the case escalates.
A different case may include the order label, timestamped inspection video, component checklist, buyer reason and a documented applicable exception. That record may support a reviewable refusal, but the team still reads back the platform response and final state. The difference is not confidence or tone. It is connected evidence.
Smallest useful next action
Pull ten recent return rejections and complete the same six-field evidence card for each. Group missing fields by reason, SKU, warehouse and reviewer. Choose the most repeated gap and repair that input before tightening refusal rules or adding automation. Re-run the ten cases after the repair and verify whether another reviewer reaches the same conclusion from the record alone.
Source notes
This original WEM operating framework draws on the current Requirements for Invalid Seller Rejection Rate (ISRR) Metric and Requirements for Managing Returns, Refunds, and Replacements, fully read and revalidated on October 18, 2026. Platform rules, eligibility, thresholds and interfaces can change. Verify the live policy and current order record before execution.
Related WEM guides
Frequently asked questions
What does ISRR measure?
It measures the share of eligible seller-reviewed aftersales requests where a seller rejection is later determined invalid. It is an operating quality signal across a defined scope and window, not a verdict on one isolated case.
Can a seller appeal the ISRR metric?
No. The metric itself cannot be appealed. Eligible platform-initiated aftersales decisions may use the standard appeal process, so retain the complete order-level evidence and final readback.
When should a rejection stop?
Pause or escalate when a required fact is missing, evidence conflicts, policy scope is unclear, the category needs special treatment, or no named owner can complete the review before its deadline.
Why is a photo not enough?
A photo must connect to the order, item, timing and claimed condition, and it must agree with inspection, logistics and communication records. An isolated or ambiguous image cannot explain the entire decision.
What must a rejection record retain?
Keep the order and request facts, applied rule version, evidence for and against the reason, capture time, reviewer, remaining clock, submitted action and terminal outcome.
What is the smallest useful next action?
Audit ten recent rejections with the same six-field evidence card. Group missing fields by reason, SKU, warehouse and reviewer, then repair the most repeated gap before changing policy or automation.
