A return clock needs the event that started it

Return disputes often become messy because nobody agrees which event started the clock.

The seller may count from purchase. The carrier may count from delivery. The platform may count from delivered status. The buyer may count from pickup, unboxing, activation, or first use. Each clock can be reasonable for a different type of claim. The problem is using one clock without naming it.

For changed-mind returns, purchase or delivery may be fair. For damaged-on-arrival claims, possession or unboxing may be fairer. For defects that require setup, the clock may need to start at first reasonable test. For perishable goods, the clock may need to be strict and short. The record should match the claim type.

A return clock record should name the start event, deadline, claim type, evidence, and who can extend or deny the window. It should also say what evidence is not enough. A photo after the deadline may show damage, but not when it happened. A delivery scan may show arrival, but not inspection.

This matters for platforms because fixed rules are easier to automate but not always easier to trust. Buyers need to know what to capture. Sellers need to know when a sale is final. Support needs a line it can apply consistently.

The useful compromise is not to make every return flexible. It is to make the clock explicit. If the policy says delivery starts the window, say that. If certain claims can use pickup or inspection, say which claims and what proof is needed.

A return window without a start event is not a policy. It is a future argument.

A return clock needs the event that started it

// COMMENTS

ON THIS PAGE