Back to all work
https://supplier.meesho.com/returns
RETURN RECON
MEESHO · 2021

Return Recon

Sellers believed they were losing half their returns. They were losing 3%. That belief was sitting inside Meesho's prices — and making the panel easier to use did not shift it.

Supplier Panel · Lead Designer, sole designer · ~2 months to ship

Chapter One

Background & Context

Timeline
2021 · ~2 months
Company
Meesho — Supplier Panel
Responsibilities
IA, Flows, UX, Testing

Built in 2021 — the year Meesho became a unicorn and its supplier base grew roughly 7×. The panel served hundreds of thousands of suppliers, the large majority of them small businesses selling online for the first time.

Meesho sellers could not see what happened to their returned shipments. Returns left the customer, vanished into the courier network, and sometimes came back. Claims lived entirely in email threads. Sellers filled that silence with a worst case — and research showed how far off it was.

What sellers believed
What was actually true
Return rate above 30%
Roughly 13%
~50% of returns lost in transit
3%

Around 90% of sellers were managing returns in Excel or a similar tool outside the panel. Larger sellers had a person dedicated to it.

Those beliefs had a price. Sellers carried a buffer on units to cover wrong returns, and the panel was the only place that buffer could be argued down. On a marketplace whose entire proposition is being the cheapest place to buy, an invisible logistics process was quietly inflating the catalog.

Chapter Two

What Sellers Were Working With

One detail says everything. The most prominent control on the page was DOWNLOAD EXCEL, sitting above everything else. The primary action in the product was leaving the product.

Below it, a filter block and a list of order cards. Each card carried an order number, a type, a status of PENDING, a pickup date, a courier name and an AWB. That was the entirety of what a seller could know.

What was missing
Any way to see how many shipments arrive today
An expected delivery date for anything in transit
Visibility of lost shipments — at all
A way to view or request proof of delivery
A way to raise a claim for a wrong, damaged, used or lost return
A single place to see claim status

Read that list next to the beliefs above and the causal chain is obvious. A seller who cannot see a shipment arrive, cannot prove one was delivered, and cannot track a claim will conclude that returns disappear and claims get rejected. Both conclusions were wrong. Both were entirely reasonable given what the interface showed them.

The problem, as I came to frame it

"Not every return comes back to me. Meesho rejects most of my claims. I should price for that."

The brief was not "help sellers track returns." It was make the system legible enough that sellers stop pricing in fear.

Chapter Three

Research & Discovery

Interviews were run by Meesho's research team, and I sat in on them. Competitive research, the information architecture, flows, wireframes, the KPI layer and the usability testing that drove V1 to V2 were mine. The questions were deliberately about the sellers' business rather than the panel — how they manage returns, what they store daily, and what they do to cover the losses they feel they are taking.

Research Methods

A multi-faceted approach to gather insight. In-depth interviews gave rich, contextual information. A competitive audit revealed the comparison sellers were already making in their heads. Usability testing let us watch sellers interact with the interface in real time.

Interviews with 5 sellers, three mid-sized and two large, recruited through support.

Competitive audit of the Flipkart & Amazon seller panels for return visibility.

Usability testing of the wireframes with the same sellers, four tasks each.

Key Findings

The finding that reframed everything was operational: around 90% of sellers were reconciling returns outside the panel in Excel, and at larger sellers that was a person's job. The panel was not their source of truth.

A second finding shaped where I looked next. Sellers were benchmarking Meesho's return rate against what they believed Flipkart's was — from memory, against a competitor, using numbers neither platform had ever shown them. In-panel claim tracking, it turned out, essentially did not exist anywhere in the category.

Chapter Four

V1 — Solved the Workflow,
Not the Belief

V1 gave sellers the full lifecycle — three states with live counts, filters, search across order ID, SKU and AWB, expected delivery dates with delay flagging, and claims brought into the panel. We retested it with the same five sellers, four tasks each.

1How many returns are you expecting today? — went well
2How many returns this month, and how much loss? — this is where it broke
3What is the status of the claims you have made? — went well
4Is this enough to replace your Excel sheet? — the Excel sheet survived

Nothing in V1 could answer Task 2. The panel held every individual shipment and no view of the month, so sellers fell back on the same inflated estimate they had given in research. I had built for the wrong unit of work. The panel answered where is this shipment, one row at a time — and answered it well. Sellers were asking something else: am I okay this month. Efficiency and belief are different design targets.

Chapter Five

V2 — Designing for the Belief

The change was an aggregate band above the tables — four numbers, each chosen to attack a specific false belief rather than to summarise the page. It gave the panel a view at the altitude the seller's real question was being asked at.

13%
Customer return rate, with trend
3%
Courier (RTO) return, split out
Claims
Raised as a share of returns delivered
44%
Claims approved, with ₹ recovered
KPI
The belief it targets
Customer return rate
"My returns are above 30%" — shown at 13%, and moving
Courier (RTO) rate
Splits two causes sellers had merged into one fear
Claims raised
"I am constantly having to claim"
Claims approved
"Meesho rejects everything" — shown at 44%, with the money named

Two choices worth defending. Splitting customer returns from courier returns cost a column of space and bought an accurate mental model. Showing the 44% claim-approval rate, with the rupee figure, is uncomfortable — but the belief we were fighting was that claims were pointless, and a real number with real money attached beats a reassuring statement. Transparency only works when it is willing to show the unflattering version.

Chapter Six

Decisions Worth Defending

Claims brought inside the panel

The competitive gap and the loudest source of distrust. We pulled the whole claim lifecycle in against its sub-order, rather than leaving it in the ticketing system.

Dated promises, not status labels

Every claim state carries a date. Approved means compensation by a specific date. Dates are commitments — but a status label is still silence with a nicer font.

Lifecycle tabs, search lifted out

Five views mapped to shipment state, because the structure teaches the state machine — a seller learns that a failed delivery is not a lost shipment. Search sits outside the tabs, across all states.

Proof of delivery as a gate

The flow routes a delivered shipment to proof first, and only into a claim if proof is unavailable. Proof resolves the dispute before it becomes one.

Chapter Seven

Outcome

I do not have post-launch numbers. What I can state is how success was defined before we designed anything — and the panel shipped instrumented against exactly those measures.

2.8%
Baseline wrong-returns buffer to reduce
+1.6%
Target lift in supplier NPS
−0.3%
Target drop in instances-per-order

What I can evidence directly is the testing that drove V1 to V2 — and the fact that the KPI band corrected an assumption that the operationally superior V1 left completely untouched.

What I'd Do Differently

I would have designed for the belief first.

The brief said tracking, so I built tracking — and it took a round of testing to discover that sellers were not asking where their shipments were. They were asking whether they were losing money. When a business problem is caused by what users believe, efficiency improvements do not touch it. I now check early whether the thing I am fixing is the workflow, or the story the user is telling themselves about the workflow.

RETURN RECON · MEESHO · 2021