Rise Portal · Rupeezy · 2024 · My first project at the company
Refer more. Earn less. No way to find out why.
Designing trust, visibility and transparency for the partners behind 35% of company revenue.
01 — The problem
The phone call that happened a hundred times a day
Rupeezy’s digital partners are experienced traders and financial content creators — people with an audience that trusts them on money. Around 100 partners worked this way. Together, they drove roughly 35% of Rupeezy’s revenue. And the entire relationship ran on spreadsheets and phone calls.
How the model works
{{ m.text }}
A partner wanting to know how many of their leads had converted would call their relationship manager. The manager would open a spreadsheet, check manually, and read the numbers back. A hundred partners, referring people daily, each entitled to ask at any time. Payouts landed on the 15th of every month, calculated somewhere the partner couldn’t see. Now imagine the partner’s side of it.
“Last month I referred 100 people and earned X. This month I referred 200 — and earned less. Why?”
There’s a legitimate answer — earnings depend on how many leads completed KYC, how many clients actually traded, and how much. But the partner can’t see any of that. All they can see is that they did more and got less. When a third of your revenue flows through people who can’t verify their own income, you don’t have a reporting gap.
Not a reporting gap
You have a trust problem.
02 — Groundwork
Learning a business I’d never seen
This was my first project at Rupeezy. A PRD landed from the PM, and it was full of words I didn’t know — digital partners, brokerage share, payout cycles, lead-to-client conversion. So before designing anything, I learned the machine: I sat with the PM to understand how the partner business worked and where the money moved, and with the support team to go through what partners actually asked — the daily queries, the repeated questions, the complaints. Two questions dominated everything:
I never spoke to a digital partner directly — I’ll come back to that at the end, because it’s the honest limitation of this project. What I had was the next best thing: the people who answered their calls every day.
03 — The design
Make the funnel visible
{{ fin.title }}
{{ fin.body }}
{{ fin.caption }}
04 — The mechanism
The mechanism nobody was paying for
A partner sees a lead stuck at “account processing.” That lead is money sitting one step away from becoming a client. So the partner calls them — is something wrong with the registration? Can I help? That call used to be Rupeezy’s job. Support teams chase stuck registrations everywhere. But the partner’s call works better, because the lead already knows and trusts the person who referred them — that’s why they clicked the link in the first place.
Same with the inactive clients list. An inactive client earns the partner nothing, so partners re-engage them — nudge them back to trading — because their income depends on it. Nobody instructed partners to do follow-up. The product made their pipeline visible, and self-interest did the rest: Rise Portal quietly turned 100 partners into a distributed sales and support layer — one that costs nothing and converts better than cold calls from an unknown number.
The biggest outcome wasn’t a screen. It was a behaviour.
Why it worked
Every lead a partner can see is a phone call we no longer have to make.
05 — Constraint
Designing inside compliance
As a regulated broker, we cannot expose client phone numbers — not to partners, not to anyone. Numbers render masked: XXXXXX7890. Which creates a tension, because the whole mechanism above depends on partners being able to contact their own referrals.
The resolution came from how partners actually work. These are people running a business — most collect contact details themselves when they refer someone, through their own forms and conversations. What they need from the portal isn’t the number. It’s the match: a name, the masked digits, and the status, so they can connect what they see in the portal to the records they already hold. We didn’t fight the constraint. We designed the smallest sufficient signal around it.
06 — Eligibility
Making “X AND (Y OR Z)” readable in a glance
Partners don’t automatically get paid every cycle. The business set a compound rule — to keep partners driving real trading activity rather than collecting signups. The rule wasn’t mine. My problem was making it legible: partners needed to read their own status in a glance, not parse a logic expression.
The card shows each condition as its own fraction, the AND/OR relationship visible between them, and a plain-language warning when the partner is short: “Currently, you’re not eligible for payout.” A partner three clients short can see precisely which lever to pull.
Eligibility as fractions — every condition its own lever.
Where this card sat caused the one real disagreement of the project. The business team wanted eligibility at the top of the dashboard — it decides whether a partner gets paid, so surely it’s the most important thing on the page. I argued placement should follow frequency, not importance: eligibility is one-time information — a partner needs it while working toward the threshold, and stops looking at it once they’ve met it. Earnings and clients are what a partner checks every single visit. Prime position went to the daily information; eligibility went bottom-right — visible, not dominant. I also considered hiding the card entirely once a partner qualified, and rejected it: a dashboard that rearranges itself depending on state is worse than one stable layout.
Design principle
Important and frequent are not the same thing. Layout should follow frequency.
07 — Responsive
One product, two screens
Rise Portal shipped as responsive web, and I designed both ends of it. Partners check earnings from wherever they are — the mobile layout keeps the same four sections (Dashboard, Earnings, Clients, Updates) in a bottom navigation, with the charts and tables restacked for one hand and one thumb.
Updates carries the messages that used to be phone calls — payout eligibility warnings, cycle information, service notices — filterable by type. The channel that used to interrupt a relationship manager’s day became a feed the partner checks on their own time.
08 — Results
What happened
{{ r.title }}
{{ r.note }}
One caveat I attach to my own numbers: Rise Portal was isolated to digital partners, and the commission structure didn’t change in that window — but I’d still want to verify nothing moved on the payout side before claiming clean causality. I didn’t own the analytics; I’m reporting what the teams closest to the data reported.
09 — Honesty
The part a portfolio usually hides
Three things were true about this project that case studies don’t usually admit.
I never spoke to a digital partner.
Everything I knew about them arrived second-hand — through the PM, and through the support team who answered their calls every day. It was fast, and it was enough to ship. But every insight passed through someone else’s summary first. The follow-up behaviour I described above, I learned about after launch. Five direct conversations before designing might have surfaced it early enough to build the product for that behaviour, instead of merely enabling it and finding out later.
The numbers came from my own curiosity, not from a plan.
Rupeezy didn’t do post-release analysis; nobody agreed upfront what this product was supposed to move. The 2.4x and the 48% exist because I went and asked the business and support teams myself. I stand behind how I got them — but a metric you chase down afterwards is a weaker thing than a metric you committed to in advance.
I won the placement argument with reasoning alone.
I’d rather have won it with five partners’ behaviour on a screen recording.