refund prevention

Research with 500 buyers and 400 creators surfaced something the team hadn't expected.

Access-related issues — buyers who couldn't log in, find their access link, or open their content — drove 7–54% of refunds depending on the journey and 30% of all CX tickets.

These weren't dissatisfied customers. They were customers who couldn't reach what they had paid for, and the refund flow was the easiest path to ask for help.

The decision

Move the why from the end of the journey to the beginning.

The existing flow processed the refund first and asked the reason after confirmation. By then, the request was already submitted, the GMV already gone, and the user already in the queue.

I redesigned the journey to invert that logic: understand the reason before processing, and offer a path to resolution when the reason was solvable.

For access issues specifically, that path was a single screen showing the user's purchase details and a direct link to access the product they were trying to refund.

The redesigned flow

The new structure added one step — reason selection — and one branch — resolution attempt. Everything else stayed in place.

The intervention only fires for solvable problems. A user requesting a refund because the product didn't meet expectations still gets to refund. A user who simply lost their access link gets the link.

This wasn't friction added to make refunds harder. It was a missing step that should have been there from the start.

Results

Of users who reached the new resolution step:

• 80% clicked "Access My Product"

• 73% successfully accessed their content

• 53% of total refund journeys abandoned the request entirely

No measurable increase in CSAT complaints, no rise in support tickets — meaning the intervention didn't harm users who still genuinely needed to refund.

The benchmark that guided this redesign held: the best refund journeys offer transparency, feedback, and alternatives. They don't just process requests.

Why this worked

The intervention wasn't about convincing users to stay. It was about removing the conditions that made them leave.

The earlier flow assumed refund intent was final by the time the user reached the submit screen. Research showed it wasn't — for a significant share of users, the refund was a workaround for an unresolved access problem.

Once that gap was named, the design moved itself. A reason step + a resolution branch did the rest.

A parallel experiment, briefly

A service experiment ran alongside this work — testing whether creators could reverse refunds already in motion through bonuses or extended access.

3.03% reversed. Surveys had predicted 33.4%. That gap confirmed what the prevention work was already showing: by the time a refund reaches submission, the window has largely closed. I recommended stopping investment in post-request reversal and doubling down on pre-request prevention.

Reflection

A refund flow that only processes refunds is doing half the job. The other half is asking whether the request should exist in the first place.

The work also surfaced a structural problem in how refund reasons were collected — nearly half were logged as "Other," making reliable strategy impossible. That became its own initiative.

→ See also: [Refund Reason Taxonomy] — redesigning the data layer beneath this work.