A self-service application is usually designed for the customer who has everything ready. Each screen asks, the customer answers, the next screen appears, and a missing document earns a red validation message and no further thought. Design for that customer and every interruption is a failure of the person rather than a state the product knows how to hold.
A European cooperative banking group built its lending dossier the other way round. The screen carried eight modules down the left and a running answer down the right. Two modules were ticked complete, one showed an in-progress marker, one sat open, and four were greyed out behind padlock icons because the inputs they depended on had not arrived. In the worked example on the product screen, the right pane read as a borrowable amount of EUR 312,000 against a stated requirement of EUR 308,575, and a net monthly cost of EUR 1,053. Those figures are the review material's demonstration case, not a customer outcome, and the screen said as much: indicative, conferring no rights, neither an offer nor advice.
Along the bottom of that same screen sat two controls. One was the button that made an appointment. The other, a plain link beside it, said the customer already had one.
The second control is the finding. Nobody labels a control I already have an appointment and puts it in the primary action row unless they expect the journey to be interrupted, resumed later and carried into a conversation with a person, and expect it often enough to pay for it in pixels. The padlocks and that link are one design rather than two. The product is allowed to refuse an answer, because leaving is not the end of the process.
The challenge
The review around the product was a process mining engagement across the full cross-channel journey. Mobile events, online clickstream and CRM click data were stitched into a single discovered model, which is the part that earns its cost. Analytics kept per channel cannot see a customer who starts in one place and finishes in another, because each channel believes it is the front door.
The designed journey had eight stages, fifteen mapped touchpoints and three owning functions with handovers between them. The model discovered from the event log had between thirty-five and forty activities and long loop-back arcs sweeping from the foot of the diagram back to the top. Setting those two pictures side by side is the argument for doing the work.
Two findings came out of it, and both are about leaving rather than converting. Uploading the supporting documents did not go right the first time. And customers contacted the bank first, going online afterwards, which inverts the assumed order: the site was largely serving people already in the funnel.
Read those two together and the padlock stops looking like a gate. A lending dossier cannot compute an honest answer without income, existing debts and the property. Most products handle that by asking anyway and printing a number with a disclaimer underneath. This one declined, and declining costs you the customer unless the way back in is already built and visible.
The approach
Three design decisions carried the weight, and none of them is a model.
The module grid wrote into one shared dossier state, so the answer was computed from whatever had been filled rather than assembled at the end. The screen is the proof: income and existing debts ticked, the property module mid-flight, four modules locked, and the right pane already carrying a number. That is what makes a lock legible, because the person sees an answer standing while the remaining inputs are still doing work, so a padlock reads as not yet rather than as no.
The dossier also produced a portable artefact. An orientation report could be downloaded from the same screen: something to bring to the appointment, or to open a fortnight later when the payslip finally turns up.
And escalation was a first-class path rather than a failure state. The landing page in front of the dossier promised a full picture of the loan and the monthly cost within thirty minutes, then offered three separate appointment calls to action against three calculation entry points. That abundance is honest about what customers wanted, and it is also a measurement problem: three ways to book a person cannot tell you which one was intended.
The document step is where the design was tested hardest. Drilling from the bottleneck in the discovered model into the live screens showed six document categories, a path three levels deep to reach a single payslip, two competing upload controls (one for a whole document, one for loose pages) and a hint suggesting the customer move to a tablet and photograph the paperwork. That is a great many ways to be wrong about one payslip. The primary action on that screen was not submit. It was share the dossier and make an appointment, offered as a single control.
Hominis exists for that shape of problem. The hard part of putting a machine-run process in front of a person is not the handover, it is holding the case whole across it.
The outcome
The dossier was a live product. The process mining around it produced findings, a mined funnel and recommendations. It did not produce a measured conversion lift, no before-and-after figure appears in the material, and this piece has none to give.
What it produced as structure was a funnel discovered from CRM events rather than drawn: six activities, with inbound and outbound telephone contact modelled as two distinct steps instead of collapsed into a single box called contact. A drawn funnel would have merged them. The event log kept them apart, and the traffic queued on the transitions into them.
The recommendation was to embed the measurement rather than repeat the study. Process indicators inside the reporting that already wrapped the straight-through processing chain. Operational indicators inside the comparison programme already running across the member banks. Process analysis inside the team that ships the product, not in a central analytics function beside it. One precondition was stated plainly, in small type, and it is the most honest line in the pack: none of the comparing works unless every unit records the same way in the same CRM. Data readiness before instrument, as ever.
Three things would be done differently with what is available now.
The padlock is an event, and nobody was logging it as one. A customer who opens a locked module, reads the prerequisite and leaves has just labelled their own abandonment for you. Capture lock-shown, lock-attempted and appointment-booked-from-a-locked-module, and whether gating helps or hurts becomes measurable instead of arguable. That costs a week of instrumentation and no new platform.
Document handling has become a deployment question rather than a taxonomy question. A classifier that reads what the customer sends and decides which of the six categories it belongs to takes the taxonomy off the customer's side of the screen. The model is ordinary supervised work; the pipeline around it is not. A feature store the classifier and the underwriting rules both read from, and a lineage trail recording which document version produced which decision, because a lending decision has to be reconstructable long afterwards.
And the cautious language-model pilots now appearing in document handling improve the capture step and nothing downstream of it. A model that reads a payslip well still needs somewhere to put the answer. If the dossier state cannot hold a half-finished case across a logout, a channel switch and a fortnight of waiting, a better reader has improved one step of a journey that still ends at the first missing document. The Platform work we do starts with that state, because it is the part nobody demos.
Any product that gates a step is betting on what the customer does next, and most lose that bet quietly, in a log nobody reads. This one bet the customer would come back, then spent the screen space to make coming back the easiest thing on the page.