Asenda TalkAsenda Talk
← All posts

A Twi-Speaking Caller’s Repeated Issue. The Handoff Still Loses Context.

black ip desk phone on black wooden table

Photo by Julian Hochgesang on Unsplash

Count how many times a Twi-speaking caller repeats the same issue after an English menu or failed handoff. That repeat count gives you a practical pre-deployment measure of whether the call preserved the caller’s meaning.

In August 1854, cholera cases were rising around Broad Street in Soho, London. Physician John Snow began plotting deaths by address and noticed that many were clustered around one public water pump. The pattern was not obvious from any single household. It appeared when the cases were counted together.

Snow documented his investigation in On the Mode of Communication of Cholera. His evidence led local authorities to remove the handle from the Broad Street pump. The outbreak later subsided, although the timing and causes of that decline have been discussed by later historians. The important point for a support operation is earlier in the story: repeated outcomes revealed a problem that individual reports could not explain.

A bilingual voice call creates the same kind of evidence. One caller saying the same thing twice may be a difficult moment. Ten callers doing it after the same menu option or transfer path suggests a system problem. The count turns a vague complaint, “the bot did not understand,” into something you can investigate.

Count the repeat, not only the resolution

Define a repeat event before testing begins. For example, count a repeat when the caller restates the same request, account issue, delivery problem, or payment question after:

  • an English-language menu
  • a language switch
  • a transfer to another agent
  • a failed recognition attempt
  • a response that answers a different intent

The event should be recorded against the call, not treated as a general impression from the transcript. A useful record includes the original issue, the language used, the point where the caller repeated it, and whether the next response addressed the same intent.

This is where call-truth tracking matters. A transcript can look complete while the call path tells a different story. The caller may have reached a transfer, repeated the request, received a partial answer, and then opted out. The operational record should preserve those stages.

A repeat count also prevents a common evaluation mistake. Completion alone can make a call look successful. If the caller reached an answer only after explaining the issue three times, the experience still failed an important test.

Set a threshold before the pilot

Choose a small set of bilingual scenarios that reflect real support work in Ghana. Use cases such as a payment question, a delivery complaint, a booking change, or a request to speak in Twi. Write the expected intent in plain language before the call runs.

Then record:

  • the percentage of calls with at least one repeat
  • the average number of repeats per affected call
  • the menu or handoff stage where repeats begin
  • the percentage of repeated issues resolved without another transfer
  • the number of callers who opt out or abandon after repeating themselves

Do not hide the difficult cases inside an overall average. Separate Twi-first calls, English-first calls that switch to Twi, and calls that move between agents. The repeat pattern can be different in each group.

Set a review threshold before the pilot starts. If a particular flow causes repeated explanations above that threshold, pause that flow and inspect the audio, transcript, first message, and handoff record. The threshold is a decision rule, not a decorative metric.

Use the count to decide what is ready

Asenda Talk lets teams configure the agent persona, first message, and voice, then evaluate the call through its telephony lifecycle and audit records. Native Twi speech recognition and synthesis make the language path part of the system under test. The repeat count should sit beside consent, opt-out, and call-resolution checks.

A high count can point to different failures. The menu may force an English choice before the caller can speak. The recognizer may capture words but miss the intent. The handoff may lose the earlier context. The agent may hear Twi and continue with an English script. Each failure needs a different fix, so the count should lead to a call-level review rather than a single “accuracy” score.

This is also where the Broad Street example returns. John Snow did not get useful evidence from one isolated case. He got it by connecting repeated outcomes to a place and a shared system. For a bilingual support desk, connect repeated explanations to the exact menu, language switch, or handoff that preceded them.

Before enabling a live campaign, run a fixed set of Twi and English calls, inspect every repeat, and record the reason. If callers still have to restate the same issue after a handoff, the flow needs more work, regardless of how polished the voice sounds.

Sources (1)
  1. owlake.comOwlake: AI voice agents and WhatsApp automation, built in Ghana

Asenda Talk

A self-serve platform for building and running voice AI agents, built on native African-language speech (Twi, with more languages in progress) instead of a wrapper around a third-party voice API.

Try Asenda Talk

Comments

No comments yet.