A journey map is a drawing until something measures it. Anyone can put fifteen boxes on a wall in an afternoon, and most banks have. What almost nobody has is a log that can say whether the boxes are in the right order.
A large European cooperative banking group was rebuilding its lending chain end to end when this work ran. The chain it was replacing had been steered the way most chains are steered, on output: applications in, offers out, conversion counted at the end of the quarter. Those measures describe a process after it has stopped, which is acceptable when the process is stable and useless while you are changing it. The sharpest line written down at the start of the work was the shift itself: move from steering on output to steering inside the process.
To steer inside a process you have to be able to see inside it. That meant three things in sequence. Join data that had never been joined. Mine the journey it describes. Then hold the mined journey against the drawn one and read the disagreements.
The challenge
The journey ran eight stages, from the moment a borrower becomes aware there is a decision to make through to the point they recommend the bank to somebody else. Fifteen distinct touchpoints sat along it. Some were channels the group controlled and could log directly: the public website, an online calculator, an upload of supporting documents. Some were human: a phone call, an advice conversation, the handover that completes the purchase. Some sat outside the perimeter entirely, including social platforms, news and campaigns, and the life event that started the search in the first place.
Three owning functions divided that journey between them. Marketing owned the first stage only. Sales owned the next four, from information through to the purchase. Service owned the last three, after the money moved. Two internal seams therefore fall inside one customer's journey. At each of them the borrower carries straight on and the accountability changes hands, which is neither a coincidence nor a scandal. It is what an organisation chart does to a journey.
The data problem was more ordinary and harder to fix. Behaviour was recorded in three separate places: mobile event data, online clickstream, and click data from the customer-relationship system the branches worked in. Each was complete about its own channel and blind to the other two. A borrower who calculated a repayment on a phone, called a branch two days later and then signed in a meeting appeared across those systems as three unrelated strangers. No amount of reporting on any single source produces a journey, because the journey is precisely the thing that crosses them.
The approach
The work stitched the three sources into one process model, keyed on the customer rather than on the channel, and mined that model for the paths people actually took.
Keying on the customer is the whole job, and it is the part that gets budgeted as though it were plumbing. A shared case identifier is what turns three channel reports into one journey. Without it there is nothing to analyse except three accurate accounts of three different things, and no dashboard built on top of them can recover the crossing. Our Consult work starts at that identifier rather than at the model, because every question anyone wanted to ask of this estate sat downstream of the join, and so did every error the join made.
What the mining adds is not detail. A drawn map is a consensus: it records what the people in the room believe the process does. A mined graph is a measurement. When the two agree, the drawing was fine and the exercise cost a few weeks. When they disagree, the disagreement is the finding, and it is the kind of thing that is cheap to measure and ruinous to guess at.
The outcome
Three things the mined graph said that the drawn map had not.
Document upload did not succeed on the first attempt. On a drawn journey that is one box with a single arrow leaving it. On a mined one it is a loop, and it sits immediately in front of the advice conversation, so a clerical failure lands on the human step.
The channel order was inverted. Customers contacted the bank first and went online afterwards, the reverse of the sequence the digital programme had been designed around. A funnel built on the assumed order tunes steps that people are reaching in a different state than anyone planned for.
And lead time to the first appointment could, for the first time, be compared across the group's local banks on real transaction data rather than on self-report, with the strongest performers standing as the reference point instead of an average.
Then the part that determines whether any of this survives the engagement. The recommendation was not to stand up an analytics team. It was to embed the measurement in three places the group already had: the reporting environment covering the straight-through processing chain, the existing benchmark programme the local banks were already compared in, and the development and marketing team that changes the product.
One precondition sits underneath all three, and it deserves large type rather than small. None of the comparing and steering works unless every local bank records the same way in the same system. A benchmark built on inconsistently entered events produces confident, wrong league tables, and the confidence is the dangerous half.
The item this kind of work almost always drops is the one that makes the next cycle possible: a baseline captured before anything changes, so improvement can be measured rather than argued about. Skip it and the following review opens exactly where this one did.
Set the tense straight before anyone quotes this. The engagement produced a stitched journey model, a set of mined bottlenecks, a working demonstration of cross-bank comparison and a proposal for embedding the measurement. It did not produce a delivered conversion result, and nothing above should be read as one.
What transfers is the discipline rather than the tooling. Data readiness is not a platform question, it is a joining question: three sources with no shared case identifier are three reports, and every machine learning pipeline downstream inherits whatever the join got wrong. That is why lineage back to the source event matters more than model choice, and why a feature store fed by an unjoined estate is an expensive way to be wrong faster.
The early and cautious language-model pilots now appearing in document handling do not change that arithmetic either. A model that reads an uploaded file well still has to land its answer somewhere, and if that somewhere is the same loop sitting in front of the advice conversation, the pilot is a demonstration rather than a programme. The Platform work we do begins at the join, because everything else is downstream of it.
Fifteen boxes on a wall is a consensus. A mined graph is a disagreement, and the disagreement is what you came for.