ReturnSift

When should you reset a customer's return score?

Return scores are built to remember. That is their strength: a customer with forty returns in six months should not be treated like a customer with one. But memory without a reset policy turns into a different problem. Behavior changes, accounts get compromised and recovered, and a score that never forgives starts punishing people it should have released years ago. A reset policy is not leniency. It is score hygiene.

Why scores go stale

A return score is a summary of past behavior, and past behavior has a half-life. Someone who abused returns during a rough year, then shopped normally for two more, is not the same risk they were. Someone whose account was taken over, ran up fraudulent returns, and then recovered the account with your fraud team's help is not a fraudster at all. And seasonal patterns distort everything: a customer who looks like a serial returner in December may be a perfectly ordinary bracketer buying holiday gifts. Scores that never decay treat all three of these people as permanent risks, which means your controls spend their budget on the wrong accounts.

Good reset triggers

The cleanest trigger is sustained clean behavior: twelve months of normal purchase-to-return ratios with no policy violations. That is long enough to mean something and short enough to be achievable. Account recovery is another: when your own investigation confirms an account was compromised and the legitimate owner is back, the fraud-period behavior should be quarantined from the score, not averaged into it. Data corrections count too: if a reason-code cleanup or a warehouse error inflated someone's score, fix the inputs and recompute rather than letting the bad data age out on its own.

Bad reset triggers

Do not reset because a customer complained loudly, because a VIP asked, or because a fixed amount of time passed with no behavior change. Complaint-driven resets teach customers that escalation erases history, which is a lesson you do not want to teach. Time alone is not rehabilitation: a dormant account that wakes up and resumes the old pattern should pick up where its score left off. And never promise resets as a customer-facing policy. The moment customers know the forgiveness schedule, the schedule becomes part of the abuse playbook.

Decay versus hard reset

In most cases, gradual decay beats a hard reset. Weight recent behavior more heavily and let old signals fade on a curve, so a reformed customer earns their way back and a relapsing one is caught quickly. Reserve hard resets for the cases where the history itself was wrong: confirmed account takeover, data errors, identity mix-ups. And keep the history flagged even after a reset. A reset score should still carry a note about what happened, visible to analysts but not to the scoring model, so the next review has context instead of a blank slate.

Keep it internal

The reset policy belongs in your operations documentation, not on your website. Publish the behavior you reward, which is normal shopping, and keep the mechanics of forgiveness private. Review reset outcomes quarterly: how many reset customers reoffended, and how fast. If the reoffense rate is low, your triggers are well calibrated. If it is high, you are resetting too eagerly. A score that forgives wisely is more accurate than one that never forgets, and accuracy is the whole point.