Almost every bank has the same slide in its AI deck. The contact centre takes a large number of calls, a large share of them are repetitive, the answers already exist somewhere in the app or on the website, and an AI assistant could take that load. The slide is usually right. What it leaves out is everything that decides whether the assistant will still be running, and trusted, a year later.
This ten-chapter case study follows one bank as it builds its own assistant from nothing to production, one capability at a time. Each chapter adds the smallest thing the previous version could not do safely, explains why it was needed, and names the new risk it creates. One architecture diagram grows with the series: what earlier chapters added is drawn normally, what the current chapter adds is highlighted, and what comes later is not there yet.
It is deliberately a different story from our Agentic Banking series. That series asks what happens when a client's own AI agent sits between them and several banks. This one is about the bank's own assistant, inside its own channels, under its own control. The design problems overlap, but the owner of the risk is different, and so is the order in which you meet them.
The first chapter has no AI in it at all. That is the point.
The bank in this case study
Impala Bank is fictional, and its systems and figures are illustrative. Impala is a South African retail bank with about 2.1 million clients and a head office in Rosebank, Johannesburg. Its clients bank mostly through the app, and its contact centre takes about 180,000 calls a month.
When the service team sampled those calls, about 60% were questions whose answers already existed in the app or on the website. Why was my card declined? When does my debit order go off? How do I get a confirmation letter for my landlord? What does this fee mean? I changed phones and cannot log in. The information was all there. Clients simply could not find it across dozens of screens, or did not trust what they found, so they phoned.
The board's question was simple: could an AI assistant answer those questions, cut the queue and reduce the cost of service, without giving a piece of software unsafe authority over anybody's account or money? That last clause matters more than anything else in the brief, and it shapes every chapter that follows.
Deflection is the wrong target
The obvious measure for an assistant is containment, or deflection: the share of conversations that end without reaching a person. It is easy to count, and it goes up quickly. It also rewards exactly the wrong behaviour.
An assistant scored on deflection is rewarded for ending conversations, not for answering questions. It learns, or is tuned, to sound conclusive. A client who receives a confident answer that does not solve the problem, gives up on the chat and phones the next morning has been counted as a success by the assistant and as a call by the contact centre. The bank has paid for the conversation twice and has a less patient client on the line.
Impala's service team wrote the outcome differently:
A client's repetitive question is resolved, and they do not need to contact us again about it within seven days.
That definition does three useful things. It counts resolution rather than silence. It is measurable across channels, because a repeat contact shows up whether the client comes back by chat, call or branch. And it applies equally to the contact centre today, which means there is a fair baseline to compare against.
Measure the baseline before anyone builds anything
Most organisations skip this step because it feels like a delay. It is the only step that lets anyone later say whether the assistant worked.
Impala's analysts took eight weeks of contact-centre data and established, illustratively:
- About 60% of calls were repetitive, using an agreed list of question types rather than a guess.
- 71% of those repetitive calls were resolved without a repeat contact within seven days. Not 100%. Human agents also give incomplete answers, and knowing that number protects the assistant from being held to a standard the existing channel does not meet.
- The average wait was about six minutes at peak, longer on the first working days after month-end when debit orders run.
- The cost per resolved repetitive question was about R38, once agent time, telephony and the cost of repeat contacts were included.
Each of these numbers had an owner and a written definition. That sounds bureaucratic until the first steering committee where two people present different containment figures for the same week.
The measures that must not get worse
A cheaper channel can make some things quietly worse while the headline improves. Impala listed those up front and treated them as guardrail metrics: numbers that can stop a rollout even if the primary outcome looks good.
Fraud and social engineering. Bank fraud in South Africa leans heavily on persuasion: callers impersonating the bank, SIM swaps, clients talked into approving transactions. A new conversational channel is a new surface for that. Any rise in fraud cases linked to the assistant stops the programme.
Complaints and escalations. If more clients complain, or more conversations end in a formal complaint, the assistant is creating problems rather than resolving them.
Vulnerable clients reaching a person. Some clients are bereaved, in financial distress, elderly and confused, or being coerced. A channel optimised for efficiency can make it harder for exactly those people to reach a human. Impala committed that the time to reach a person, for anyone who asks or shows signs of needing one, would not rise.
Writing these down before the build is not pessimism. It is how the team kept its later arguments about scope honest. When someone proposed letting the assistant change a client's registered cellphone number, the conversation was short, because that change sits squarely on the fraud measure.
Start with the questions, not the model
The other half of the baseline is a list of what the assistant is actually for. Impala's team grouped the repetitive calls into about thirty question types and ranked them on two axes: how many calls each one generated, and how much harm a wrong answer could do.
That produced a natural order of work, which the rest of this case study follows:
- Public, low-harm questions first. Branch hours, how fees work, how to get a confirmation letter. The answers are the same for everyone and already approved.
- Questions about the client's own account next. Which debit orders ran, why a card was declined. These need identity and data, and the harm of a wrong answer is higher.
- Simple requests after that. Order a replacement card, request a letter. These change something, however small.
- Disputes, fraud, hardship and complaints last, or never. These belong to workflows and trained people, with the assistant at most gathering the facts.
Notice what this list does not mention: a model, a vendor or a framework. Those choices come later, and Chapter 8 shows that for a South African bank they are more constrained than the marketing suggests. Choosing them first, before the outcome and the question list are clear, is how organisations end up with an impressive platform and nothing for it to do.
Who owns the outcome
The last thing Chapter 1 settles is ownership. Impala made the head of digital service the accountable owner of the outcome: not the AI team, not IT, not the contact centre. The platform team builds and runs the assistant. The content team owns every answer it is allowed to give. The risk function owns the guardrail metrics and can stop a rollout. The contact centre owns the handoff experience, because every conversation the assistant cannot finish arrives on their desks.
This matters because an assistant touches all of those teams at once, and without a named owner each one optimises its own part. Chapter 10 returns to this with the operating rhythm that keeps the arrangement working after launch.
If you want a broader view of what separates a demo from a system, our From Chatbot to Agent series covers the general case. This series stays inside one bank and keeps asking the same question: what is the smallest safe next step?
Key points
Start with the outcome, not the model. Impala defined success as resolution without a repeat contact, before any technology choice.
Deflection rewards the wrong behaviour. Counting conversations that end teaches an assistant to sound conclusive, not to be right.
Measure the existing channel first. A 71% baseline protects the assistant from an impossible standard and gives the board a fair comparison.
Write down what must not get worse. Fraud, complaints and access for vulnerable clients are guardrail metrics that can stop a rollout.
Order the work by harm, not by excitement. Public questions first, account questions next, simple requests after, disputes and fraud last.
Next: Chapter 2, Start with an assistant that knows nothing about anyone. All chapters are on the series page.
How CloudNala can help
We help organisations define what an AI assistant is actually for before anyone chooses a model: the outcome, the baseline, the measures that must not get worse and the order in which to take on risk. We work from your own contact data and question types, so the business case rests on evidence you already have rather than on a vendor's benchmark.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Production Readiness Review or write to us at consult@cloudnala.co.za