VOYA BLOG / AI Assistants in Banking: From Fast Replies to Reliable Customer Outcomes

AI Assistants in Banking: From Fast Replies to Reliable Customer Outcomes

A fast reply does not mean a resolved issue. Explore banking assistants through task completion, verified transaction status and a clear path to human support.

VOYA | Digital Product Design Studio
VOYA | Digital Product Design Studio
3 November 2026
Article
Fintech
Artificial Intelligence
7 minutes reading time
7 minutes reading time
VOYA BLOG / AI Assistants in Banking: From Fast Replies ...
A banking app showing AI and human support messages beside a headset.
Table of Contents
  • What Turkish customer research adds
  • Distinguish an answer, an action and a resolution
  • Scenario one: a transfer has not arrived
  • Scenario two: an unfamiliar card transaction
  • Scenario three: tracking a credit application
  • Treat human handoff as part of the service
  • Measure customer outcomes, not conversation volume
  • Test failure and change over time
  • Frequently asked questions
  • How should a banking chatbot be evaluated?
  • When should an assistant transfer a customer to a person?
  • Should every task happen entirely in chat?

When a customer says a transfer has not reached its recipient, a fast conversation is not the outcome they need. They want to understand the payment’s status and what to do next. An immediate but irrelevant answer leaves the uncertainty intact.

The starting question for an AI banking assistant should be which tasks it can reliably help customers complete. Natural language becomes valuable when it connects to accurate information and an effective service operation. Without that connection, the product may sound capable while leaving the customer unable to make progress.

What Turkish customer research adds

KPMG’s 2024 customer experience research for Türkiye reports concerns about personal data security among 51% of respondents, incomplete transactions among 50%, and a lack of emotional understanding among 45%. It covers 1,052 consumers across eight sectors; these are not banking-only results.

Our design interpretation is to examine whether the customer can actually move forward. The scenarios and measurement framework below are proposed product design approaches, rather than outcomes measured by that study.

Distinguish an answer, an action and a resolution

An assistant can answer a question, prepare an action or open a support request. These should not share one undifferentiated definition of success. Explaining a transfer limit is an information task. Preparing a payment is a transaction task. Investigating a missing payment starts an operational process.

Each task needs an explicit completion condition. Opening a case can be a successfully completed submission while the underlying issue remains unresolved. Analytics and customer-facing language should preserve that distinction.

The assistant should also explain its scope in practical terms. A promise to locate transactions and create support requests is more assessable than a greeting that implies every financial problem can be solved in the chat.

Scenario one: a transfer has not arrived

If several payments were sent to the same recipient, the assistant first needs to identify the relevant one. A short selection list with dates and amounts may be easier than asking the customer to retype everything. Identity and authorisation checks must follow the actual banking service’s requirements.

Once the transaction is selected, the response should rely on verified status information. If the system cannot retrieve that information, it should explain the limitation rather than generate a likely answer. The interface should describe an investigation as underway only when one has actually been initiated.

When a request is submitted, the customer can be shown a reference, a tracking route and a verified next step where available. The assistant should not invent a completion deadline. Returning later should make the existing case accessible rather than encourage duplicate requests.

Scenario two: an unfamiliar card transaction

A customer reporting a transaction they do not recognise needs a different journey from someone asking a general product question. The interface should provide access to the appropriate security and support pathways according to the institution’s real procedures.

Long explanations and repeated questions may add unnecessary work. The reason for collecting information should be clear, and already verified details should not be requested again without a relevant need. The assistant should avoid soliciting unnecessary sensitive information in the conversation.

Empathy involves more than adding reassuring language. Appropriate prioritisation, understandable options and a real follow-up path are practical design decisions. A comforting response must not imply that a protective action has occurred when no such action was taken.

Scenario three: tracking a credit application

Repeating generic eligibility conditions does not answer a customer who wants to know why an application is pending. Where the assistant has the necessary access and authority, it should show the current stage and whether the customer needs to do anything.

If a document is missing, the product should identify it, explain how to submit it and confirm the resulting state accurately. If a decision has not been made, the assistant should avoid implying likely approval. Application tracking should not drift into unsupported credit advice.

This illustrates why conversational products need other interface components. A status card, upload control or progress view may communicate more clearly than a long paragraph. The entire experience does not need to fit inside chat bubbles.

These three scenarios are illustrative design proposals, not descriptions of services deployed by a named institution or evidence of measured improvements.

Treat human handoff as part of the service

The US CFPB’s 2023 report on financial chatbots describes problems involving inaccurate information, repetitive interactions and difficulty reaching human support. It is neither a Turkish study nor a current benchmark of model performance. It provides documented failure patterns to consider in design.

Possible escalation triggers include a direct customer request, an authority boundary or repeated inability to make progress. The destination and response should reflect the support operation’s actual capacity.

Preserving relevant context can reduce repetition. A representative may need the selected transaction, the request summary and the steps already attempted. Only appropriate, necessary information should be transferred. Because generated summaries may be inaccurate, the experience can also provide a way to correct them.

An escalation is not automatically a failure. Recognising the system’s limit and helping the customer reach suitable assistance may be the correct outcome for the task.

Measure customer outcomes, not conversation volume

Time to first response is an operational measure, not a complete measure of service quality. The following framework proposes complementary metrics. It does not provide industry benchmarks or promise a particular improvement.

Metric Proposed definition Interpretation
Task completion Verified completed tasks divided by eligible task attempts A closed chat is not evidence of completion.
Repeat contact Customers returning for the same reason within a defined period Define the period and reason matching in advance.
Time to resolution Time from initial request to verified resolution Keep separate from response latency.
False success reporting Actions described as completed when they were not Track as a distinct trust-related failure.
Handoff quality Appropriate transfers with the required context Reducing transfers is not the sole objective.

Segment these measures by task. Combining product information questions and suspected fraud cases into one average can conceal important differences. A low handoff rate could indicate effective automation, but it could also mean people cannot reach the support they need.

Teams should define how completion is verified before measuring it. A customer’s positive reaction is useful feedback, but it does not establish that a payment executed or a dispute was resolved. Use the relevant operational record where the task requires one.

Test failure and change over time

Prototypes should include incomplete information, misunderstood intent, unavailable systems and repeated requests. Research should explore what participants believe happened, as well as what they said or clicked. Believing that an unexecuted action has completed is an important design finding.

A release can begin with a clearly bounded task scope. Support cases and failed attempts can inform subsequent changes. When a model, knowledge source or integration changes, critical scenarios should be checked again rather than assumed to behave as before.

VOYA’s AI product transformation approach centres on user needs, workflows and prototype validation. An effective banking assistant belongs within an experience where customers understand what happened and what comes next.

Explore customer trust in banking AI for the broader experience principles, or AI and KVKK for the Turkish data protection perspective.

Frequently asked questions

How should a banking chatbot be evaluated?

Track task completion, accuracy, repeat contact and resolution time together. Conversation closure or a fast reply does not by itself establish that the issue was resolved.

When should an assistant transfer a customer to a person?

Consider the customer’s request, the task’s consequences, the assistant’s authority and whether the interaction is progressing. Design these rules with the actual support operation.

Should every task happen entirely in chat?

No. Selection lists, status cards and confirmation screens can work alongside conversation. Choose the interaction that helps customers understand and complete the task correctly.

Share on XShare on FacebookShare on LinkedIn

Explore All Blogs

>
<

Ready to talk
about your project?

Do you have a clear vision regarding the ideas, goals, requirements, and desired outcomes for your project? Let's take the first step together by setting up a meeting to bring all of these to life.