A “press 2 for Twi” prompt only changes the menu path. It does not prove the bot that answers can recognise Twi, preserve what the caller means, or reply naturally when the conversation moves between Twi and English.
At 8:12 on a rainy morning in Kumasi, Esi is holding her phone between her shoulder and ear while packing her daughter’s lunch. This is an illustrative composite, but the moment is familiar: she has called a service line because an account action needs attention before she leaves for work.
“Press 1 for English. Press 2 for Twi.”
Esi presses 2. The recorded prompt changes language, so she relaxes and explains the issue in Twi, adding an English account term halfway through because that is how she normally speaks.
The bot pauses, then asks her to repeat the account term in English. Esi tries again, more slowly. It sends her back to a generic menu.
She now has a choice that should never have been hers: spend more time translating her own problem into the language the bot can process, or leave without resolving it. If the action needs to happen that morning, the bad ending is simple. Her request stays unfinished because the language option ended at the keypad.
A language option is only the first step
A keypress menu can be useful. It tells a system which recorded greeting to play, which queue to use, or which agent group should receive a call. It can also help a human support team prepare for the language a caller prefers.
But a conversation begins after the caller presses the key.
The system then needs to hear what the caller said, including natural phrasing, local pronunciation, interruptions, repetitions, and code-switching. It must keep the meaning of the request while deciding what to say next. If it speaks back, its response has to be intelligible enough for the caller to act on.
An English-focused bot behind a Twi menu can create a particularly frustrating failure. The caller has already been told that Twi is available. Their first spoken sentence reveals that the promise only covered the greeting.
This is why teams should separate menu localisation from conversational capability. A Twi recording at the front of a call flow is one component. Twi speech recognition and Twi speech synthesis are different components. The assistant’s language handling, account-action logic, consent controls, and audit record still have to work together once the call becomes specific.
The failure often appears at the first mixed-language sentence
Esi does not need to make a formal decision to switch languages. She may begin in Twi, say an account term in English, then return to Twi to explain what happened. That pattern can occur in a single sentence.
A system designed around a menu selection may treat “Twi” and “English” as separate lanes. Real callers do not always stay in one lane.
The operational consequence is larger than a poor transcription. If the bot loses a detail after a language switch, it can misunderstand the reason for the call, ask the caller to repeat themselves, or record an incomplete account request. Where consent, opt-out requests, or account actions are involved, the team also needs to know exactly what happened and what the system understood. A caller switches to Twi. Consent and account actions can no longer wait. explores that responsibility in more detail.
The practical test is not “Can the menu play a Twi prompt?” Ask the agent to handle a short, ordinary request that includes a switch between Twi and English. Then review whether it recognised the key detail, responded appropriately, and retained that detail through the rest of the interaction.
What a Twi-capable voice agent needs behind the menu
Asenda Talk is being built for this part of the problem. The platform lets operators configure a voice agent’s persona, first message, and voice, with Twi speech recognition and synthesis fine-tuned in-house. The aim is to evaluate actual Twi and Twi-English conversation, rather than treating a translated menu as evidence that the call experience works.
The calling assistant runtime is orchestrated through Vapi. Asenda Talk also has a telephony lifecycle webhook pipeline designed to track call truth, along with consent, opt-out, and audit records for every call. These are important when a team needs to examine where a call changed course: the greeting, the caller’s speech, an opt-out, a failed handoff, or the final call state.
Those capabilities should be evaluated as a connected flow. Recognition quality alone does not establish that a voice call is ready. A natural-sounding reply alone does not establish that the correct account detail survived the exchange. Can This System Preserve Meaning When Callers Switch Between Twi and English? sets out the question teams should test before relying on a language path.
Test the conversation your callers will actually have
Esi reaches the end of her second attempt with no clearer route than when she began. A better call flow would let her state the issue in the language she chose, keep the account term she used in English, and give her a clear next step. If the assistant cannot complete the action, the record should show what happened so a human can take over without asking her to start again.
Asenda Talk remains in active early access. Outbound calling is gated behind an explicit telephony-provider decision that has not been made live. Teams can still use the current platform context to define and test the conversations that matter before any live calling rollout.
Start with five real caller intents. Write them as people say them, including the English terms that naturally appear in Twi speech. Then test the whole path after the keypress: what the agent hears, what it says, what it records, and where it hands off.
Comments
No comments yet.