Progress must be trackable
Aliases: refund status · after-sales tracking · refund progress
What it is
After the request is in, people must open the same after-sales thread and see which step it sits on, when that step started, and whose move is next. Trackable is the state machine made visible, not a forever ticket that says “we received it.” A time limit says the latest moment; progress says the present. Without progress, the limit is a date on the wall.
Why it happens
Refunds cross merchant, warehouse, finance, and rail; from outside there is only silence. Silence is encoded as “not working” or “money gone,” then nudges and chargebacks. Mapping internal tickets to a few external stages (review, wait for return, received, paid out, rail processing, credited) lets people decide whether to act—returning a parcel is theirs; rail processing is not a merchant nudge. Stage names must bind to real events: finance has not paid out, so the UI must not say “refunded.” Timestamps on history let people see stall, rather than “processing” on every open.
Studying it
Run a refund that pauses (awaiting return, inspection). Compare no status, “processing” only, and staged timestamps. Watch which stages attract nudges.
Independent variables: number of stages, whether the responsible party is shown, stall marked separately. Dependent variables: in-window nudges, nudging the wrong party (merchant while it sits at the bank), naming the current step.
Labs compressed to minutes will not show next-day stall. Use a diary or a next-day return. Notification count is not progress—many pushes with no state change are noise.
Where it stops holding
If the rail never posts credit, the last stage stays “refund initiated” and points people to the bank app; do not fake “credited.” Partial returns of several items need per-item state; one bar for the order lies. After cancel, progress should close as “cancelled,” not vanish so people think it still runs. Internal review notes can stay hidden; the outside still needs an actionable “need more materials.”
Applying it
- After-sales detail uses a stage list, current step highlighted, each with a start time; stall past its own limit marks overdue.
- Steps that need the user (ship back, more photos) offer the action; others say “nothing for you to do.”
- Credit completes only on rail notify or user confirmation; no notify, no complete.
- Verify with a return waiting for shipment; next day ask “whose turn, do you ship.” Failure: no responsible party, or “refunded” before merchant payout.