English-only scripts fail when callers switch to Twi because the script no longer helps them explain, confirm, or resolve the issue. Treating Twi as a preference setting hides the operational signal: a language switch often marks the point where a caller needs the conversation to work differently.
At 9:12 on a Monday morning, Ama, an illustrative composite support lead in Accra, had a mug of tea cooling beside her laptop and a spreadsheet open from the previous week’s calls. One repeat-call reason kept appearing in the notes: “customer called back for clarification.”
She clicked into a recording summary from Friday. The caller had begun in English, answered the verification question, then switched to Twi when the agent explained what would happen next. The English script continued. The caller repeated the question in Twi. The call ended without a clear resolution.
By the time the customer called again, the issue had become a complaint waiting to happen. If the second agent also missed the question, the desk could lose the caller’s trust entirely, and the original request could remain open with no one owning the gap.
Ama had previously grouped these calls under “language preference.” That label was too soft. The report showed a pattern of conversations changing language at the precise moment the standard script stopped being useful.
A switch to Twi often signals a harder part of the call
People switch languages for many reasons. They may be more comfortable in Twi, want to describe a detail precisely, or need reassurance after hearing a policy, instruction, or next step. The important point for a support team is practical: the switch changes what the agent must understand and how it must respond.
An English-only flow can still collect a name, read a greeting, or repeat a simple status update. It breaks down when the caller needs to explain why the answer does not fit their situation.
That is why repeat-call reports deserve more than a count of “resolved” and “unresolved.” Review what happened immediately before the caller called back:
- Did the caller switch from English to Twi after a policy explanation or troubleshooting step?
- Did the agent repeat the same English wording after the switch?
- Did the call create a ticket with enough context for the next person to understand the actual question?
- Did the caller receive a clear next step in the language they used to ask for help?
A transcript can look complete while the conversation itself has failed. The distinction matters when a support desk measures call success by a closed interaction rather than a caller who can act on the answer. A caller switches to Twi. Their real question goes unanswered. explores that failure point in more detail.
The Monday report should connect repeat calls to the moment meaning was lost
Ama changed the way she reviewed the sheet. Instead of treating every repeat call as a staffing problem, she added columns for the language at the start of the call, the language at the first unresolved question, the final stated next step, and whether the follow-up agent had enough context to continue.
The new view did not prove that every Twi switch caused a repeat call. It gave her a way to find the calls worth listening to.
One entry showed a caller who began in English, moved into Twi while describing a problem, then received an English confirmation that did not address the detail she had raised. The second call began with frustration. The caller had to explain the situation again.
That second explanation is the cost of losing meaning. It adds handling time, increases the chance of inconsistent answers, and makes a caller feel as if the first call disappeared.
For voice AI teams, this means evaluating more than recognition accuracy. Test whether the agent preserves the caller’s intent across Twi and English, asks a useful clarification when it is uncertain, and records the outcome in a form the desk can audit. A clean transcript alone does not guarantee a workable handoff. Twi support ticket creation: Why Accurate Transcripts Still Need Decision Rules covers the decision layer behind that handoff.
Build the language decision into the call design
A useful script does not force every caller through the same language path. It gives the agent a clear opening, recognizes when the caller changes language, and defines what should happen if intent remains unclear.
Asenda Talk is built for teams creating voice agents that need Twi and English conversation. Its Twi speech recognition and synthesis are fine-tuned in-house rather than passed through a third-party wrapper. Teams can configure an agent’s persona, first message, and voice, then evaluate whether the agent handles the moments where callers change direction.
Call-truth tracking through the telephony lifecycle webhook pipeline can help teams compare what the system recorded with what actually happened in a call. Consent, opt-out, and audit records give operators a way to review outreach responsibly.
The platform remains in active early access. Assistant runtime calling is orchestrated through Vapi, and outbound calling remains behind an explicit telephony-provider decision that is not yet live. Teams should evaluate the available workflow carefully and avoid promising callers a capability their operating setup cannot yet provide.
Make the next report harder to dismiss
The following Monday, Ama’s report had fewer vague categories. She could point to the place where callers stopped receiving useful help, and she could separate a language-switch failure from a general repeat-call trend.
That changes the team’s next action. Instead of rewriting every English script, they can test the specific moment when a caller moves into Twi, review whether the agent understood the request, and decide what the agent should do when it cannot.
A caller should not need a second call to find out whether the first one counted.
Comments
No comments yet.