A CRM that verifies the lead before an agent ever picks up the phone
A custom loan CRM for a financial services operation, with an OTP-gated public intake that captures live KYC evidence, auto-routes every lead to the right agent by category and location, and carries it through to qualified.
The CRM takes a lead from first visit to a qualified record. Loan processing, underwriting, credit decisioning, disbursement and repayment were outside scope and handled by the client's existing arrangements.
- SECTOR
- Financial services
- TYPE
- Custom CRM
- STACK
- EDIT-STACK
- TEAM
- EDIT-TEAM
- CLIENT
- Under NDA
Most CRMs inherit whatever the website sends them
A conventional CRM begins where the lead lands in it. Whatever arrived, arrived — a name, a number that may or may not connect, an enquiry that may or may not be serious. Agents then spend their day separating the real from the rest.
For a lending operation that is expensive in a specific way. Qualification requires identity, income evidence and bank statements. If none of that arrives with the lead, every one of those items becomes a phone call, and agents spend more time collecting documents than assessing applicants.
We built the capture layer as part of the CRM rather than treating it as someone else's form. Verification happens before the record exists, not after an agent chases it.
That decision reshapes both ends. Leads enter the CRM already verified, with KYC evidence and financial documents attached. And because capture belongs to the CRM, the order in which it asks is a design decision the CRM owns — which matters, since every field added loses leads and every field removed admits ones that are not real.
The intake layer: six steps, in this order for a reason
This is the CRM's front door. A lead completes it in public, unassisted, before any agent is involved.
Mobile number, confirmed by OTP
Nothing else is asked first. Ten seconds of effort, and it establishes a contactable, verified number before any personal data is collected. Every applicant who stops after this point still leaves the business a real number.
Basic details
Name and core identifying information. Low friction, and enough for an agent to hold a conversation if the applicant stops here.
KYC: face video, ID held to camera, ID upload
The applicant records a live face video, is captured holding their identity document, and uploads the document itself. Three signals that have to agree with each other.
Bank statement upload
The heaviest ask in the flow, placed after identity is established rather than before. An applicant who has completed a video KYC step is materially more likely to finish this one.
Employment, income, purpose and amount
Employment type, monthly earning, loan purpose and requested amount. The amount field is bounded by server-side rules keyed to applicant category and declared income.
Submit
The lead becomes a CRM record with its evidence attached, and is routed to an agent immediately.
The ordering is the design. Asking for a bank statement on the first screen collects very few. Asking at step four, from someone who has already verified a phone number and completed a KYC capture, performs differently — sunk effort works in both directions.
Why the KYC step has three parts
An uploaded identity document proves someone possesses an image of a document. That is a low bar, and it is the bar most online applications clear.
Capturing a live face video raises it — the applicant has to be present, not simply holding a file. Capturing them holding the document raises it again, because the person and the document now have to appear together in the same frame at the same moment. Together the three signals make casual impersonation with a borrowed or purchased document considerably harder.
Capture on real devices
Video capture in a browser behaves differently on every Android manufacturer and iOS version. Most of the engineering time in this step went here, not into the logic.
Bandwidth reality
Applicants complete this on mobile data of varying quality. Capture had to degrade gracefully and resume rather than fail and restart the step.
Guidance during capture
People do not naturally know how to hold a document to a camera legibly. Clear on-screen prompts reduced unusable captures more than any change to the capture itself.
Human review, not automated matching
The captures are evidence for an agent to assess, not an automated identity decision. Nothing is approved or rejected on the strength of a face match.
Eligibility limits belong on the server
Requestable amounts are bounded by rules combining applicant category with declared monthly income. The rules live in the back end and are configurable without a release, because they change with business policy rather than with the software.
Keeping them server-side is not an architectural preference. The requested amount is the single field an applicant has most reason to manipulate, and any limit enforced only in the browser is not a limit. The client sees the bound; the server decides it.
Applying the rule during the form rather than after submission also does the applicant a favour. Someone asking for an amount their declared income cannot support learns it immediately, instead of waiting for a call that says no.
What the agent desk does
A completed intake becomes a CRM record and is assigned automatically. Auto-tagging routes it to an agent based on applicant category and location, which removes a manual triage step that would otherwise sit between the lead arriving and first contact — the interval where interest decays fastest.
From there the agent works a conventional qualification desk: review the record and its captures, call the applicant, verify what was declared, correct contact details, record the conversation, and advance the status. A lead that stands up to that is marked qualified.
Partial leads are still leads
Because each step is saved as it completes, an abandoned intake does not vanish. It exists in the CRM as a partial record, and that changes what the business can do with it.
Someone who verified their number and gave basic details but stopped at KYC is a contactable person with a stated interest in borrowing. A conventional website form would have discarded them. Here an agent can call. In most operations that recovered segment is larger than the completed one.
It also gives the CRM a funnel report nobody had before: exactly which step loses people. If a disproportionate share stop at the bank statement upload, that is a specific, fixable finding rather than a vague sense that intake is too long.
The data this system holds
Face video, identity documents, bank statements and income declarations, for members of the public, collected through a form anyone can open. It is close to the most sensitive combination a business can hold, and it shaped the build.
Assignment-scoped visibility
Agents see the leads assigned to them rather than the full database. A qualification desk does not need a browsable archive of identity documents.
Controlled document handling
Captures and uploads are stored against the lead record with access restricted to assigned staff and supervisors.
Action history
Status changes, edits and access are recorded, so any question about who saw what can be answered rather than estimated.
DPDP obligations
The operating business is the Data Fiduciary under India's Digital Personal Data Protection Act. Consent at collection, purpose limitation and retention of face and document data are its obligations, and full enforcement begins 13 May 2027.
How the team built it
GegoSoft engineers use Claude Code as standard daily tooling. On this build the concentration was on validation and on the eligibility rule engine — the parts where an edge case is a business consequence rather than a cosmetic bug.
The step ordering, the three-part KYC capture and the decision to keep identity assessment with a human rather than automate it were the team's. Every change passed normal review before merge.
Where it stands
EDIT-STATUS — confirm whether the system remains in use and whether the client permits any figures above to be published.
Common questions
Can GegoSoft build a loan CRM for us?
Yes, covering lead capture, KYC collection, agent routing and qualification. Underwriting, credit decisioning, disbursement and repayment are a different scope and were not part of this build — we would tell you plainly where our experience ends.
Why build a custom CRM instead of configuring an existing one?
Try configuring one first — where it works, it is cheaper. It tends to break when the capture layer has to be part of the CRM rather than a form feeding it: OTP-gated entry, live KYC capture, server-side eligibility rules and per-step persistence are not things a standard CRM's web form will do.
Why capture a face video as well as an ID upload?
An upload only proves someone has an image of a document. A live capture requires the person to be present, and capturing them holding the document puts person and document in the same frame at the same moment. Together they make casual impersonation considerably harder.
Does the system approve or reject applicants automatically?
No. Eligibility rules bound the requestable amount, but identity assessment and qualification are done by an agent. Nothing is approved on the strength of an automated match.
Doesn't a six-step intake lose leads?
Fewer than you would expect, and the ones it loses are not lost. Verification comes first because it costs almost nothing, the heaviest upload comes after identity is established, and every step is saved as it completes — so an abandoned intake still becomes a contactable CRM record rather than nothing.
Do you build other back-office and qualification systems?
Yes. We have built custom CRMs for travel agencies, professional training organisations and passport assistance services. The common thread is a workflow with document dependencies and human verification.
Agents spending their day chasing documents?
Tell us what your CRM receives today and what your agents have to collect afterwards. Moving verification into the capture layer is usually where the time goes back, and that is the first thing we would look at.
Start a conversation See all case studies