Most banks measure whether their staff use the CRM. Very few measure what the CRM costs them. The first number is an adoption metric and it can only ever go up and to the right. The second number is a line item, and once an organisation holds it, every screen in the system becomes an object of finance rather than an object of taste.
A large European cooperative banking group went and got the second number. It did not commission a time-writing exercise, a survey, or an activity analysis with a six-week discovery phase in front of it. It read the logs its own people were already generating: 5.8 billion CRM click events a year, refreshed continuously, sitting in a system nobody had thought to point at itself. For the whole of the sales funnel, click counts and throughput times were made visible. From that, the group reconstructed what the ideal handling of a task looked like and measured actual executions against it. The gap, expressed as a better configuration of the system, carried a stated saving potential of 600,000 hours a year.
The challenge
The group runs through a network of local banks with real autonomy, which is the point of the model and also the source of the problem. Autonomy at the customer touchpoint is worth paying for. Autonomy in how a form gets filled in is not, and neither is invisible.
Two cuts of the same data show what that costs. The first is by role. A single sales task inside the CRM was executed by five different role types. The adviser ran 61 per cent of it, an administrative assistant 17 per cent, an account manager 9 per cent, a specialist 6 per cent, and a residual 7 per cent went to other roles. A task that five roles touch is a task nobody owns. Worse, the analysis found that the specialist spent more time per sale than either the adviser or the administrative assistant. The role running the smallest share of the volume was also the slowest through the same screens, and nothing in the material says whether that was the difficulty of the cases or the handling of them.
The second cut is by place. The time taken to run the same sales task varied measurably between local banks. Not because the customers were different, and not because the product was different, but because the handling was. The group put it more diplomatically in its own words: local banks differ and pick things up in different ways, and the ambition is to combine the strength of the personal approach with the strength of consistent handling.
Neither of those findings is available from an average. Both fall straight out of a click-stream once you agree to read it as evidence rather than as exhaust. The enabling move on this engagement was passive time attribution: work out where staff time goes directly from system events, with no self-reported input anywhere in the chain, and therefore nothing for anyone to argue with in the steering committee.
The approach
The mechanism deserves stating carefully, because the analysis records its inputs and its output but not every step between them. What is stated: the click volumes and throughput times were visible across the sales funnel, and an improved configuration was assessed as carrying a 600,000 hour annual potential, with the benchmark described as the ideal handling of a task. The reconstruction that follows from those statements, and from the process breakdown that sits alongside them, is that the ideal path was derived from observed successful executions rather than from a target somebody set, and the deviation of every real execution from that path was then aggregated into hours.
That derivation matters more than the headline. A benchmark taken from a vendor's reference data is a number a client can dismiss. A benchmark taken from the client's own best observed runs of its own task is a number that has already survived the only objection that counts, which is that the work here is different.
The arithmetic discipline matters too. Six hundred thousand hours is an arresting figure and an easy one to misuse. Set it against the total time the same analysis says the workforce spends inside the CRM each year and it lands on the order of two per cent. That is modest, and the modesty is the credibility. Most business cases for analytics run the ratio the other way round: a large percentage against a small base that never gets published. This one put the absolute and the denominator on the same page, which is the only form in which a finance function will accept either.
The measures this half of the work fed into are worth reading as a list, because they were correct and they were also, at the time, mostly unbuildable. Adjust the CRM to prevent superfluous clicking. Monitor and steer response and throughput times proactively across local banks. Let the weaker banks learn from the stronger ones. The group's own notes behind that list add a fourth in plainer language: configure tasks consistently.
Two of those four are configuration. Do them once and the gain is banked. The other two are not, because a throughput time that is steered proactively has to be steered again next week, and a weaker bank that has learned something has to keep having learned it. Both need something that watches continuously and then acts. What was available was reporting, benchmarking and training. Those are the right instruments for producing agreement and the wrong ones for holding a standard in place.
The outcome
What this work produced was a measured baseline, a set of quantified differences between roles and between local banks, and a list of improvement measures with a stated potential attached. It did not produce a realised saving, and nothing in the material claims one. Six hundred thousand hours is a pool that was shown to exist, priced honestly against its own denominator, and handed to the people who would have to go and get it.
The analysis half of that work has since become cheap. Event data lands in a warehouse with lineage attached, the process breakdown is a query rather than a project, and any group with its data readiness in order can rebuild this baseline in weeks. Our Consult engagements start there for exactly that reason: the measurement is no longer the constraint.
The expensive half is closing the gap, and this is where the shape of the problem has changed. Peer learning decays. A branch that was taught the better path in the spring drifts back by the autumn, and the only way to know is to run the analysis again. The standard cannot live in a training deck or in a quarterly benchmark; it has to live in the runtime, in the thing the staff member is actually touching. A copilot that holds the ideal path and executes it, so that the deterministic segments of a task stop depending on whether a person remembers the shortest route, is the first mechanism that delivers what this group asked for: consistency held in the process, variation preserved where the customer can feel it.
Two disciplines from this work carry directly into that. The first is that the observed best path, not an aspiration, is the benchmark, which means an evaluation set built out of the client's own logs rather than a generic one. The second is that the deviation has to keep being measured after the system goes in, because a configuration that saves time in month one and drifts in month six has saved nothing. Early autonomous execution should be scoped to the steps where the ideal path is unambiguous and the lineage trail is complete, which is also what the incoming European rules on AI, now politically agreed, will expect anyone to be able to show.
The group found the hours. What it did not have was anything that could go and spend them.