
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
No. Selection lists, status cards and confirmation screens can work alongside conversation. Choose the interaction that helps customers understand and complete the task correctly.
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.