The Menu That Sent Adwoa Back Three Times, and What It Almost Cost Her

A caller who speaks Twi and lands back at the main menu has often experienced a failed first contact, even when the call dashboard records a completed interaction. Teams need to track repeated menu routing as a language and intent signal, then review the call before they count it as a successful self-service outcome.

Consider Adwoa, an illustrative composite, standing beside her provisions shelf in Kumasi just before closing. Her phone is pressed between her shoulder and ear while she tries to reach a supplier’s support line. She explains her reason for calling in Twi, hears the menu again, and tries a shorter version of the same request.

The menu returns a third time.

By then, the outcome is in doubt. If she hangs up, the supplier may never learn why she called, and the issue she needed help with stays unresolved until she can make time for another attempt. The call system may still show three menu selections, several minutes connected, and no technical error. On a dashboard, that can resemble a normal interaction.

For Adwoa, it was a conversation that never began.

A repeated menu can hide a failed recognition event

Main-menu loops are easy to misread because each individual event can look valid. The call connected. The agent played a greeting. The caller spoke. The system selected or repeated a menu prompt. No call dropped.

But a valid sequence of technical events does not prove that the caller’s intent was understood.

A Twi-speaking caller may use wording that does not match the expected English menu phrase. They may code-switch halfway through a sentence. They may answer the agent’s question naturally rather than choosing a numbered option. If speech recognition misses the request, the agent can fall back to the main menu. If that fallback happens repeatedly, the caller may conclude that the line cannot help them.

That is why a menu loop should be treated as a reviewable call outcome, especially when it follows a caller utterance. It can point to a recognition gap, an unclear prompt, a routing rule that expects overly narrow answers, or a mismatch between the agent’s language and the caller’s language.

The same risk appears when calls lose the customer’s intended next step. What Happens When Twi-English Calls Lose the Customer’s Intended Next Step? looks at the consequence after intent slips away. The loop is often where that loss starts.

Call truth should separate activity from progress

A useful call record needs more than duration, status, and cost. It needs a version of what actually happened: what the caller said, what the system understood, what route it took, and whether the caller reached a meaningful next step.

Asenda Talk’s telephony lifecycle webhook pipeline is built around that call-truth need. A team should be able to inspect the sequence around the loop: the agent prompt, the caller’s Twi or English response, the interpreted intent, the fallback action, and whether the call ended without resolution.

That record changes the operational question. Instead of asking, “How many callers used the menu?” a support lead can ask, “How many callers were sent back to the menu after stating an intent?”

Those are different numbers.

For an early-access platform, this distinction matters even more. Asenda Talk currently supports building and configuring voice agents, including persona, first message, and voice, with in-house Twi speech recognition and synthesis. Teams evaluating it should test their own high-value caller phrases, including the informal wording their customers actually use. A polished demo phrase is a poor substitute for the sentence a caller says when they are in a hurry.

The fix begins with the first failed turn

Adwoa’s call should trigger a review, not disappear into a completed-call total. Her first Twi response is the critical moment: did the agent transcribe it accurately, identify her intent, and give her a route that fits the request?

If the answer is no, the team has something concrete to improve. They can adjust the first message so callers know they may speak Twi or English. They can add accepted ways to express the same intent. They can review where the agent falls back and make the fallback ask for clarification before replaying the whole menu.

A caller who says “yɛfrɛ me” or another natural Twi phrase should not be forced into the exact wording imagined by a script writer. What Happens When Your Voice Agent Cannot Understand yɛfrɛ me? explores why these first phrases deserve direct testing.

Asenda Talk also includes consent, opt-out, and audit-trail controls for every call. Those records matter when reviewing a failed interaction, particularly when a caller asks to stop receiving calls. A repeated loop must never obscure an opt-out or turn a frustrated caller into another follow-up attempt.

Test for exit paths, not only happy paths

The strongest evaluation calls are the awkward ones. Have someone speak Twi immediately after the greeting. Have them switch to English midway through the request. Have them answer with a full sentence when the prompt expects a menu choice. Then check whether the agent moves them forward, asks a useful follow-up, or quietly sends them back to the start.

Asenda Talk uses Vapi for assistant runtime orchestration, while its Twi speech layer is fine-tuned in-house. The platform remains in active early access, and feature parity with established voice-agent platforms is still in progress. Outbound calling also remains gated behind an explicit telephony-provider decision that has not been made live.

For Adwoa, the useful change is simple. On her next call, the agent hears the reason she called, confirms it in language she understands, and routes her somewhere other than the same menu. Her phone stays on the counter. The provisions shelf gets closed on time.