The Problem
DMS One App is the primary tool for 1L+ field agents across Bajaj Finance's debt management function. Every month it handles 140L+ case detail searches, 55L+ calls, 52L+ feedback captures, and ₹1,000+ Cr in payment volume.
Agents doing all of that were working with day-old data.
A field agent visiting a customer had the loan agreement details and the outstanding EMI. What they didn't have: whether that same customer had paid for a different loan account that morning, or whether a tele-caller had reached them two hours earlier and gotten a promise-to-pay, or whether the customer had started a digital payment and abandoned it mid-way, or whether a legal notice had gone out since the last sync.
Any of those details changes how a good agent approaches the conversation. None of them were in the app. Agents either called back to the office to check, made decisions without the context, or showed up to a visit the data would have told them to handle differently.
What I Found
The data existed. Real-time payment events, digital journey drop-offs, tele-caller dispositions, settlement offer status. All of it sat in various sources: the core collections database, the loan management system, the payment gateway, the data lake. The problem was that none of it reached the agent interface in time to be useful.
The structural issue was how new data got into the app. Every new data point required a version release. A business team would spot something worth surfacing, it would go into a sprint, get built and shipped, and by the time agents had it, the specific moment that made it valuable had often passed. The app's ability to display data was tied to its release cadence.
Two gaps were costing the most in practice.
Cross-LAN payments. When a customer with multiple loans paid for one of them, agents visiting for another often didn't know. They'd push a customer who had already paid, wasting the visit and, in some cases, damaging whatever goodwill existed.
Digital journey drop-offs. When a customer started a payment on the Official Online Payment channel and abandoned it, the agent had no visibility. They'd follow up without any context about where the customer got stuck.
What I Did
Built a configurable data-insight layer on top of the existing app, designed to push near-real-time data to agents anywhere within DMS One App without a new release for each data type.
A standardised table in the Data Lake. Any business vertical could load LAN-level or customer-level data here: payment events, drop-off signals, legal status, settlement details. Records are priority-ranked so the most critical insight for a given case appears first.
A template configuration layer at the App DB. Static content (titles, labels, explanatory text) is configured once per template type. Variable data (the actual amounts, dates, flags for each customer) gets pulled from the Data Lake at runtime. A new insight type can be designed and deployed without touching the app codebase; no sprint, no release required.
A PWA display layer in the app. A Progressive Web App page, triggered by configurable events in DMS One App, renders the right data card in context: on the case detail page for customer-specific insights, on the homepage for team- or business-level information.
Data latency target: under one hour from event to display. A customer's morning payment would be visible to a field agent arriving for a visit by midday.
First four use cases, chosen to stress-test the architecture:
- Cross-LAN payment status (did this customer pay for another loan recently?)
- Digital journey drop-off (did they start and abandon a payment in their last session?)
- Tele-caller disposition (Promise-To-Pay (PTP) and other resolutions, visible to field agents before the visit)
- Settlement offer status (what options are on the table before the agent walks in?)
What Changed
The data-led layer is live. The outcome that matters most is what it changed about how quickly a new insight reaches an agent.
Before, any new data point required a full sprint cycle to reach the app, typically one to two months, competing with every other feature in the queue. Now, adding a new insight type takes one to two days at most: create the database entry, load the data for that use case, and configure the template. No code change, no release, no wait. The work that used to take a sprint now takes a day.
At full deployment across the four initial use cases, agents go into each visit with context they previously had to call in for or work without. Cross-LAN payment visits to customers who already paid will drop. Drop-off follow-ups will have something to work with beyond a cold retry notification.
What I'd Do Differently
The hardest part of this build wasn't technical. Getting business verticals to commit to a data format took the most time. Different teams had different standards for data freshness, different owners, and different willingness to work within a structured table schema. We spent longer than expected getting the Data Lake schema locked before development could fully start.
If I were doing this again, I'd treat the data contract (format, latency, owner, refresh schedule) as a gate to get onto the roadmap, not something to sort out during the build. We handled it in parallel with development because we were trying to move fast. It slowed us down instead.
I'd also have started with two use cases rather than four. The architecture needed one clean end-to-end proof before we added use cases with different data owners and different schema requirements. We got through it, but the scope in early sprints was wider than it needed to be.