Guides
What digital transformation in a bank really looks like
Transforming a bank is not a choice of platform but management work: before-and-after metrics, honest economics and people who are afraid of being optimised away. Where to start, and where AI stalls.
Digital transformation in a bank is usually discussed as a choice of technology: which platform to install, which model to plug in. In practice it is decided one level up. Technology today is equally available to everyone, and the advantage goes not to whoever deployed something first, but to whoever tied the deployment to business goals, did the arithmetic and was ready to change processes rather than only systems.
Transformation touches strategy, the operating model, the budget, the culture, security and customers. It is a management task, not an IT department project.
Why change stalls even with full support from the top
Management is almost always in favour of change. The trouble is that the strategy has to be grounded in the processes and the goals of the front-line units — otherwise it stays a presentation. Open resistance is rare; passive resistance is what you meet. Access to data takes weeks to approve, the pilot drags on, the results always need one more clarification.
There is a separate cause: the wording. “We are introducing AI to improve efficiency” sounds to a contact centre agent like “we are about to be cut”. Until that is addressed head-on, the line will quietly sabotage any pilot.
Four groups of projects and one catch
Business cases for transformation usually fall into four groups, and each has its own way of proving itself.
- Customer service: speed, quality of service, retention.
- Costs: cost per contact, workload on people, manual operations.
- Revenue: conversion, average basket, repeat sales.
- Risk and compliance: fraud, adherence to regulations, auditable decisions.
The catch is in the timeframe. Research projects pay off over two or three years, and not every committee is ready for that horizon. In practice anything that does not pay back within a year to eighteen months gets postponed — however promising it looks.
The metrics without which a project stays a technology
The main reason an AI project cannot be defended is the missing “before” measurement. The effect then cannot be shown: there are numbers, but nothing to compare them with. Here is what is worth measuring before the start.
- FCR — the share of questions resolved on first contact. Watch it by day, week and month: a drop means repeat calls are growing.
- NPS — the share who score 9–10 minus the share who score 0–6. Scores of 7–8 are not counted at all.
- CSAT — the share of 4s and 5s. Eighty per cent and above is considered healthy.
- AHT — average handling time. Not to be confused with answer speed, which is set by a service level such as “80 % of calls within 20 seconds”.
- WER — the speech recognition error rate. For languages with little labelled data, and for mixed speech, it easily exceeds 30 %.
- Attrition — how many agents change in a month. Ten per cent means hiring and training a tenth of the shift every month.
A metric is not for the report, it is for the comparison. Without a “before” measurement any result remains an opinion.
Why AI reaches customer service first
The reason is simple: everything needed to prove the effect is already here. The data has accumulated, operational metrics have been counted for years, the process is clear and repeatable. That is why speech analytics, a prompter for the agent in the call, search over the knowledge base and alerts on spikes in contacts pay off fastest.
Internal helpers for HR, legal and finance, search over documents and general-purpose assistants deliver more slowly — usually beyond a year and a half. That does not mean they should not be built; it means starting with them is risky.
Where AI stalls
- Infrastructure: the cloud requires anonymising the data, while an on-premise rollout costs more and takes longer.
- People: there are few specialists who can take a model all the way to production.
- Security and compliance: a human in the loop is required wherever a decision affects the customer.
- Fear among staff: while the line expects redundancies, it will not help the pilot.
- Data quality: a model trained on rubbish confidently produces fiction.
Four of the five barriers are organisational, not technical. They have to be cleared before the project starts, not after the first failed pilot.
From the prompter to the agent: where the market is going
The market is moving from systems where a person decides and the machine suggests, towards agents that act on their own. For a bank that runs straight into personal data, banking secrecy, responsibility for the decision and integration with dozens of systems.
The sensible order is to build automation up in stages. First recording, analysis and quality control: the system watches and reports. Then automatic scenarios where the quality has already been confirmed on your own recordings.
Six questions before the start
- Which problem exactly are we solving, and whose problem is it?
- Which metrics will measure the starting point and the result?
- What stays inside the bank and what goes to a partner?
- How will the solution fit into the architecture, the data and the processes?
- Who manages the models, their quality and their security, and how?
- How is the handover of knowledge arranged so the bank does not stay dependent?
What this gives in practice
Transformation is won at the level of operations, not of platforms. A bank does not need one more system; it needs results: every conversation reviewed instead of a sample, less time per contact, fraud spotted before the money leaves, and no repeat calls about the same question.
In our banking projects it looks like this: automatic quality control across 100 % of communications instead of a sampled 2–5 %, average handling time down by 10 %, and 19 % of customers moved into digital channels. The numbers differ from bank to bank and have to be counted on your own recordings — but the order of magnitude is this one.
