A bank chatbot handling 100,000 queries a month can still exclude customers if it only understands the language the bank prefers. Native Twi support removes a practical barrier: customers can explain account, payment, and verification problems in the language they use when the issue becomes complicated.
Consider an illustrative scene in Kumasi. At 4:47 p.m., Ama is standing behind the counter of her fabric shop, holding a phone with a cracked corner while two customers wait. A transfer she expected has not appeared, and she needs the money to pay a supplier before the order leaves.
The bank chatbot asks her to describe the problem. Ama starts in English, pauses, then switches to Twi when she reaches the part about who sent the money and which account should have received it. The bot misses the switch and returns an unrelated answer.
She tries again. If the issue reaches the wrong queue, the fabric order may go to another buyer. The supplier is still waiting.
High query volume can hide language failure
Absa has said its chatbot handles 100,000 queries each month. That number shows the scale at which automated banking support now operates. It does not show how often a customer abandons a conversation, simplifies a problem to fit the bot, or switches to English and loses an important detail.
At this volume, language support shapes access. A misunderstanding repeated across thousands of conversations becomes a routing problem, a support-cost problem, and a customer-trust problem.
Banks often measure whether the chatbot responded. A better measure is whether it understood enough to move the customer toward the correct outcome.
For Twi-speaking customers, the difficult part may appear halfway through the conversation. A greeting can begin in English. Account terms may stay in English. The explanation of what happened may come in Twi because that is where the customer can be precise.
That mid-conversation switch matters. As discussed in The Twi Switch Kwame’s Voice Agent Missed, and What It Could Trigger, language detection must work beyond the opening phrase.
Native Twi changes what the system can understand
Adding translated buttons or a list of common Twi phrases will cover only narrow interactions. Banking problems arrive through names, numbers, English financial terms, Twi explanations, corrections, and short affirmations whose meaning depends on context.
Native speech recognition and synthesis provide a stronger foundation for voice interactions. The system can be fine-tuned for how Twi is spoken in real conversations instead of passing speech through a general third-party voice layer that was primarily built around English.
That distinction affects what happens after recognition. If the system captures the wrong account number, misses a negation, or treats a language switch as noise, the automation can confidently send the case down the wrong path. A polished voice cannot repair a damaged transcript.
Asenda Talk is being built around native Twi speech recognition and synthesis developed in-house, with English interaction and additional African languages in progress. It can create voice agents with a defined persona, first message, and voice, while Vapi orchestrates the assistant runtime.
The platform remains in active early access. Feature parity with established platforms such as Vapi, Retell AI, and Bland AI is still in progress. Live outbound calling is also gated until an explicit telephony-provider decision is approved. Those limits matter when a bank evaluates what can be tested today and what still belongs on the roadmap.
Inclusion requires consent and call truth
Ama’s conversation should not become “successful” because the bot produced a reply. Success depends on whether her language was understood, her request was routed correctly, and the system preserved what happened.
For voice agents, that requires call-truth tracking across the telephony lifecycle. Did the call connect? Did the customer consent? Did she opt out? Which events occurred, and what evidence remains for an operator to review?
Asenda Talk includes a telephony webhook pipeline for call-truth tracking, metered per-minute billing behind an operator-controlled real-money gate, and an audit trail for consent and opt-out events. Secrets are managed through masked, write-only, environment-aware controls.
These controls do not guarantee a fair customer outcome on their own. They make the interaction inspectable. When the agent misunderstands a Twi phrase or mishandles a payment dispute, the team needs more than a completion count. It needs a record that can show where the failure occurred.
The same principle applies before launch. Test complete spoken journeys, including language switches, account references, corrections, consent, opt-out requests, and transfers to a person. What Happens When English-Only Automation Misroutes a Twi Payment Dispute? shows why routing deserves the same attention as recognition.
Start with the conversations carrying real risk
A bank does not need to automate every Twi interaction at once. Start with a contained journey where misunderstanding has a visible cost, such as payment-status enquiries or routing a disputed transaction.
Build a test set from consented, representative speech. Include mixed Twi and English, different speaking speeds, background noise, numbers, names, corrections, and brief responses. Then measure whether the agent captured the customer’s intent and moved the case correctly. Response volume alone is too weak.
In Ama’s illustrative scene, the turn arrives when the agent recognises her switch to Twi, confirms the disputed transfer details, and routes the case to the appropriate review path before the supplier gives away the order.
A few minutes later, she lowers the phone and writes the reference in the margin of her receipt book. The money has not magically appeared. What changed is equally practical: her problem reached the right place without requiring her to translate the most important part of it.
Comments
No comments yet.