One system. Three teams. The same numbers everywhere.
Solv is a B2B commerce platform. Three teams were reconciling payments by downloading reports and switching between five different tools. I redesigned the system so finance, support, and sellers were all reading the same numbers, in the same place.
MIS multi-screen composite — Dashboard, Transaction View, UTR Approval, OMS and Seller Portal
67%
reduction in payment-related support tickets
Source: CRM team
7→2 days
average vendor settlement processing time
Source: Finance team
55% faster
daily reconciliation, same tasks, less time
Source: Finance team
10→2 days
average seller payout time
Source: Operations team
Requirement context
Payments and deliveries crossed seven partner systems.
Solv is a B2B commerce platform. Wholesale buyers place orders, sellers fulfil them. Money comes in through three payment partners: PayU, Rupifi, and EPay Later (the last two are pay-later providers). Goods go out through four delivery partners: Delhivery, Bluedart, Ekart, and Smartr, who sometimes also collect cash on delivery for Solv.
The work connected three products: the internal MIS portal for finance, OMS for operations and support, and the seller-facing app and website.
Settlement work sat across this partner network. Finance handled roughly 90,000 settlements a month; one took 5–10 minutes when all the details were available. A 25-person finance team worked extra hours and still couldn't complete the full daily workload.
About Solv
A commerce and finance platform built for India's MSMEs.
Solv was an SC Ventures incubated B2B marketplace from Standard Chartered, helping Indian MSMEs trade with verified buyers and suppliers and access payment collection and credit. Standard Chartered reported almost 400,000 MSMEs on the platform after its first two years in a 2024 profile ↗.
Active sellers, Play Store downloads, and GMV: Solv internal figures as of May 2025.
Problem statement
A late settlement could put a seller's next business cycle at risk.
For a seller, a settlement was working capital. As of May 2025, the average seller did about ₹10 lakh in business a month. If a payout was delayed, that money was unavailable to restock or fulfil the next order. Sellers also had no clear view of when it would arrive.
The status gap crossed every team: finance chased mismatches across partner reports and email, support switched tools to answer payment questions, and sellers couldn't see where a settlement stood.
Adding finance staff would only increase capacity linearly. Solv needed a way to complete settlements at scale while giving sellers and internal teams a reliable view of payment status.
Who was affectedSellers waiting on cash, with finance and support bridging the gap
What was at stakeAbout ₹10 lakh in average monthly seller business (May 2025)
Visibility gapNo shared settlement status across finance, support, and the seller app
Operational constraint90,000 monthly settlements for a 25-person finance team; 5–10 minutes each
Design question
How might we make settlements reliable at Solv's scale and show sellers when their money will arrive, without growing the finance team linearly?
My contribution
I redesigned the financial layer across three Solv products.
I joined as a Senior Product Designer and was initially onboarded by the Design Manager. After the handoff, I took full ownership of the project: designing the new MIS finance platform from scratch, launching new features, and improving existing experiences across Solv's web and mobile products.
I led research and workflow mapping, reframed the original drill-down request with product, and partnered with product and engineering through prototyping, usability testing, executive UAT, and implementation handoff.
Understanding the workflow
I started with people, not data models.
Time didn't allow a broader formal study, so I started with one experienced internal representative from each team. Each had spent more than a year at Solv and over a decade in the industry. I interviewed them separately to compare the standard workflows they'd used before with the way work actually happened at Solv.
For the seller perspective, I visited three sellers across home-furnishing and FMCG categories. Their monthly business with Solv ranged from ₹15 lakh to ₹85 lakh, and they also worked with other platforms.
The most useful thing I did wasn't an interview. It was sitting next to a finance team member during morning reconciliation and watching. In 45 minutes I saw what no question would have surfaced:
—Where she switched tabs (PayU dashboard → Excel → email).
—Where she paused and double-checked a UTR against the bank statement.
—Where she gave up and estimated.
Watching someone work around your product teaches you more than any question you can ask them.
One seller's workflow changed how I framed the problem.
I mapped a typical seller's journey on Solv: order received → packed → picked up by 3PL → delivered → settlement pending.
Sellers weren't asking "where's my money" out of impatience. The timeline was genuinely opaque at every stage. Transparency, even without faster payments, would solve most of the anxiety.
Seller journey map
Scroll or use arrow keys→
Open full map ↗
Seller journey — order received → packed → in transit → delivered → return window → settled
Three roles, three different versions of "broken".
More data wasn't the problem. They needed the dashboard to lead with overdue, short-collected, and disputed payments across the three payment partners. Successful transactions were noise they were tired of scrolling past.
Support team
Every seller question meant switching systems. Order details lived in one tool and payment details in another. Each query cost 10–15 minutes of tab-switching before an agent could reply.
Sellers
Sellers wanted clarity more than speed. They couldn't see what stage their money was at. Orders moved from delivered → return window → settlement initiated → paid, but the seller never saw any of it.
Order to settlement · people and systems
One order could take several paths before a seller saw the money.
Payment type, delivery, returns, and disputes changed what happened next. The map follows the money, then shows how one late settlement moved through the teams.
01 Order & payment
Order placedBuyer starts checkout
Payment type
Online paymentPayU · Rupifi · EPay Later
Paid in fullAdvance paid
Cash on deliveryDelivery partner collects payment
Order cancelledRefund to buyer · average 24–72 hours
02 Delivery & settlement
Full online payment
Order delivered
→
Return waiting period24–48 hours
→
Settlement beginsTypical full-payment cycle · 7–10 days
Advance paid online · balance paid online
Order delivered
→
Collect remaining balanceOnline · around 1–2 days
→
Balance receivedSettlement starts
Balance paid in cash · or cash-on-delivery order
Order deliveredCOD or advance + cash balance
→
Partner collects & depositsFunds arrive at Solv · 3–5 days
→
Funds depositedSettlement starts
03 Returns, disputes & adjustments
Return
Review the item → return it to the seller → initiate a refund to the buyer.
Timing depends on the case.
Dispute
Operations and Finance review. If Solv is responsible, Finance approves; if the delivery partner is responsible, escalate to them.
Chargeback / adjustment
If Solv overcharged or settled short, correct the difference in the seller's next settlement.
04 When a seller asks, “Where is my payment?”
A single status question became a chain of checks across teams and systems.
Order delivered · settlement still pendingThe seller has no clear payment status or arrival estimate.
Seller
Asks support
“Where is my payment? How long will it take?”
Customer support
Checks with Operations
“The order is delivered, but settlement still shows pending. Why?”
Operations
Checks with Finance
“The order settlement is still pending. Can you check what happened?”
Finance
Searches across systems
“I need to check yesterday’s bank settlement, payment-partner reports, and email. Give me 10 minutes.”
↙Finance → Operations → Support
Support relays the update
“It hasn’t been processed yet. Please wait a few more days.”
Seller
The business impact
“If I don’t get my money, how will I run my business?”
Online and cash payments converged on settlement, but exceptions created more handoffs. Finance had to search across partner reports, bank statements, and email before Support could give the seller an answer.
Defining the scope
The brief asked for a drill-down. Discovery said scrap it.
Once I'd pulled the research together, I reframed the scope with the product team. The original ask was a drill-down. Discovery showed payment status was changing constantly as goods moved, so a static drill-down would be out of date within weeks.
We aligned on three principles that would guide every decision:
01
Lead with what needs attention
The 20% of transactions that are overdue, short, or disputed get the front page. The 80% that are fine sit one click away.
02
One number, three views
Finance, support, and the seller are all looking at the same payment. The view changes; the underlying figure doesn't.
03
Keep the systems in sync
A status change in finance has to show up in the support tool and the seller app the moment it happens. If the numbers can disagree, they will.
One end-to-end order flow across four Solv systems.
I mapped how an order moved through Commerce, OMS, Seller, and Finance, showing where each system acted and where payment status changed. The end-to-end view gave design, product, and engineering a shared reference for how the flow connected.
SOLV order flow — Commerce, OMS, Seller, and Finance
Every transaction moves through the same states. We mapped them before drawing a screen.
Underneath the order flow, every transaction moved through the same payment lifecycle: success, retries, chargebacks, refunds, across advance and balance payments. I mapped this before designing any screen, so the team could see exactly which state could lead to which.
Transaction process — success, retries, chargebacks, refunds across advance and balance payments
Aligning the solution
Two things were broken: what the screen led with, and how the numbers rendered.
We led with everything. Finance only cared about what was wrong.
Our initial wireframes showed everything at equal weight. Every transaction, every vendor, equal pixel real estate. We took it to a usability test with two finance team members.
"I don't need to see successful payments every morning. I need to see what's overdue." — Finance team member, usability test session
That sentence rebuilt the dashboard. The new version led with what was wrong (overdue, on-time, short-collected) and pushed the rest one click down.
Wireframe V1 vs V2 — flat hierarchy vs status-first architecture with drill-down
Design challenge · charting constraints
₹5,000 and ₹5 crore in the same chart: impossible on a linear scale.
A single dashboard view had to render five payment streams in one chart:
—PayU card and invoice payments, anywhere from ₹5,000 to ₹50 lakh per transaction
—Rupifi pay-later settlements
—EPay Later pay-later settlements
—Cash-on-delivery batches from the four logistics partners, up to ₹5 crore each
On a regular linear scale, ₹5,000 transactions vanished beside ₹5 crore batches. Engineering was using D3.js for data visualisation, and the project had limited scope for customising the production chart.
I looked at how other enterprise products handle wide-ranging data and explored logarithmic scales as a way to keep both ends readable.
I pulled a month of real transaction data and built a quick prototype in a code editor, comparing log and linear scales side by side. The log scale made ₹5K and ₹5Cr readable in one chart.
I brought the browser prototype to a working session with the developer and PM. It gave us a direction that worked with the existing D3.js implementation and its limited customization scope. Testing the trade-off this way saved weeks of back-and-forth.
Prototype & validation
A senior exec rejected the prototype, until we added Excel back in.
We built a Figma prototype covering the core Finance flows: dashboard, transaction view, UTR approval, payout. Usability testing with finance and internal stakeholders mostly confirmed direction. One session stopped the project in its tracks.
A senior finance executive reviewed the prototype and didn't want to move to the new system. Not because it was broken, but because it was unfamiliar.
He had worked in Excel for years. Our dashboard led with exceptions and vendor performance; Excel showed everything, always. Side by side, our dashboard looked like it was hiding information, even though it wasn't.
The question for the team wasn't "how do we convince him." It was "what is he actually losing that we haven't accounted for?" The answer was control: filtering, sorting, and exporting exactly the way he wanted.
We didn't change the design. We added a capability the design was missing.
We added import and export: Excel out for control, Excel back in for bulk updates. The executive adopted the platform. In the next phase, export management became a standalone feature that Operations and CRM actively asked for. A resistance fix turned into a cross-team feature.
Settlement Upload — the Excel bridge that became a cross-team feature
Final product
Seven views of the same money, each shaped around a different job.
Five views inside the internal tools, two on the seller side. The underlying numbers are the same in every one; what changes is what gets put in front of you.
The dashboard leads with what's wrong.
Collection status sits up top: overdue, on-time, short-collected, broken down by each of the three payment partners. The bar charts use a logarithmic scale so a ₹5,000 transaction and a ₹5 crore one are both legible in the same view (a fix that took me a side-quest into IBM's data-viz docs).
Every transaction, one ledger.
A filterable table of every transaction. Click a transaction ID and the row expands into a timeline of how that payment moved: captured, received, refunded, charged back, reversed. Same states the rest of the system uses. Export to Excel sits in the header for the people who still need it there.
Approve a bank transfer with the breakdown visible.
When PayU sends Solv a bank transfer, finance has to confirm the amount matches what's owed. The approval screen shows the transaction-level breakdown side by side with the bank reference. Rejections need a written reason, and the same note becomes the ticket finance raises with PayU when amounts don't line up.
What we paid the seller, line by line.
One row per payout: amount, bank reference, status. Expanding the row shows the deductions (commissions, taxes, returns, recoveries), and the breakdown matches exactly what the seller sees in their app. No reconciliation calls about "why is your number different from mine".
Payment context inside the support tool.
The full payment lifecycle now lives inside the order view that support agents already had open: payment method, settlement status, bank references. Tab-switching to PayU went away. Reply times that were measured in hours dropped to minutes.
Sellers see what stage their money is at.
Once an order is delivered, the timeline becomes visible: return window → settlement initiated → settled. Same words finance uses internally, so when a seller calls support, both sides are reading the same screen.
Web
Mobile app
Net earnings, with the maths shown.
Total payouts, bank reference, commissions, taxes, deductions, recoveries. Every figure ties back to the same row finance is looking at: no parallel spreadsheet, no version-control fight over which number is right.
Web
Mobile app
Impact & reflection
Settlements went from 7 days to 2. Support tickets dropped 67%.
I compared the quarter before launch with the quarter after the MIS and related features were released. Operations, CRM, and Finance supplied outcome data; MoEngage showed behavioural patterns and adoption. These results reflect the combined release, not the MIS alone.
67%
reduction in payment-related support tickets
Source: CRM team
7→2 days
average vendor settlement processing time
Source: Finance team
55% faster
daily reconciliation, same tasks, less time
Source: Finance team
10→2 days
average seller payout time
Source: Operations team
Minutes
to resolve payment disputes, down from hours
Source: CRM team
3 teams
adopted export management feature in Phase 2
Source: MoEngage
Beyond the numbers: ops stopped emailing spreadsheets to finance, and sellers stopped escalating to account managers. The conversation between teams shifted from arguing about figures to deciding what to do about them.
Three things I'd do differently. One I'd always keep.
Bring sellers into discovery earlier. We spent most of the research time on the vocal internal stakeholders. Seller insights came late and turned out to be just as load-bearing.
Don't underestimate UAT. I went in thinking it was sign-off. It turned out to be the most valuable feedback loop of the project: the Excel export feature came directly out of UAT resistance, not earlier research.
Document decisions in real time, not at the end. The log-scale call, the hierarchy rebuild, the export origin: I had to reconstruct all of it from memory later. Handoff and this case study would both be sharper if I hadn't.
The thing I'd always keep: mapping the full transaction lifecycle before designing anything. It sounds like overhead. It prevented at least three major scope disagreements and became the one document everyone (design, product, engineering) referenced throughout.
Working on something similar
Want to talk about it?
I'd love to hear what you're building. Get in touch.
