A calculator is a function. Inputs go in, an answer comes out, and nothing survives the tab. That is why nobody minds abandoning one halfway. It is what a lending page had long offered, and it is what everyone assumed sat at the centre of the lending journey at a large European cooperative banking group when we started mining that journey from its own event data.
The group's public page said as much. It promised that within thirty minutes you would know what your new loan and your monthly costs looked like. Beside the promise sat a counter boasting how many people had already been through it. Around both, on one page, were three separate places to start a calculation and three separate buttons offering an appointment, which is a page that cannot tell you which door the customer meant to use.
Then two of the product's own screens were laid side by side. The source keeps them apart, in different sections of the review, and apart is how each of them reads as ordinary product copy. One is the opening step of the self-service tool. The other is what a customer sees while working with an adviser. Read together they are not a calculator with a form attached. They are a numbered case file, held by the institution, that a person is allowed to put down and pick back up.
The challenge
The bank was steering a lending chain it was in the middle of rebuilding, using measures that only describe a process once it has finished. The analysis stitched mobile events, online clickstream and customer-relationship click data into one model keyed on the customer rather than on the channel, and two of the findings that came back are the reason the architecture question matters at all.
The first is that uploading supporting documents did not go right the first time. The second is that customers contacted the bank before they went online, rather than orienting online and then calling. Both describe a process that runs for days across more than one channel. Neither describes thirty minutes in a browser.
So the marketing frame and the mined behaviour disagreed, and the disagreement was not a copywriting problem. If the thing on the page really is a calculator, a failed document upload is a defect in a form and the fix is validation. If it is a case file, a failed upload is a case that stalls with a customer holding evidence the bank has asked for and cannot accept, and the customer's next move is to pick up the phone. That converts a step which costs the bank nothing into a serviced contact, and it does it at the point in the journey where the commitment is highest.
Deciding which of those two things you have built is not a question of taste. It changes what you measure, what you staff and what counts as a failure.
The approach
Take the screens in order.
The first is explicitly numbered as step one and it runs with nobody assisting. Eight modules sit in a grid, covering earnings, existing debts, the property, improvement work, savings, rate, product form and repayment. Some carry a completion mark, one is in progress, and the later ones are greyed behind locks until their prerequisites arrive. To the right, a result is already showing with only two modules finished: what you can borrow, what you appear to need, what you would pay each month, and a verdict on whether a guarantee scheme applies to you. The figures on screen are an illustrative example, not an outcome, and the product itself says they confer no rights and are not advice.
That combination is the tell. A calculator computes at submit. This one carries a partial answer, revises it as each module lands, and refuses the questions it does not yet have inputs for rather than guessing. Refusal plus a running answer is state. State that persists between visits is a file.
The second screen is the advice conversation, and its left rail is not a menu of topics. It is a step rail with the advice itself as one item and document capture as the next. Below it the flow is numbered again, and the third step is where six categories of supporting evidence attach: earnings, debts, savings, the property, identity, and pension arrangements. Reaching a single document type takes three levels of navigation. There are two ways to add one, a whole document or loose pages, which is an admission that real paper arrives in the state real paper arrives in. A hint offers to let the customer photograph the documents on a tablet instead.
The joining detail is a single control that shares the file with the bank, books the appointment, or does both. Handing over state and asking for a human sit behind one button rather than two.
The mined event log then confirms from the other side what the screenshots imply. In the discovered end-to-end model, roughly three dozen activities deep, the file's own page events carry a shared naming prefix and sit in the same graph as appointments and quotes, the two nodes the analysis picks out. Drill into one local bank and the funnel that comes out of the customer-relationship data has six activities in it, with inbound and outbound telephone contact modelled as two distinct steps rather than collapsed into contact. One identity, many channels, and the switch between them is a transition inside the model rather than a boundary between models.
The outcome
What the engagement produced was findings, a mined funnel and a set of recommendations: put process indicators into reporting environments that already existed, land operational measures inside the comparison approach already running with the local banks, and put the analysis capability next to the people who change the product. It also named a precondition, which is that the local banks would have to record the same way in the same system before any comparison across them carried weight. No conversion result was measured, and none is claimed here. The reading of the two screens as one artefact is ours, not a claim the source makes.
What follows from it is a measurement change more than a build. If the unit is a case file rather than a session, then the questions worth instrumenting are the file's own transitions: how long it sits between the unassisted step and the advice conversation, how often evidence capture is attempted more than once, how often the file arrives at an adviser complete, how often it is abandoned with the locks still on. None of that requires new collection. It requires treating the file identity, not the visit, as the key, and keeping the lineage of which system wrote which field so the state is defensible later.
That is also where model deployment stops being a separate conversation. The cautious language-model pilots now appearing in document handling are aimed squarely at the third step, at reading an earnings document and classifying it. A model that reads it well still needs somewhere to put what it read, a record of what it saw, and a rule about what happens when it is unsure. Where that somewhere is a case file with a state machine, the pilot becomes straight-through processing. Where it is a form, the answer lands in a person's queue and the pilot stays a demonstration. The Platform work we do starts with that landing point for exactly this reason.
The bank had already built the harder half of this and was describing it as the easier half. Thirty minutes was the promise for the first step. The artefact underneath it was designed to survive the customer walking away, coming back, and bringing a human into the middle of it.