The first version of a bank assistant is often designed backwards. Teams start with the impressive capability, the assistant that can tell you your balance and pay your electricity, and work out the controls later. The first version that actually reaches clients should be designed the other way round: start with the capability that can do the least harm, and learn from it.
For Impala Bank, that meant an assistant that knows nothing about anyone. It answers questions that have the same answer for every client: how fees work, how to get a confirmation letter, what to do when you change phones, which branches open on Saturdays. It cannot see accounts, cannot look anything up and cannot do anything. If a question needs any of that, it says so and sends the client somewhere that can help.
That sounds too modest to be worth building. In practice it is where most of the hard lessons arrive, at the lowest possible cost.
Where we are in the case study
Impala Bank is fictional, and its systems and figures are illustrative. In Chapter 1 Impala set its outcome, a client's repetitive question resolved with no repeat contact within seven days, measured an eight-week baseline of 71%, and listed what must not get worse: fraud, complaints and access to a person for vulnerable clients. It also ranked about thirty repetitive question types by volume and by the harm of a wrong answer.
The highest-volume, lowest-harm questions were all public. Roughly a third of the repetitive calls could, in principle, be answered from content Impala had already published and approved.
Approved content is the real product
The first surprise was not about AI. When the team gathered the content the assistant would answer from, they found about 420 help articles, fee tables and process pages, written over eight years by different teams. Some contradicted each other. Some described app screens that no longer existed. Two pages gave different cut-off times for the same type of payment.
A human agent copes with that. They know which page is stale, or they ask a colleague. An assistant answering from that content will repeat the contradiction with complete confidence, to thousands of clients, in polished sentences.
So the first real work of Chapter 2 was editorial. Impala's content team became the owner of every answer the assistant was allowed to give. Each page got an owner, a review date and a status: approved for the assistant, or not. Pages that described removed features were retired. The two conflicting cut-off times were resolved by the payments team, and the losing page was corrected.
This is the same lesson our No AI Without Information Architecture work keeps returning to. The model cannot repair content the organisation has not maintained. It can only make the gaps more visible, faster.
Three honest moves
The design rule for the first assistant was that it has exactly three moves, and guessing is not one of them.
Answer. If approved public content covers the question, the assistant answers in plain language, quotes the relevant point and links to the page it came from. The link is not decoration. It lets the client check, and it lets Impala trace any wrong answer back to the content that caused it.
Redirect. If the question is about the client's own account, such as "why was my card declined yesterday?", the assistant does not try. It explains that it cannot see accounts yet and sends the client to the right place in the app, with a link that opens the relevant screen.
Hand off. If the question is neither, or the assistant is unsure, or the client asks for a person, the conversation goes to the contact centre with the transcript attached, so the client does not have to start again.
The retrieval pattern behind the "answer" move is ordinary retrieval-augmented generation, which our RAG explained simply article covers for non-specialists. The production details, such as hybrid search, freshness and evaluating retrieval separately from the answer, are the subject of our RAG That Survives Production series. What matters here is the policy around it: when retrieval finds nothing approved, the assistant does not fall back on what the model happens to know about banking in general. General model knowledge about fees or rules may be out of date, may describe another bank, or may simply be wrong.
Why the handoff is half the design
Teams tend to treat the handoff to a person as a failure path, built last and tested least. For Impala it was the first thing the contact centre asked about, and the right instinct.
A poor handoff makes the assistant worse than nothing. The client explains their problem to the assistant, gets transferred, waits, and explains it again to someone who cannot see the earlier conversation. Their impression of the bank is now worse than if they had phoned in the first place.
Impala's handoff carried four things: the transcript, the question type the assistant thought it was, the pages it had considered, and the reason for the handoff (asked for a person, no approved content, low confidence, sensitive topic). The contact centre's screen showed all four. Agents could also flag a handoff as "should have been answered" or "should never have been attempted", which became one of the most useful signals in the whole programme.
There was also a hard rule about when to hand off immediately, without trying to answer: any mention of fraud, a stolen card, a death in the family, being unable to pay, or being pressured by someone else. Those conversations go to trained people. The first assistant's only job is to get them there quickly.
What the client is told
The assistant introduced itself plainly: it is an automated assistant, it can answer general questions about Impala's products and services, it cannot see or change accounts, and the client can ask for a person at any time. It never claimed to be human, and it never asked for card numbers, PINs, passwords or one-time PINs. Because fraudsters routinely impersonate banks, Impala made that last point visible in the opening message and repeated it whenever a client typed something that looked like a card number. Anything that did look like one was masked before the message was stored.
On WhatsApp, the same rules applied, with one addition: the WhatsApp assistant handled public questions only, and anything about an account was sent to the app through a link. That decision comes back in Chapter 3, where identity arrives.
A small pilot, measured properly
Impala launched the first assistant to 5% of app users, chosen at random, with the rest as a comparison group. Over six weeks the team tracked the Chapter 1 outcome for both groups, not just the assistant's own statistics.
The illustrative results were encouraging and humbling in equal measure. For the question types the assistant handled, resolution without a repeat contact was slightly above the contact-centre baseline. For about one question in seven, the assistant found no approved content and handed off, which mostly exposed gaps in the content rather than in the model. And a small number of answers were wrong because a page was wrong, each traced through its link and fixed at the source.
None of that required the assistant to know anything about any client. That is why it is the right first version: the bank learns about its content, its handoff, its measurement and its clients' real questions while the worst possible failure is an unhelpful answer about a public page.
What this version cannot do, on purpose
The first assistant cannot tell a client why their card was declined, which is one of the most common questions in the whole contact centre. It cannot help with a debit order. It cannot order anything. Clients notice, and some say so.
That frustration is useful evidence. It tells Impala which capability to add next and how much demand there is for it. It also gives the team time to build the identity and data controls properly rather than in a rush. Every later chapter adds authority; this one establishes the habits, owned content, honest handoffs and measured outcomes, that the authority will depend on.
Key points
The safest first assistant sees no client data. Public, approved content only, with no account access and no actions.
Approved content is the real product. Contradictory or stale pages become confident wrong answers, so content needs owners and review dates.
Three moves, no guessing. Answer with a link, redirect account questions to the app, or hand off with the transcript.
Design the handoff first, not last. A handoff that loses context makes the assistant worse than no assistant.
Measure against a comparison group. Track the Chapter 1 outcome for users with and without the assistant, not the assistant's own statistics.
Next: Chapter 3, Adding account context without handing the model the keys. All chapters are on the series page.
How CloudNala can help
We help organisations launch a first assistant that is deliberately modest: owned and approved content, a handoff the contact centre actually trusts, and a pilot measured against a comparison group. The aim is to learn where your content, process and measurement fall short while the stakes are still low.
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