The Problem
Bajaj Finance's app and web had a lot of collections infrastructure already: 18+ notification types, 6+ pop-ups, 14+ nudges, 12+ tickers, banners, loan cards, multiple search entry points. All of it designed to get delinquent customers into a payment or service journey.
Self-serve repayment rates were still low. Customers bounced out, dropped off, or didn't engage.
The instinct was to fix specific touchpoints: sharper notification copy, more prominent banners, a smoother payment screen. But that assumes customers are leaving because of friction at a known step. The question we hadn't actually answered was: when a customer lands on any of these surfaces, what are they trying to do, and does what they see match that?
What I Found
I mapped the lifecycle of 36L delinquent customers from loan onboarding through EMI bounce, post-bounce intervention (automated voicebot and notification campaigns, allocation, tele-calling, field visits), and into remedial stages (settlement, restructuring, surrender, bureau correction). For each stage, I tracked which digital touchpoints were active and where customers were being routed.
The main thing I found: every delinquent customer was being sent to the same set of digital surfaces regardless of where they were in their lifecycle.
A pre-bounce customer with an upcoming EMI and a customer in active legal proceedings landed on the same pages, saw the same information, and were asked to take the same actions. Their actual next step was completely different. The pre-bounce customer needed to pay or register a mandate. The settlement-eligible customer needed to understand an offer before it expired. The customer in bureau correction needed to raise a request through a specific flow. The customer with an allocated agent needed to know who was coming and when. We had one experience covering a dozen genuinely distinct situations.
The second finding was a channel continuity problem. Bajaj's collections model touches customers across multiple channels: the app, web, branch, WhatsApp, email, field visits. The intent was for a customer who starts a service journey on one channel to continue it on another without losing their place. In practice, that wasn't happening. A customer who initiated a payment through a WhatsApp communication and dropped off mid-way had to start from scratch if they walked into a branch or came back to the app. There was no single place in the digital product that held the complete picture of where a customer was in their lifecycle and what they needed to do next, regardless of how they'd got there.
The root issue was that while bits and pieces of the collections and servicing journeys existed in the app, they were scattered across different surfaces with no single destination tying them together. A delinquent customer had no one place to go to complete their entire journey digitally.
We benchmarked against Amazon, Airtel, and Vodafone. The pattern was consistent: for complex service journeys, a category landing page that aggregates status, actions, and support in one place outperforms scattered deep-link notifications.
What I Did
Created a category landing page as a single destination in the app and web covering the complete customer lifecycle from pre-bounce through remedial stages. The goal was that any delinquent customer, regardless of which channel they'd previously interacted through, could land here and complete their journey without needing to go anywhere else. Internally, we named the product Pay EMIs, chosen for clarity across language groups and because it described the action plainly without the stigma some of the more collections-specific names carried — this write-up uses its functional name, Category Landing Page (CLP), throughout. Naming took real iteration: EMI Pay Zone, EMI Sathi, EMI Samdhan, Repayment Assistance, and 20+ others before we got there.
Designed the CLP around four static tabs, each grouping a distinct customer need:
- Make Loan Payment — all loan cards with dedicated payment actions, plus loan details and statement of account; sub-tabs within this section separate settlement-eligible, overdue, and non-delinquent loans
- Financial Details — overdue amounts, EMI breakdowns, and contextual nudges
- Communication History, Statements & Documents — a single place for all records and documents
- Payment Options — an overview of all available payment modes
Layered within the page:
- A personalised banner strip, configurable by customer segment
- Change Bank Account (for mandate updates)
- Services for You carousel, hosting banners for different service use cases
- A dedicated section for collection-related services
- Chat with Us and FAQs
Built entry points across the app and web so no customer had to search for it:
- Bottom navbar (dedicated CLP tab — primary and always visible)
- Homepage (banner)
- Direct notification deep-links
- Search
Mapped 30+ customer journeys through the CLP, from pre-bounce through remedial, each scenario tied to an entry point, the CLP state the customer sees, and where they land next.
What Changed
| Metric | Result |
|---|---|
| Uplift in unassisted digital repayments | +45% |
| Navigation placement | Primary placement across app & web |
The 45% uplift in unassisted digital repayments was the main outcome. "Unassisted" means customers completing payment or service journeys without agent or tele-caller involvement. That number tells you whether the product is doing its job, and it moved.
Getting the CLP into primary navigation across app and web was a separate win. The 36L customer base now has one findable place for every collections-related action, rather than reaching it only through a notification or a specific deep-link.
What I'd Do Differently
The naming process took too long. We ran through 20+ options and evaluated them through internal discussion. For a product where the name directly affected how customers felt about engaging with it (stigma was a real concern), we should have run a quick preference test with actual customers before locking in. The outcome was fine; the process was slow.
The second thing is about scope. We went into V1 with four tabs, a personalised banner strip, sub-tab logic within Make Loan Payment, and several supporting components all at once. In hindsight, I'd have pushed for a leaner V1: get the core payment journey working end-to-end in one tab, ship it, learn from real usage, and then build the rest. We had strong conviction from the lifecycle mapping about what customers needed, but conviction about the right destination isn't the same as conviction about the right build sequence. A faster, thinner V1 would have gotten us to real usage data sooner and let the subsequent components be built with more signal behind them.