A Field Agent's App Is Not a Smaller Version of the Web Portal
A responsive web view looks like a mobile app in a demo with full signal. A field agent finds out otherwise on the first doorstep visit with no connectivity, and by then it is the lender's problem, not the vendor's.
Every collections app looks the same in a vendor demo: full signal, a clean map, a visit logged in under a second. The test that actually matters happens somewhere none of that holds, a semi-urban route with patchy coverage, where the agent’s phone drops to no bars for three hours in the middle of the day’s rounds.
A field collections app has to work when the connection does not, log a visit in a way both sides can trust later, and issue a receipt the conduct rules actually require. A demo running on office wifi tests none of these. Three requirements separate an app built for the field from a web portal resized to fit a phone: offline-first architecture, geo-tagged visit logging, and a receipt tied to what RBI’s rules require an agent to carry.
A responsive web view passes every demo, because a demo never loses signal. It fails on the first real route, because a real route does. By the time that gap shows up, the agent has already lost a morning’s worth of visit records, and the lender is the one explaining to a borrower why there is no proof the agent ever came.
Requirement one: offline-first, not offline-tolerant
Offline-first means the app runs entirely on data already on the phone and queues every action for sync once a connection returns. A visit gets logged, a payment gets recorded, a promise-to-pay gets captured, all locally, all in order, none of it waiting on a network call to complete. Offline-tolerant means the app tries to degrade gracefully when a request fails, which in practice means a spinner that never resolves and an agent who has to remember what happened well enough to re-enter it later, hours after the fact, from memory.
The architectural difference is not a feature a vendor adds later. An app built around live API calls, retrofitted with a queue-and-retry layer bolted on top, still assumes connectivity is the normal case and offline is the exception. An app built offline-first assumes the opposite, and the request-response version simply becomes one more sync event, not the app’s only way of functioning. Asking a vendor “does it work offline” gets a yes from both kinds of app. Asking “does the agent’s UI look and behave identically for a full workday with the phone in airplane mode” only gets a yes from one of them.
Requirement two: geo-tagged visits settle disputes before they start
A borrower says the agent never came. An agent says they knocked and nobody answered. Without a record, this is one word against another, and it usually resolves in whichever direction the relationship manager’s patience runs out first. With a timestamped location attached to the visit log, it resolves against a fact neither side can dispute.
The same record works the other way too. It is the evidence a lender needs to show an RBI inspection, or answer a borrower complaint, that a visit happened, when, and roughly where. RBI’s conduct rules bar recovery calls and contact outside permitted hours, and a geo-tagged visit log is what turns “we follow the conduct rules” from a policy statement into something a lender can actually produce.
Requirement three: a receipt the conduct rules actually require
RBI’s Responsible Business Conduct Directions, 2025 require a recovery agent to carry a notice, an authorisation letter and an identity card, and require the borrower to be given the agent’s details when recovery starts, specifically for microfinance loans under paragraphs 95 and 96. None of that is optional paperwork a field app can skip past. If cash changes hands at the door, the app has to issue a receipt at that exact moment, tied to the borrower’s account and the agent’s identity. A borrower told the payment will reflect in the system by the next day has nothing in hand to prove they paid at all.
An app that cannot answer, on the spot, which identity credential the agent presented and what receipt the borrower was handed has built the workflow around the office, not the doorstep. The gap only costs something the day a borrower disputes a cash payment and there is no record beyond an agent’s word.
What a demo can’t show you
None of these three requirements shows up in a fifteen-minute vendor walkthrough run on the vendor’s own wifi, in the vendor’s own office, on a route the vendor chose. They show up on an agent’s actual first day, on an actual route, where the phone actually loses signal.
There are three honest ways to test for it before signing. Ask the vendor to demo the app in airplane mode, mid-session, and watch what breaks. Send a reference customer’s field ops lead the exact question: has an agent ever lost a day’s visit log to a connectivity gap. Or build in-house against a spec that names offline-first, geo-tagged logging and point-of-collection receipts as non-negotiable, at the engineering cost that comes with owning it. The LMS selection mistakes that have nothing to do with features covers the broader pattern this fits inside: a feature that works in the room it was demoed in is not the same claim as a feature that works where it will actually run.
Frequently asked questions
What makes a collections app 'offline-first' instead of just having offline support?
Offline-first means the app is built to run entirely on local data and queue every action, a visit log, a payment, a promise-to-pay, for sync once connectivity returns. Offline support usually means a responsive web view that fails or freezes the moment the connection drops, then requires the agent to redo the work. The difference only shows up in the field, never in an office demo with full wifi.
Why does geo-tagging a field visit matter for an LMS?
It turns a disputed visit into a checkable fact. When a borrower says an agent never came, or an agent logs a visit that did not happen, a timestamped location on the visit record settles it without relying on either party's memory. It also gives a lender the same evidence an RBI inspection or a borrower complaint would ask for.
What does RBI actually require a field collection app to capture?
RBI's Responsible Business Conduct Directions, 2025 require a recovery agent to carry a notice, an authorisation letter and an identity card, and require the NBFC to give the borrower the agent's details when recovery starts, for microfinance loans specifically under paragraphs 95 and 96. An app that cannot show which identity credential a field agent presented, or issue a receipt at the point of cash collection, leaves the paper trail these rules assume exists somewhere else, usually nowhere.
Should a lender build a field collections app in-house or buy one?
It depends on how much this is a differentiator versus a utility. Building gives full control over the offline architecture and the exact fields a lender's policy requires, at real engineering cost. Buying a point solution ships faster but adds an integration to maintain against the core LMS. An LMS whose collections module ships a native offline-first mobile app removes that integration entirely, at the cost of depending on that vendor's own roadmap for it.
Read next:
- RBI’s recovery agent rules for NBFCs: the conduct window and documentation requirements a field app has to support, not just avoid violating.
- NBFC collection strategy by bucket: where field visits fit inside a full collections cadence, and which buckets rely on them most.
- The LMS selection mistakes that have nothing to do with features: why a feature confirmed in a demo is not the same as a feature confirmed in the field.
Chandramouli is the co-founder and CEO of Lokta, the agentic loan servicing platform. He has spent two decades building AI for decisions that change people’s lives, and has served as an independent director on an NBFC board. He writes here about the gap between what a demo shows and what an agent’s actual workday requires.
