Indranil Ghoshal
All prototypes

Instant Return Refund

Loyal customers get refunded the moment the parcel is scanned at hand-over. Everyone else gets their refund only after the item reaches the hub and passes inspection — turning speed into an earned loyalty benefit.

ELIGIBILITYINSTANT CREDITHUB QC

Customer drops off → eligibility gate → instant credit or hub inspection

1. What to build

A returns flow inside the shop app where a customer selects an item to return and — if their loyalty tier and risk profile allow it — receives the refund the instant the parcel is scanned at drop-off, instead of waiting for hub inspection.

2. User & entry point

The customer, arriving from My orders → Return an item after a delivered order. Ops agents see the same decision as a read-only audit trail; they do not drive this flow.

3. Screens / steps

  1. Item selection from the delivered order
  2. Return reason
  3. Refund eligibility verdict (instant vs. after hub check) with the reason why
  4. Drop-off method — parcel shop, locker or courier pick-up
  5. Hand-over scan simulation
  6. Confirmation: refund credited, or refund pending QC

4. Logic & rules

  • Loyal customer = instant refund. Platinum, Gold and Silver tiers qualify for instant credit up to their cap (€500 / €250 / €100). Standard and non-loyal customers receive the refund only after the item arrives at the hub and is checked.
  • Item value above the tier cap, return-abuse risk score ≥ 60, or any disputed return on file falls back to the hub-checked refund path.
  • Serialised electronics always need IMEI verification at the hub.
  • "Arrived damaged" and "wrong item" claims need a physical check; size and expectation returns do not.
  • The refund fires on the drop-off scan event, not on the return request — no scan, no money.
  • If the hub later finds the item missing or not as declared, the refund is clawed back from the original payment method (out of scope for this prototype's UI).

5. Data / inputs

All data below is mock / sample: customer profile (tier, risk score, 90-day return count, disputed returns, tenure), order items (name, category, price, order date, serialised flag), return reasons, drop-off locations with their scan event types, and tier-level refund caps.

6. States handled

Empty (nothing selected yet), loading (scan in progress), error (scan failed — refund not triggered), success — instant credit, and success — return booked with refund pending QC.

7. Out of scope

No auth, no payment processing, no backend persistence, no real label generation, no ops back-office, no fraud-model training. Front-end simulation only.

Simulate a customer profile

The eligibility engine reacts to tier, risk score and item — switch profiles to see the fallback behaviour.

1. What are you returning?

Select an item above to start the return.

Prototype only — customers, orders, risk scores and scan events are simulated data. No payments are processed and nothing is persisted.