We cut a client’s application rejections by 90% — by letting the documents fill in the form
ProLend was not losing applications because the applicants were wrong. It was losing them because a human retyped what was already printed on a document, and got a digit wrong. So we stopped asking people to retype documents, and had the documents populate the profile instead.
Summary
- A private-lending network came to us for a brand relaunch. What they actually had was an operations problem wearing a marketing problem’s clothes.
- Applications were being rejected at a punishing rate — and almost none of the rejections were about the applicant. They were about paperwork: a transposed ID digit, a bank statement in the wrong name, a field a consultant filled in from memory.
- So we rebuilt intake around a simple inversion: the documents fill in the form, not the person. ID documents and proof of bank are read on upload and populate the client profile directly. Signature routes itself to applicant and consultant through an embedded flow that never leaves the ProLend brand.
- Rejections fell by roughly ninety per cent. Not because anyone got stricter — because an entire class of error stopped being possible.
The client, and what they were actually asking for
ProLend is a South African private-lending platform: a marketing and distribution business connecting people with capital to consultants who can structure a lending arrangement, across a network of about a hundred and fifty consultants. It is deliberately not the lender. It explains the structures, lets someone model an indicative scenario on their own numbers, and hands the conversation to a person.
The brief that arrived was a brand relaunch — a new front end, and an SEO strategy that could make ProLend the place South Africans land when they type what is private lending or how do I become a private lender into Google. That is what we were hired for and that is what we built: the marketing site, the indicative calculator that needs no sign-up, and the guide cluster underneath it that does the ranking.
Then we asked the question we always ask, which is what happens after someone converts. The answer was the real project.
Where the applications were actually dying
Applications were being rejected constantly. The instinct in that situation is to assume a quality problem — wrong audience, weak leads, consultants pushing unsuitable people through. That would have been a marketing diagnosis, and it would have been wrong.
When we looked at what the rejections had in common, they were almost entirely clerical:
- an ID number transposed by one digit between the document and the form;
- a name captured as it is spoken rather than as it appears on the identity document;
- proof of bank in a different name to the applicant, with no one noticing until it was reviewed;
- fields completed by a consultant from memory during a call, because asking the client to send the document again would stall the deal.
Every one of those is the same failure: a human retyping information that was already printed on a document they were holding. The application was not wrong about the world. It was wrong about the paperwork, and it got thrown out days later for it — after the consultant had spent their time, and after the applicant had gone quiet.
The bottleneck was not who was applying. It was that the truth was sitting in an attached document, and the form was being filled in from a phone call.
Letting the documents fill in the form
The fix was to invert the direction of trust. Instead of a person typing what a document says and attaching the document as evidence, the document becomes the input.
Identity documents and proof of bank are read on upload — OCR with a model doing the extraction — and the values it pulls populate the client profile directly. The consultant is no longer a transcription layer. They are reviewing a profile that was built from the source material, which means the ID number in the system is the ID number on the ID, because nothing ever retyped it.
This is unglamorous and it is the whole game. A field that no human ever types is a field that cannot be transposed. The class of error does not get reduced by better training or a stricter checklist; it stops existing, because the path that produced it is gone.
Signature is a routing problem, not a PDF problem
The second half of the loss was in what happened after the application was complete. A finished application that sits waiting for two signatures is not finished, and every hour it waits is an hour someone can change their mind.
So the application generates and routes itself. It goes out for signature to the applicant and to the consultant through the Zoho Sign API, embedded as an iframe inside a ProLend-branded page rather than bouncing the signer out to a third-party e-signature domain. Nobody is emailed a PDF and asked to print it. Nobody lands on a page carrying someone else’s logo at the exact moment they are being asked to trust the transaction.
Fee collection sits on the same rails, so the commercial side of an application settles as part of the flow instead of being chased afterwards.
Keeping the signature inside the brand is not vanity. The signing step is the single highest-anxiety moment in the whole funnel, and handing someone off to an unfamiliar domain at that exact moment is the most expensive design decision available to you.
What actually produced the 90%
Rejections dropped by about ninety per cent, and it is worth being precise about why, because the mechanism is more transferable than the number.
Nothing about the lending criteria changed. No one got better at filling in forms. What changed is that the two places errors entered the system were both removed — transcription was replaced by extraction, and the delay between complete and signed was replaced by automatic routing.
That is the pattern worth stealing: when a process has a high failure rate, look first for the step where a human is copying data that already exists somewhere authoritative. It is almost always there, it is almost never the step anyone suspects, and it is usually cheaper to delete than to police.
Where the front end and the pipeline meet
The two halves are one system, which is the argument for building both. The SEO work brings in someone searching is private lending safe; the calculator lets them model a number without giving anything up; the consultant picks up a conversation that has already been half-had; and the application that follows is built from documents rather than dictation.
ProLend also runs Crossdeck, so the arc from first search to signed application resolves as one person rather than an anonymous visit and an unrelated applicant. A consultant preparing for a call can see what that person actually read before they got in touch, which is the difference between a cold meeting and an informed one.
That is what we mean by bespoke work: not a website, and not a back office, but the whole path a person takes through a business.
Have a process losing people somewhere after the click?
That is the kind of work we take on for private clients.
Questions people ask
- How do you reduce application rejections with OCR?
- Most rejections in a document-backed application process are clerical rather than substantive — a transposed ID digit, a name captured by ear, proof of bank in the wrong name. Reading the uploaded documents and populating the profile from the extracted values removes the transcription step entirely, so that class of error can no longer be introduced. On ProLend this reduced rejections by roughly ninety per cent without changing any lending criteria.
- Can you embed Zoho Sign in your own branded page?
- Yes. The Zoho Sign API supports an embedded signing flow that can be rendered in an iframe inside your own page, so the signer completes the signature under your brand rather than being redirected to a third-party e-signature domain. This matters because signing is the highest-anxiety step in most funnels, and an unfamiliar domain at that moment costs conversions.
- Should you automate document intake before or after fixing marketing?
- Fix whichever one is losing more. It is worth measuring what happens after conversion before spending on more traffic — if applications are failing on paperwork, additional leads simply fail at the same rate and the spend produces nothing. In ProLend’s case the marketing brief was real, but the larger recoverable loss was sitting after the conversion, not before it.
- Does Cross Constellation take on client projects?
- Yes, a small number. ProLend is a client project — we built the front end, the SEO strategy, and the application pipeline behind it. It runs the same team and the same method we use on our own products, pointed at one organisation’s problem instead of ours.
The lesson
Find the step where a person retypes something that already exists. Delete it.
Read next
Why we built Crossdeck — and why every product we build helps test it
Every product is a test environment for the one beneath it
The Firebase bill that taught us to see
The email address you’re keying on is not the person
We got our connector rejected. It was the best product spec we received all year.
The black box blinks: seeing App Review happen in your own data
Why Biotree needed Crossdeck Trust — and how we stopped the SEO spam farms