The Reset Error That Made a Customer Switch to Twi, and What Followed

A customer often switches from English to Twi at the exact moment a password-reset call stops being simple. The error message creates uncertainty, and an English-only bot can lose the customer’s meaning just when the account is at risk.

At 8:12 on a Monday morning, Kofi is holding his phone between his shoulder and ear while checking a support queue on his laptop. A customer has received the password-reset link twice, entered the new password twice, and still cannot open the account. The automated voice asks him to repeat the email address.

He starts in English. Then the reset page returns one more error, and he switches to Twi.

The bot keeps speaking English.

Kofi can hear the customer explaining what happened, but the system catches only fragments. It asks whether the customer wants a new link. The customer says yes, then adds that the link has already failed. The bot hears agreement, sends the same path again, and moves on.

Now the outcome is uncertain. The customer may be locked out after another failed attempt. Kofi may need to take over manually while the queue grows. If the account is needed for work that morning, the password problem has become an access problem with a real cost.

The language switch marks a change in the problem

People do not always switch languages because they prefer one language in every part of a call. They may start in English because the task is familiar, then move into Twi when the situation becomes confusing, urgent, or difficult to explain.

The error message is often the trigger. A customer may know how to say “I need a reset link” in English. Explaining that the link arrived, opened, rejected the new password, and then appeared to stop working can require more precision. Twi may be the language that lets the customer describe the sequence without searching for words.

That change carries information. It tells the agent that the call has moved from a standard request into diagnosis.

An English-only bot treats the switch as noise, an interruption, or a failure to follow the script. A language-aware agent can treat it as a change in context. It can acknowledge the switch, continue in Twi, confirm what happened, and keep the account state attached to the conversation.

A reset flow needs meaning, not repeated prompts

The weak response to Kofi’s customer is another question: “Would you like me to send a new password-reset link?”

The stronger response depends on understanding the full sequence:

• The customer received the link.
• The link opened.
• The new password was rejected.
• The customer tried again.
• The error returned.
• The customer switched to Twi while explaining it.

Those details determine the next safe step. The answer may be to verify the account state, explain the password requirement in the customer’s preferred language, or hand the call to a person with the right context. Sending the same link again may increase frustration and create another failed attempt.

This is why a voice agent needs more than speech recognition. It needs call controls around the conversation. The system should record what was said, what action was taken, and whether the call reached a valid outcome. Consent, opt-out handling, audit records, and telephony lifecycle events matter because a support call is also an operational event.

We have written about this broader issue in Twi voice agents: Why a Working Language Model Still Needs Call Controls. The language model can understand a sentence while the call still fails as a process.

What to test before putting the flow on calls

A useful test starts at the error message, not at the greeting.

Build a scenario where the caller begins in English, receives a password-reset error, switches to Twi, and explains the problem in their own words. Then check whether the agent:

1. Detects the language change without forcing the caller back into English.
2. Repeats the problem accurately before taking another action.
3. Distinguishes a failed reset from a missing reset link.
4. Avoids sending the same instruction repeatedly.
5. Preserves the conversation context during a human handoff.
6. Records the call outcome and any opt-out or consent event correctly.

Asenda Talk is built for teams testing this kind of voice workflow. You can create and configure an agent’s persona, first message, and voice, then evaluate native Twi speech recognition and synthesis alongside English conversation. The Twi capability is developed in-house rather than added as a wrapper around a third-party voice API.

The platform also includes a telephony lifecycle webhook pipeline for tracking call truth, metered per-minute billing, and an operator-controlled real-money gate. That gate matters during testing: teams can evaluate the flow before live usage is allowed. Asenda Talk remains in active early access, and outbound calling depends on a telephony-provider decision that is not live yet.

The useful signal arrives before the handoff

Kofi’s customer should not have to repeat the whole story to a human because the bot missed the language switch. By the time Kofi joins the call, he should see that the customer received the link, failed the password step, changed to Twi at the error message, and needs help recovering access.

Later that morning, Kofi reviews the call record. The important event is easy to find because the language change appears beside the error and the bot’s repeated prompt. He can now adjust the flow, add a Twi confirmation, and test the same failure path again before it reaches another customer.

Start with the moment the script breaks. That is where the agent has to understand more, ask less, and preserve the customer’s meaning.