Tales & Co.

Istanbul — San Francisco

Notes

Diagnosis before solution

6 min read

Banks Lose Applicants Where the Funnel Stops Looking

Banks lose applicants during digital account opening in more than one way, and the funnel report records them all as a drop at the last screen touched. The loss that decides the number often happens after the applicant has pressed submit, in systems the funnel was never built to see.

A bank losing applicants in digital account opening usually measures the loss at the last screen they touched.

The report looks the same in most banks. A funnel runs from the first screen of the application to the confirmation page, each step shows how many sessions reached it, and the steps with the steepest fall are coloured red. Identity verification is usually one of them. Document upload is often another. The conversation that follows is about those screens: fewer fields, a clearer camera prompt, a progress bar, verification moved later in the flow.

The redesign that moved little

A digital bank we worked with had run that conversation twice. Its product team had redesigned the application form, then rebuilt the identity step with a new verification vendor, and each release improved the screens it touched. The number the executive team watched, applications that became funded accounts, barely moved. The team's reading was that the remaining friction was harder to find. The friction was not hidden. Most of the applicants the bank was losing had already left the funnel's field of view before they were lost.

That is the condition this note is about. The funnel is an instrument built by the digital team, and its boundary is the app. It counts what happens on screens, and it ends at submit, because that is where the digital team's ownership ends. The applicant's journey does not end there.

Applicants leave account opening in at least four different ways, and the funnel records them as one.

Four ways out

When the lost applicants at that bank were followed one by one, they fell into four groups, and the same four turn up in most account-opening flows we have looked at since:

  • applicants who left mid-flow and decided not to come back, because the product, the price or the request no longer seemed worth it
  • applicants who left to fetch something, a payslip, a utility bill, a second device, and found on return that the session had expired and the application had to be started again
  • applicants who submitted and then waited on the bank, referred for manual review or asked for a further document by a message they did not expect
  • applicants the bank turned away, declined by an automated rule, some of them by a rule nobody in the bank could still explain

Only the first group is the one the redesign was aimed at. The second looks identical to it in the analytics: a session that ends at the document step. The third and fourth do not appear in the funnel at all, because by then the applicant has pressed submit and the funnel has counted them as a success.

Why the instrument blurs them

After submission the applicant lives in other systems. The verification vendor holds the outcome of the identity check. A case management tool in operations holds the referrals and the requests for more information. The account platform holds who was opened and who funded. Each of these is owned by a different function and reported in a different meeting, and none of them is joined to the app analytics by default. A bank can watch every screen of its application and still have no single place that says what happened to the people who completed it. The same gap between what a brief can see and what is causing the number is set out in the work before the work.

The diagnosis follows applicants across systems, not steps across one.

Tracing a cohort

The method is plain and slower than reading a dashboard. We take one month of applications and follow each one by its reference number through every system it touches, from the first screen to the first deposit or the last contact. Each applicant who did not become a funded account is placed in exactly one of the four groups. The question at every step is not how many left, but where this person was when the bank stopped hearing from them, and who inside the bank was holding their file at that moment.

At the bank, the trace reordered the problem within a few weeks. The largest group had submitted. They sat in a referral queue, and when a further document was needed the request went out by email from an unmonitored address, often days after the applicant had last thought about the bank. The second largest group was the interrupted one: applicants who had gone to find a document and returned to an empty form. The declined group was smaller, but it contained an address check that rejected applicants who had moved recently, a rule written for a fraud pattern the bank no longer saw.

The funnel ends where the digital team's ownership ends. The applicant's journey does not.

What the screens could not have shown

None of these findings was available from the funnel, and none of them was a design problem in the sense the redesigns had assumed. The referral queue was an operations matter, the same kind of upstream cause traced in when to add headcount and when to fix the process. The expired session was an engineering decision about how long an application could be held, and often a limit inherited from the core banking system behind the app, which is what an app drop-off rate that ignores redesigns tends to be reading. The address rule belonged to financial crime. Each finding pointed at a function that had never been asked about onboarding, because onboarding had been treated as a product metric.

Each way out has a different owner, which is why the fix usually lands on the one in the room.

Who holds which loss

Applicants who decide to leave are a product and pricing question. Applicants who are interrupted are an engineering question about saving and resuming. Applicants left waiting are an operations question about queues, service levels and how the bank speaks to someone it has not yet accepted. Applicants turned away are a risk question about which rules still earn their place. In most banks the onboarding review is attended by product and digital, so the fixes it commissions are screen fixes, and the losses owned elsewhere persist through every release.

The order of repair

The trace also sets the order. The groups that are largest and cheapest to recover go first, and at the bank that meant a contact standard for referred applicants and a saved application that survived a closed browser, before any further work on the screens. How to put a figure on each group, from ledgers the bank already holds, is set out in the four bills of onboarding drop-off. The useful output of a drop-off analysis is not a list of friction points but a list of owners, each holding a share of the loss they had not been shown. Once each function could see its own group, the onboarding review gained three new attendees and the funnel gained a second half that ran past submit.

Where this thinking becomes work.

Our work on digital account opening starts with the cohort trace rather than the funnel. Following one month of applicants through every system they touch usually shows within weeks why a redesign did not move the number, and which functions hold the losses the funnel cannot see.

From there our consulting engagements inside the diagnosis before solution pillar join the systems, assign each group of lost applicants an owner and sequence the repairs, and our training programmes teach product, operations and risk teams to read one shared view of the application instead of three partial ones. A bank recovers lost applicants by first finding out where they were lost, and only then deciding what to redesign.