A customer abandoning an application does nothing dramatic. They put the tablet down, or they close the tab, and the only trace is a session that stops. Nobody on the product team witnesses a failure. Everyone sees a conversion figure that could be better, and a monthly meeting about what to try next.
Which is why the useful question is never why customers leave. It is what the product asked them to do in the minute before they left, and how many separate decisions that one request was made of.
A large European cooperative banking group put that question to its own event data. Mobile, online and customer-relationship records were stitched into a single case history and a process model was discovered from it rather than drawn. The designed journey had eight stages and fifteen mapped touchpoints. The discovered one had between thirty-four and thirty-eight activities, with loop-backs sweeping from the end of the model to the beginning, which is the usual and useful shock. The first finding the review put a headline on was narrower than any of that. Uploading the documents does not go right the first time.
The challenge
That sentence is easy to nod at and hard to act on, because it names an activity rather than a cause. So the work drilled from the model into the screens that produce it, and the screens turn out to be the whole finding.
The customer arrives on an advice screen carrying a rail of two steps. The first is the advice itself. The second is document upload, and under it sit six required document categories, each a tile the customer has to open. Open one and the path continues: a breadcrumb three levels deep to a single document type, with copy telling the customer which version of that document to supply. On that final page there are two controls. One adds a document. The other adds loose pages. Beside them, a prompt suggests opening the file on a tablet and photographing the paperwork instead.
Take any one of those decisions to a design review and it survives. Six categories, because a lending file genuinely needs six kinds of evidence and lumping them together makes the assessment harder downstream. A two-step rail, because advice and evidence are different activities with different owners. Three levels, because a category holds several document types and a flat list of every type in the file would be worse. Two controls, because a phone camera produces loose pages and a scanner produces documents, and a product that pretends otherwise will mangle one of them. A device prompt, because tablet capture really is better than a desktop scanner most people do not own.
Each is a local optimum. Nobody in the organisation is wrong. The customer still stops.
Read the depth as arithmetic and the ordinary case gets uncomfortable. Four selections place the first file, assuming the customer picks the right control, has the right version of the right document and photographs it legibly. The descent then repeats for every remaining category. That comes to at least nineteen selections before the last file lands, and that is our arithmetic over the counted structure rather than a figure the material states. It is also the happy path. It has no wrong turns, no re-scans and no returns to the advice screen to check which category a document belonged to.
Now put that next to the journey the organisation had drawn for itself. Fifteen touchpoints across eight stages, running from arriving on the site and running the calculation, through the phone call and the advice conversation, to signing the offer and recommending the bank to a friend. Document upload sits on that map alongside them, and along the application stretch it is the one purely clerical act: nothing to choose, nobody to talk to, nothing to receive, only paperwork to get into the right shape. Clerical steps attract no attention in a workshop, because there is no argument inside them and nobody holds an opinion about them, which is exactly why they are where journeys stop. The step nobody would have nominated was the first one the event log named as broken.
The approach
The method that carried this is the joining, not either half of it. Process mining on the stitched event data names the activity where cases stall and loop. It cannot say why, because an event log records that a page was visited and not what the page asked for. The screen explains the why and knows nothing about volume. Run them separately and you get a bottleneck with no cause and a design critique with no weight. Run them together and the argument is finished in one afternoon.
The two controls are the sharpest illustration. A customer choosing between adding a document and adding loose pages has to know, before they act, what shape their own evidence is in and which of the two words the product uses for it. Choose wrong and there is no validation message, because nothing invalid happened. There is a file in the wrong shape, arriving later at a person who has to correct it, and a customer who has been told nothing. That is a zero-cost digital step converting itself into an assisted contact, which is precisely the arithmetic that makes straight-through processing worth measuring in the first place.
The device prompt says the same thing more plainly. The product's own remedy for poor capture was to ask the customer to change device mid-flow: honest advice, and an admission that the fix available at the time was better hardware.
The outcome
What the engagement produced was findings, a discovered model and a set of recommendations. No before-and-after conversion figure appears in the material and none appears here. The proposal was to stop repeating studies and embed process indicators permanently: inside the reporting that already wrapped the straight-through processing chain, inside the comparison programme already running across the member units, and inside the team that ships the product rather than in a central analytics function beside it. One precondition was stated 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 system. Data readiness before instrument, as always.
Three things would be done differently with what is available now.
Instrument the descent itself. The review could name the failing activity and could not put a rate on it, because the levels of that path were not events anyone was recording. Level entered, level left, control chosen, category completed, session abandoned at depth. That is a fortnight of instrumentation and no new platform, and it converts an argument about screen design into a measurement.
Then collapse the choice rather than explaining it. One intake that accepts whatever the customer has, whole file or loose pages, in any order, and sorts it afterwards. The classifier that decides which category a file belongs to is ordinary supervised work on a labelled corpus the bank already owns. The part that is not ordinary is the pipeline around it: a capture step that can hold a half-sorted pile without losing it, a feature store both the classifier and the assessment rules read from, and a lineage trail recording which version of which document produced which decision, because a lending decision has to be reconstructable long after the customer has forgotten uploading anything. That is the Platform work, and it is the part nobody demonstrates.
And the early language-model pilots now appearing in document handling improve the reading and leave the depth exactly where it was. A model that understands an income document perfectly is still sitting at the bottom of a four-level descent, waiting for a customer who has to complete the descent to reach it. Better comprehension at the leaf does not shorten the path to the leaf.
Every organisation has a screen like this one. It was not built by anyone careless. It was built by a succession of people who each won a reasonable argument, on different days, none of whom ever drew the result as a single path and counted it.