One onboarding flow served every customer, regardless of why they came. Loan applicants who failed eligibility were still onboarded into savings accounts they never intended to use, leaving roughly one in six new accounts dormant from the day it opened.
Our onboarding process did not differentiate between savings and loan products. Every customer moved through a single, unified flow that ended in a savings account, regardless of what brought them in.
That worked for customers who came for savings. It failed for the majority who came for credit.
Historical data showed roughly 72% of new customers arrived with a lending intention. Of those, about 49% were rejected by Saku Kredit's eligibility criteria. And roughly half of rejected applicants never touched their account again.
The flow onboarded them anyway. They left with a product they had not asked for, and the business was left maintaining an account no one intended to use.
A product-agnostic onboarding flow created a mismatch between why customers arrived and what they left with.
Compounding the rates gives the scale of the problem:
Close to a quarter of every customer who came to us for credit ended up holding an account they never used. Because each of those accounts carries an ongoing operational cost, the flow was steadily generating expenses out of customers we had failed to serve.
How might we capture customer intent early enough to stop opening accounts that no one intends to use, without adding friction that costs us genuine savings customers?
The obvious fix was downstream: better reactivation campaigns, stronger nudges for dormant accounts. I argued the opposite. The dormancy was decided at the start of the funnel, the moment we onboarded someone whose actual goal we had never asked about. No reactivation effort fixes an account that was never wanted.
I also deliberately avoided rebuilding the journey. The existing onboarding worked, and a structural overhaul would have carried cost and risk out of proportion to the problem. What the flow lacked was not a better shape but a signal: it had no idea who it was serving.
So the change was targeted rather than architectural:
Keeping the flow structure intact was the point. One question at the top, a set of conditional fields beneath it, and a redesigned outcome screen were enough to separate two journeys that had been collapsed into one.
The tradeoff I accepted: adding a question before onboarding begins risks losing customers who might have drifted into a savings account without deciding to. I took that deliberately. An account opened by accident is not an acquisition. It is a deferred cost.
1. Capturing Intent at Entry
The flow opens with a single routing question offering two paths:
Framing both options as savings-inclusive was deliberate. Lending is presented as an addition rather than an alternative, which matches the underlying product reality and avoids implying that choosing credit means giving up the savings account.
2. One Flow, Two Depths of Data
Both paths follow the same step sequence: ID verification, then personal information. The intent signal changes only what those steps ask for.
Savings only stays close to the original flow, collecting identity, address, and basic employment and income context.
Savings + Pinjaman add what a credit decision requires:
The asymmetry is the whole point. Under the old flow, a customer who only wanted savings was still routed through a process built to serve both products. Splitting on intent lets each path ask for exactly what its product needs, and nothing more.
The SLIK consent is the clearest example of why the split matters. It is a meaningful commitment to ask of someone, and under a unified flow, it sat in the path of customers who had no interest in credit at all.
3. Making the Savings Account a Choice, Not a Consequence
This is where the dormancy actually gets addressed.
A customer can pass savings eligibility and still be rejected for credit. Under the old flow, that customer was simply onboarded. The savings account appeared whether or not they wanted it, and for roughly half of them, it was never touched again.
The redesigned outcome screen states the result plainly, Pengajuan pinjaman belum disetujui, and gives a concrete date when they can apply again rather than leaving the rejection open-ended. It then presents two paths:
Making cancellation the visually dominant action was the most contested decision in the project, and the one I would defend most strongly. Standard practice is to bury the exit and push the customer toward the account because acquisition is the metric everyone is measured on. But we had established that an account opened by a rejected applicant carries roughly even odds of going dormant, and every dormant account is a recurring cost. Optimizing for the sign-up meant optimizing for an expense.
Weighting the exit reflects what was actually true in that moment: this customer came for credit, did not get it, and mostly does not want a savings account. Presenting the choice honestly serves both sides.
Cancelling opens a confirmation, Yakin batal buat akun?, which explains that the data already submitted will be deleted to protect the customer's personal information. The final screen confirms deletion and gives a date when they can start again. Framing cancellation around data protection rather than lost opportunity turns the exit into something the customer is receiving, not something they are forfeiting.
Customers who choose to continue proceed straight into account creation and PIN setup, unchanged.
The open tension: weighing the exit risks, steering away customers who would have genuinely used the savings account.
4. Concept Testing: A Collision Between Two Questions
I ran concept testing with internal employees before building. The clearest finding was one I had not designed for: participants experienced the flow as asking them the same question twice.
To a participant moving through the flow, these read as the same question. In fact, they serve entirely different purposes. The first routes the customer to a product. The second satisfies a regulatory requirement to record the account's purpose. Neither could simply be deleted.
The redundancy was therefore not a duplicated field but a collision of phrasing between two questions with different owners, product and compliance, that had never been designed as a pair.
Left unaddressed, this risked the exact problem the project existed to solve. A customer who feels asked the same thing twice reads the flow as careless, and the intent signal loses credibility at the moment it matters most.
Neither question could be removed, so I stopped trying to eliminate the repetition and worked instead on making the two questions clearly distinct and clearly connected.
My first attempt reframed the entry screen away from account-opening entirely:
Yuk, pilih produk yang sesuai dengan kebutuhanmu "Choose the product that fits your needs"
This makes the first screen unmistakably a product choice, not a purpose question. The overlap with KYC disappears at the source.
I then reframed the KYC field along the same lines, from tujuan membuka akun (purpose of opening the account) to tujuan penggunaan rekening (purpose of using the account).
A single word carried the fix. Opening and using are different time horizons. One is a decision made now; the other is a description of ongoing behavior. Once the questions occupied different tenses, they stopped competing for the same answer.
Rewording alone would have left the user answering two similar-looking questions in sequence. So rather than hide the second, I made it visibly derived from the first:
The asymmetry is deliberate. Savings customers keep flexibility because several purposes are legitimately compatible with a savings product. Lending customers do not, because their answer is load-bearing. It determines the flow they are in.
The result reframes the moment entirely. Instead of a system that forgot what the user said and asked again, the user sees a system that carries their answer forward and constrains the options accordingly.
The flow moved from one path serving every customer to a journey shaped by what each customer actually came for:
Modeling the redesign against historical rejection and post-rejection inactivity rates:
These figures are projections modeled on historical rejection and inactivity rates rather than measured post-launch results. The model assumes rejected applicants decline the savings account, so the realized reduction tracks directly with how many choose to cancel. That single ratio determines whether the projection holds, and it is the number I would watch first after launch.
What I learned:
This project reinforced that the strongest design decisions often mean accepting a worse number in one place to fix a real problem somewhere else.
Let's discuss your next project