Case study · RB Saathi
RB Saathi is the field sales app behind RenewBuy's FLS and DST teams. Only 58% were actively using it, leads sat scattered across channels with no real-time tracking, and supervisors had no reliable view of who met whom.
Project overview
Rollout followed UAT with stakeholders and a final round of iterations, released to all FLS and DST teams across India. Engagement is the only metric here with a stated baseline. Lead-to-meeting and conversion figures are post-rollout readings over the same three-month window.
Context
RB Saathi lets sales teams manage partner and customer leads, schedule meetings, track daily tasks and hit targets in one place, while supervisors read the team's productivity in real time.
That second half was the part that had stopped working. With only 58% of the team logging their work, supervisors were managing on hearsay, and lead data was being kept in personal channels rather than in the system where it could be governed.
Nothing in the app was broken. It asked the team to record their day and gave them almost nothing back for doing it, so they stopped, and everything downstream of that recording went dark.
Stakeholder interviews and synthesis. The existing-design audit. The empathy map. Customer management and meeting flows. Dashboard information architecture. Handoff and UAT support.
The second designer's scope. PM-owned requirements and prioritisation. Backend lead-source integrations. Release engineering on both platforms.
FLS work in the field, DST work the phones from an office, supervisors read both. One interface had to serve all three without becoming a settings menu.
A redesign of a product already in daily use. Flows could be restructured and screens replaced, but existing integrations and data models stayed.
Android and iOS shipped together, so every pattern had to hold on both without platform-specific exceptions.
Two designers, two PMs, one app dev team. Scope had to split cleanly enough that two people could work in parallel.
Three teams
The engagement number was really a value-exchange problem. Work flowed upward and nothing came back down, so the people doing the entering had no reason to keep doing it.
First Level Sales. The field team onboarding and managing advisors and customers across India.
Meetings, attendance, lead status, follow-ups
Nothing that helped the next meeting
Own customers, clearer leads, faster query resolution
Direct Sales Team. Office-based, handling customer and partner queries over the phone across India.
Call outcomes, partner and customer queries
No visibility into what the field had already done
Shared lead status across both channels
Manages the FLS and DST teams and tracks their performance. The user whose need went unmet when engagement dropped.
Nothing. Reads only.
An incomplete picture from 58% of the team
Verifiable meetings, attendance and lead movement
The problem
Low engagement was the headline number. It was a symptom of three other things the app was failing to hold.
With four in ten users inactive, supervisors had no clear view of their team’s work or efficiency, and business data was being held outside the system where it could not be governed.
Partner and customer leads arrived through multiple channels and were reconciled by hand, creating a standing dependency on FLS members and sales agencies to remember to update a status.
Meeting and attendance data from the field was not clearly visible to supervisors or admins, so neither activity nor presence could be reliably tracked.
Weak tracking meant follow-ups were missed and conversions lost, with no record of where in the sequence a lead had gone cold.
Supervisors could not see the work, so the team had no reason to log it.
Research
Stakeholder interviews with FLS, RMs and the operations team, an audit of the existing screens, and an empathy map for the sales user.
FLS members were doing direct customer work the app had no place to record, so that work happened outside the system entirely. Anything the app could not hold, it also could not report on, which is where the supervisor visibility gap started.
Meeting records, attendance and lead status all flowed upward and nothing flowed back down. Without a reason to log, the team stopped, and engagement was the number that showed it.
Payouts and upcoming renewals sat several taps deep while less-used options held the top of the screen. Every session started with a hunt, a tax on the exact behaviour we were trying to increase.
Why is the FLS team not actively using the app?
What causes leads to scatter across multiple channels?
How do FLS members run meetings and mark attendance?
What do they face day to day in the field, with partners and customers?
What makes capturing direct customer leads difficult?
How might we
Increase and monitor FLS daily activity for supervisors.
Improve the lead-finding experience for FLS.
Improve how meeting feedback is recorded and meetings rescheduled.
Increase partner and customer lead management.
Improve direct customer support and visibility for FLS.
The work
Every decision removed something. The cost line is the part I would want to be asked about, so it sits on the page rather than in my head.
The app modelled the world as partners only. Direct customer work had no home in it, so it was tracked in personal channels or not at all.
A dedicated customer management flow alongside the partner flow, with a section showing both the FLS member's own customers and the partner's customers.
Two parallel object types to design, build and maintain, and a decision forced on the user at the entry point that they did not previously have to make.
Meeting and attendance data was not reliably visible to supervisors, and the rescheduling path was buried, so records were incomplete rather than wrong.
Rebuilt scheduling and rescheduling, made the lead-to-meeting CTA explicit, and moved feedback capture into the meeting flow itself.
More steps inside the meeting flow for a team usually between appointments. We accepted the friction because the capture is what makes the record trustworthy.
Every session opened with a hunt. The screen was ordered by what the business wanted to show, not by what the team opened the app to do.
Promoted payouts and upcoming renewals, removed options with no daily use, and reworked supporting screens to match the new integrations.
Demoted features lost their home-screen slot, and their owners lost visibility. A stakeholder cost as much as a design one, and it needed evidence to defend.
Customer queries were resolved away from the field, so the FLS member holding the relationship could neither see the status nor act on it.
Gave FLS ownership of customer interactions with real-time query visibility and resolution in the app, so the answer comes from the person already in the conversation.
Support load shifts onto the field team, whose time is the scarcest on the project. It only holds if resolution stays fast enough not to eat selling hours.
What shipped
Released to all FLS and DST teams across India after UAT with stakeholders and a final round of iterations.
Wireframes, flows and UAT
Impact
| Metric | Before | After | Window | How it was measured |
|---|---|---|---|---|
| App engagement | 58% | 84%+26 pts · +45% relative | 3 months | Active use across FLS and DST teams, all-India, post-rollout |
| Partner lead to meeting | Not baselined | 68% | 3 months | Partner leads converted to a scheduled meeting |
| Customer lead to meeting | Not baselined | 47% | 3 months | Direct customer leads converted to a scheduled meeting |
| Partner lead conversion | Baseline | +14% | 3 months | Improvement in partner leads converted to a sale |
| Customer lead conversion | Baseline | +3.7% | 3 months | Improvement in direct customer leads converted to a sale |
Platform analytics measured against the pre-launch baseline for the same teams, rounded, after UAT with stakeholders and a final round of iterations. Engagement is the only figure with a stated before and after. The lead-to-meeting rates are post-rollout readings without a published baseline, and the conversion figures are stated as improvements rather than absolute rates. Design was one of several changes in the window, so I do not claim these as design-only.
Read separately
These are two different audiences with two different sales motions. Averaging them into one headline number would hide the thing that is actually interesting.
Partner leads arrive warm through an existing relationship. Direct customer leads do not, which is most of the 21-point gap.
Bars are scaled to each other, not to a fixed ceiling. The direct customer flow was new at launch, so it had further to travel and less history to lean on.
Retrospective
Each one changed how I scope the next project.
68% and 47% read well, but without a before, neither number can prove the redesign did anything. I now agree the measurement plan with the PM in week one, not after rollout, and treat an unbaselined metric as an unusable one.
Supervisors were the users whose unmet need caused the engagement problem, yet they came second in the research order. Mapping every role that reads the data, not just the ones that enter it, is now the first thing I scope.
We separated the two paths and cannot say which one the team actually lives in, or how often they cross between them. That leaves the next phase of the split to guesswork.
Next case study
Redesigned the advisor app into a task-first experience. Added a self-learning feature and cleaner daily task flows so partners can onboard and act without help.
Get in touch
Open to senior product design roles in fintech and insurance (B2C, B2B, and SaaS).