Voice and chat assistants for banking customers and employees, built around resolution, with authentication designed into the conversation, handover that carries context, and the conduct safeguards these conversations actually need.
Containment is the standard metric in this market, and it rewards the wrong behaviour. A high containment rate means few conversations were transferred, which an assistant can achieve by keeping a customer who needed a person.
Conversational AI in banking is bought and reported on containment, sometimes called deflection. It counts conversations that did not reach a human.
An assistant can raise that number two ways. It can solve more problems, or it can become harder to escape. Both move the metric identically and only one of them helps anybody.
Containment is the target, so escape is made harder
And the customer who needed a person stays in the assistant.
The handover loses the conversation
So the customer explains everything twice and starts angry.
Authentication is where customers abandon
Because it was designed as a gate rather than as part of the flow.
Voice latency was treated as a performance issue
When in speech a pause is a conversational failure.
Distress is not detected in a collections conversation
Which is a conduct exposure rather than a usability gap.
A language is offered and supported badly
Which is worse than not offering it at all.
Measure repeat contact within seventy-two hours of a contained conversation. Take every conversation the assistant contained and check how many of those customers contacted you again within three days about the same thing. That number is your true unresolved rate and it is almost never reported, because containment is measured at the end of the conversation and the consequence arrives later. In most deployments it is materially higher than anybody expects, and it converts a containment success story into an honest baseline you can actually improve against.
Intent taxonomies designed in a workshop describe what the business thinks customers ask. Transcripts and call recordings describe what they actually ask, in their own words, including the parts that are hard.
Step 1
Assess real conversations rather than a assumed intent list
Step 2
Decide which intents are resolvable end to end
Step 3
Design authentication as part of the conversation
Step 4
Design the handover before the happy path
Step 5
Design for distress and vulnerability detection from the start
Step 6
Develop with latency as a hard constraint in voice
Step 7
Integrate to the systems that hold the answer
Step 8
Test on real transcripts, accents, interruptions and noise
Step 9
Deploy to a limited intent set and a limited audience first
Step 10
Monitor resolution, repeat contact, handover quality and abandonment
Step 11
Optimise by retiring intents that do not work
Count how many customers abandon during authentication. Instrument the authentication step on its own and report abandonment there separately from abandonment anywhere else in the conversation. Most voice deployments do not do this, because the funnel is reported at conversation level. The number is usually the largest single loss in the system, larger than any intent-level failure, and fixing it requires no model work at all. It is the cheapest material improvement available in this category.
Grouped by audience, because a customer, an employee and a collections conversation have different risk profiles, different latency tolerances and different conduct requirements.
Customer-facing
Voice AI assistants on telephony, with latency treated as a design constraint and interruption handled rather than ignored
Chat and messaging assistants across web, app and messaging channels, sharing intents with voice and not sharing its architecture
Intent recognition built from real transcripts, with an honest unknown state rather than a nearest guess
Intelligent call routing derived from what the conversation was about, rather than from a menu selection made before the customer explained anything
Multilingual support where the language is genuinely supported, with detection and mid-conversation switching
Employee-facing
Internal help desk assistants for IT, human resources and operational queries
Agent assist during a live customer conversation: retrieval, suggested responses and procedural guidance for the person speaking
Operational
Account servicing conversations for routine, reversible, logged requests
Payment assistance, within limits and with the actions themselves governed as our AI Agents page describes
Loan servicing conversations covering status, schedules and documentation
Onboarding assistance, including guiding a customer through what to provide and why it was rejected
Collections and hardship conversations, with distress detection and mandatory routing to a person
The third column is the point of the table. The conversational capability is similar across these. What differs is the authentication requirement, the system access needed, and whether the conversation carries conduct risk.
| Conversation | What the customer wants | What decides whether it works |
|---|---|---|
| Account inquiries | A balance, a transaction, a statement | Authentication, and live core access |
| Payment assistance | To make, trace or correct a payment | Action limits, and whether it is reversible |
| Loan servicing | Status, schedule, settlement, documents | Access to the lending system, not just the core |
| Onboarding support | To know what to provide and why it failed | Specific rejection reasons, not generic guidance |
| Customer support | An answer to a general question | Current approved content, as on our copilots page |
| Collections | To discuss what they owe and cannot pay | Distress detection and mandatory human routing |
| Complaints | To be heard and to get a resolution | Recognition and immediate routing, never containment |
| Internal help desk | An answer, or a ticket raised properly | Employee identity, and the knowledge base behind it |
They are routinely scoped as one programme with two front ends. The intent model and the content are genuinely shared. The architecture is not, and the latency budget is the main reason.
Telephony and channel layer: call control, media handling, barge-in and interruption, and the session that survives a transfer
Speech layer for voice: recognition tuned for real accents and noise, and synthesis that can begin speaking before the full response exists
Understanding layer: intent recognition with an honest unknown state, entity extraction, and language detection
Dialogue and policy layer: what may be said, what requires authentication, what must transfer, and what the assistant may never state
Retrieval and system access: content as governed on our copilots page, and live account access under the customer’s authenticated entitlement
Handover layer: context, authentication state, transcript and routing decision delivered to the agent desktop before the agent speaks
Speech and language: speech recognition, text to speech, natural language understanding, large language models for generation and interpretation
Channels: contact centre and voice platforms, telephony infrastructure, web, app and messaging channels
Enterprise: CRM for interaction history and customer context, core banking for account data, lending and card platforms
Integration: enterprise APIs, event-driven integration, agent desktop integration for handover
Listen to twenty calls the assistant contained. Not the transcripts, the recordings, with the operations team in the room. Listen for the point at which the customer realised they were not going to get what they came for, and for what they did next. In most deployments that moment is identifiable and early, and it is usually the same two or three intents. Twenty calls takes an afternoon and it produces a more useful backlog than any dashboard, because the thing you hear is not in the metrics.
Which regulations apply to a given use case, how it is classified, and what conduct requirements attach are determined by your compliance, legal, risk and conduct functions, based on your operating markets. We do not interpret those requirements and this page does not state which apply to you.
Technology supports a compliance programme. It does not independently establish compliance, and no assistant makes an institution compliant.
Identity and access
- Customer authentication stepped to the request, with the standard for each set by your risk function rather than applied uniformly
- Caller identification treated as a signal and never as authentication
- Voice biometrics, where used, under its own consent and privacy basis as determined by your privacy function
- Account access resolved under the authenticated customer’s entitlement, never through a broad service account
- Session isolation, so conversational context cannot be reused across sessions or customers, which is a specific and easily overlooked leakage path on a shared channel
What may be said
- A defined scope of what the assistant may discuss, enforced in the system rather than requested in a prompt
- No authority to commit the institution: no rate, no eligibility statement, no assurance about an outcome, and no figure not retrieved from a system of record
- Grounding and content currency as our Generative AI and Enterprise Copilots page describes, since a confident answer from withdrawn content is the same failure here and reaches a customer directly
- Resistance to manipulation on an open channel, treated as a security requirement rather than a prompt instruction
Conduct
- Distress, hardship and vulnerability detection with mandatory routing to a trained person, with the rules owned by your conduct function
- Complaint recognition and immediate routing into the defined complaint process, with the conversation retained as the record
- No negotiation, pressure or repeated demand in any collections conversation
- An unprompted and early human route in every conversation, because a customer should not have to work out how to escape
Records and privacy
- Recording and transcript retention under the consent and notification requirements your legal function defines, per channel and per market
- Conversation monitoring and quality review designed as a control, with what is reviewed and by whom defined
- Data privacy and minimisation, including what is captured in a transcript and what is redacted before storage
- Audit trails over conversations, authentications, actions attempted, transfers and conduct routings
This is the whole argument of the page expressed as a reporting rule. A containment figure presented without resolution and repeat contact beside it is not information, it is a number that rewards the wrong behaviour.
| Failure | How it presents |
|---|---|
| Containment rose and resolution did not | Deflection improved and repeat contacts absorbed it |
| Authentication abandonment is high | Customers leave before any intent is attempted |
| Handover context is not arriving | Agents start cold and customers repeat themselves |
| Latency crept up in voice | Interruptions and hang-ups rise with no content change |
| Recognition is weak for one accent or language | Aggregate accuracy holds and a segment is failing |
| An intent is contained and never resolved | It should be transferring early and is not |
| Distress routing is not firing | Conduct exposure accumulating with a healthy dashboard |
| A complaint was handled as a service query | The complaint process never saw it |
| The assistant stated something uncontrolled | A figure or an assurance reached a customer |
The outcomes below follow from measuring resolution, designing authentication and handover properly, and routing conduct conversations to people.
Faster service on the intents the assistant genuinely resolves, available at any hour
Contact volume reduced because problems were solved, verified through repeat contact rather than assumed from containment
Support cost reduced per resolved conversation, which is the denominator that matters
Customer experience improved on the handover, which is where most of the perceived value in this category sits
Agent time redirected to the conversations that need a person, with context arriving before they speak
A conduct position that is defensible, because distress routes to a human and the routing is evidenced
We will take one intent, review real recordings, measure where customers abandon and why, establish what live system access would be needed to resolve it, and tell you the resolution rate available. You get the assessment whether or not we build anything.
CaliberFocus builds voice and chat assistants for banks that are measured on resolution rather than containment. We design from real transcripts, build authentication into the conversation, carry full context into every handover, give the assistant live account access under the customer’s entitlement, and route distress, hardship and complaints to a person.
- Resolution and repeat contact reported, never containment alone
- Handover that carries the conversation and authentication state
- Voice designed with latency as a hard constraint
- Conduct safeguards for distress, hardship and complaints
Security & Compliance
