Designing refunds as a system, not a feature
Designing refunds as a system, not a feature
Making high-risk financial workflow predictable, trustworthy, and scalable
Making high-risk financial workflow predictable, trustworthy, and scalable
About the company
About the company
Aakash
Aakash
India’s biggest edtech platform preparing students for competitve exams
India’s biggest edtech platform preparing students for competitve exams
3M+
3M+
Students trained
Students trained
5,000+
5,000+
Teachers
Teachers
300+
300+
Branches (India)
Branches (India)
Project Details
Project Details
Objective
Migrate refunds form old legacy platform to new one with UX improvements
Migrate refunds form old legacy platform to new one with UX improvements
Timeline
1 Month (Mar 2025)
1 Month (Mar 2025)
The Team
1 PM, 14 Devs, 1 PD
1 PM, 14 Devs, 1 PD
My Role
End-to-end, Sr. PD
End to end designs (Discovery → Launch)
Worked directly with PM, Finance, Ops, Engineering
Owned UX decisions around system structure & states
End to end designs (Discovery → Launch)
Worked directly with PM, Finance, Ops, Engineering
Owned UX decisions around system structure & states
Business Context
Business Context
Migrating from a legacy ERP system to a new in-house platform
Migrating from a legacy ERP system to a new in-house platform
Company was migrating from a legacy ERP system to a new in-house finOps platform, which powered all the finance operations
Company was migrating from a legacy ERP system to a new in-house finOps platform, which powered all the finance operations
Refund was a major migration task, it’s scale & complexity made it highly important
Refund was a major migration task, it’s scale & complexity made it highly important
System Importance
System Importance
Why it matters?
Why it matters?
Refunds are not edge cases, they were frequent high-ticket operations. At this scale, small inefficiencies or errors compounds to revenue leakage or compliance risk
Refunds are not edge cases, they were frequent high-ticket operations. At this scale, small inefficiencies or errors compounds to revenue leakage or compliance risk
282k
282k
Annual refund volume
Annual refund volume
24d
24d
Average refund TAT
Average refund TAT
High risk
High risk
Trust-critical workflow
Trust-critical workflow
Refunds sat at the intersection of finance, operations and student trust
Refunds sat at the intersection of finance, operations and student trust
A Messy Reality
A Messy Reality
Refund as a system had many touch-points & involved 6 users in it’s lifecycle
Refund as a system had many touch-points & involved 6 users in it’s lifecycle
Any ambiguity in this system sent ripple effects across all the teams
Any ambiguity in this system sent ripple effects across all the teams
Problem Discovery
Problem Discovery
Discovery beyond migration
Discovery beyond migration
To understand how refunds actually worked in practice, not just how they were documented
To understand how refunds actually worked in practice, not just how they were documented
Legacy flows
Reviewed flows, PRDs and exception cases
Refund mocks
Observed & mocked how refunds were raised and approved at branches
User feedbacks
Listened to finance, ops, and accountant teams
Legacy flows
Step 1
Refund mocks
Step 1
User feedbacks
Step 1
Expectations vs reality
Expectations vs reality
What I saw on the ground
What I saw on the ground
Each step worked, each team was doing their part,
But the system as a whole didn’t coordinate well
Each step worked, each team was doing their part,
But the system as a whole didn’t coordinate well
6/7
Refund types had different logic despite similar steps
4/4
Small data issues caused full restarts of the workflow
2/2
Counsellors had no visibility and escalations were common
8/10
Refund status shared in emails, calls, and whatsapp
9/10
Most refund activity was done over mails, excel sheets & whatsapp
"I observed it was not a broken feature, but a broken system of coordination"
"I observed it was not a broken feature, but a broken system of coordination"
How our older system looked. Yes, it was confusing.
How our older system looked. Yes, it was confusing.
Observations to patterns
Observations to patterns
Patterns which emerged
Patterns which emerged
From those observations four patterns became clear,
From those observations four patterns became clear,
01
Fragmented refund flows led to early misclassification
Fragmented refund flows led to early misclassification
02
Rejections forced re-initiations instead of corrections
Rejections forced re-initiations instead of corrections
03
Lack of clear states caused uncertainty and constant follow-ups
Lack of clear states caused uncertainty and constant follow-ups
04
Different teams tracked refunds in different ways
Different teams tracked refunds in different ways
Data also supported these patterns
Data also supported these patterns
5.9%
5.9%
Major
cancellations
Major
cancellations
12.5%
12.5%
Minor
cancellations
Minor
cancellations
17.6%
17.6%
Re-initiations
Re-initiations
Design focus shifted to
Design focus shifted to
"Designing a system which reduced complexity, increased transparency & eliminated errors"
"Designing a system which reduced complexity, increased transparency & eliminated errors"
Pattern 1
Pattern 1
Fragmented refund flows
Fragmented refund flows
All refund types had its own workflow & logic within which 85% steps were identical
All refund types had its own workflow & logic within which 85% steps were identical
64%
64%
Major cancellation due to refund mismatch
Major cancellation due to refund mismatch
Pattern 1 - Design Decision
Pattern 1 - Design Decision
Unified refund flow
Unified refund flow
Refund eligibility according to the student.
1 Refund type made automatic (Major contributor of wrong refund selection)
Refund eligibility according to the student.
1 Refund type made automatic (Major contributor of wrong refund selection)
56%
56%
Major cancellation dropped
Major cancellation dropped
Here's what the simpler flow looked like
Pattern 2
Pattern 2
Cancellations forced
re-initiations
Cancellations forced
re-initiations
67% cancellations were due to minor fixable issues, which then triggered email follow-ups and ultimately 17% re-initiations
67% cancellations were due to minor fixable issues, which then triggered email follow-ups and ultimately 17% re-initiations
28% Rectification refunds to fix past refund mistakes
28% Rectification refunds to fix past refund mistakes
Reinitiating & fixing is rework → Higher OPEX
Reinitiating & fixing is rework → Higher OPEX
Pattern 2 - Design Decision
Pattern 2 - Design Decision
Add a new correction flow
Add a new correction flow
New flow such that approvers can send request back to accountant for rectification
New flow such that approvers can send request back to accountant for rectification
77%
77%
Re-initiations dropped
Re-initiations dropped
Send for correction
Send for correction
Pattern 3
Pattern 3
Lack of clear states
Lack of clear states
We showed only 3 status, which lead to different expectations of states across teams.
We showed only 3 status, which lead to different expectations of states across teams.
8/10 Users escalated & required status follow-ups
8/10 Users escalated & required status follow-ups
OLD STATES
Pattern 3 - Design Decision
Pattern 3 - Design Decision
Clear explicit states
Clear explicit states
Each state focused on,
What has happened, who owns it and what can happen next
Each state focused on,
What has happened, who owns it and what can happen next
NEW STATES
+50%
+50%
Approver efficiency
Approver efficiency
Scalable
Scalable
And also easily auditable system
And also easily auditable system
Pattern 4
Pattern 4
Different teams tracked refunds in different ways
Different teams tracked refunds in different ways
9/10 Users used individual trackers on excelSame questions asked for visibility across all roles
9/10 Users used individual trackers on excelSame questions asked for visibility across all roles
TRACKING ON EXCEL
Pattern 4 - Design solution
Pattern 4 - Design solution
Central refund tracker
Central refund tracker
All refunds in one place with clear state, owner, and time-in-state. It’s a role aware coordination tool
All refunds in one place with clear state, owner, and time-in-state. It’s a role aware coordination tool
TRACKING ON EXCEL
5/5
5/5
Users reported, Follow-ups reduction
Users reported, Follow-ups reduction
Single truth
Single truth
For every user
For every user
We designed,
We designed,
A system that is predictable, auditable, and scalable under evolving financial policy
A system that is predictable, auditable, and scalable under evolving financial policy
Design constraints
Design constraints
Key design decisions & trade-offs
Key design decisions & trade-offs
Discarded student self-serve
Discarded student self-serve
Prevented churn, recovery focused
Slower for students
Introduced “Draft” state
Introduced “Draft” state
Reduced errors before initiation
Required additional engineering work
Added “Sent back for correction”
Added “Sent back for correction”
Reduced re-initiations and email loops
Slightly longer lifecycle, but far less rework
and 3 more.
Step 1
Final designs
Final designs
This is what it looked like after the designs.
This is what it looked like after the designs.
Flow: Raising a refund request
Flow: Raising a refund request
Refund state machine
Refund state machine
Different refund flow merged into a single request
Different refund flow merged into a single request
Approver dashboard, powered by the same central refund tracker
Approver dashboard, powered by the same central refund tracker
Key results
Key results
Impact after pilot
Impact after pilot
We piloted in 3 branches for two months (Nov & Dec, 2025). We compared the data with last year activity & got good results
We piloted in 3 branches for two months (Nov & Dec, 2025). We compared the data with last year activity & got good results
Ops load reduced
Ops load reduced
-41%
-41%
Rectification refunds dropped
-77%
-77%
Re-initiations reduced
Quality improved
Quality improved
-61%
-61%
Total cancellations reduced
-65%
-65%
Minor cancellations drop
Throughput improved
Throughput improved
+44%
+44%
Total refunds processing
Rolled out in Feb, 2026
Rolled out in Feb, 2026
Future roadmap
Future roadmap
Some ideas for phase 2 revamp
Some ideas for phase 2 revamp
Automation but selective
Key takeaway
Key takeaway
In enterprise system, good design is not about speed or polish, it’s about preventing failures at scale
In enterprise system, good design is not about speed or polish, it’s about preventing failures at scale
The End
The End
Thank you for your time
Thank you for your time
If you feel like chatting about the case study, drop me a Hi! I reply in seconds.
If you feel like chatting about the case study, drop me a Hi! I reply in seconds.
JUMP TO
JUMP TO