A handled call proves that a voice system stayed connected, not that it understood the customer. When a fraud question triggers a switch from Twi to English, teams must evaluate whether meaning survived the switch and whether the final record supports the action taken.
At 4:18 p.m. in Accra, Ama paused an evaluation recording with one hand still wrapped around a cooling cup of tea. She was a composite support manager reviewing a test call for a bank’s proposed voice agent. The customer had answered routine identity questions in Twi, then reached the disputed transaction.
“I don’t know this payment,” he said in English. A moment later, he returned to Twi to explain where he had been when it happened.
The agent continued. The call remained connected. The dashboard could have counted it as handled.
Ama could not yet tell whether the system had connected the English phrase “this payment” to the transaction mentioned earlier in Twi. If it had lost that reference, the customer’s dispute might be attached to the wrong transaction or recorded too vaguely for a fraud reviewer to act. The call could end politely and still fail at the only moment that mattered.
Language switches carry operational meaning
People do not always change languages at random. A customer may use Twi for the story, then switch to English for a banking term learned from an SMS, a card statement or a previous support call. Another customer may begin in English because the menu expects it, then move into Twi when explaining fear, uncertainty or sequence.
The switch itself can reveal where the conversation became difficult.
In Ama’s recording, the English phrase marked the point where a familiar support call became a fraud report. The customer then used Twi to supply context: what he remembered, what he denied and what he wanted the bank to do. Evaluating each sentence separately would miss the relationship between them.
This is why code-switching requires more than recognizing two languages. The agent must preserve entities, references and intent across both. “That payment,” “the second one” and a Twi description of the same transaction must remain attached to one issue throughout the call. We explore that requirement further in Twi and English Code-Switching: Why Voice Agents Must Preserve Context.
Handled-call volume hides comprehension failures
Handled-call volume answers a narrow operational question: how many calls reached the system’s definition of completion? That definition may include a connected call, a completed script or a final webhook event.
None of those events proves that the customer’s meaning survived.
A useful review asks what happened at the decision point. Did the agent identify the disputed transaction? Did it preserve negation when the customer said he did not authorize it? Did the language change alter the confidence of recognition? Did the agent ask for clarification when the reference became ambiguous? Does the audit trail show what the customer said, what the agent inferred and what action followed?
These questions matter because fluent output can mask weak understanding. A warm voice and a tidy closing sentence may leave reviewers with a reassuring impression even when the underlying record contains a broken reference.
The call record must therefore separate transport success from task success. A telephony lifecycle webhook can establish when a call started, connected and ended. Call-truth tracking can preserve those events. Comprehension still needs its own evaluation criteria, especially around language switches, corrections, denials and requests to stop.
Review the turning point, not only the ending
Ama replayed the transition three times. On the first pass, she listened for recognition errors. On the second, she traced which transaction each pronoun referred to. On the third, she compared the customer’s request with the structured outcome the agent would have produced.
The uncertainty remained. That was the finding.
Instead of marking the call complete, she flagged the exchange for clarification and human review. The proposed deployment stayed in evaluation because the team could not yet defend the fraud record. By the time Ama closed her laptop, the dashboard contained one fewer “successful” call and one more useful piece of evidence.
A practical test set should include calls where speakers move from Twi to English and back again at moments of consequence. Reviewers should score intent preservation, entity continuity, negation, clarification behavior, consent and opt-out handling. They should also inspect the source record rather than relying only on an AI-generated summary, a distinction examined in Opt-Out Complaint Review: Why Source Records, Not AI Summaries, Are Proof.
What Asenda Talk can support today
Asenda Talk is in active early access. Teams can create voice agents, set a persona, choose a voice and define the first message. Its Twi speech recognition and synthesis are fine-tuned in-house rather than passed through a general third-party voice layer. Vapi orchestrates the assistant runtime.
The platform also includes telephony lifecycle webhooks with call-truth tracking, metered billing behind an operator-controlled real-money gate, and consent, opt-out and audit records for every call. Admin secrets are write-only, masked and environment-aware.
Those controls provide the material needed to inspect what happened. They do not turn handled-call volume into proof of comprehension. Teams still need representative Twi and English test calls, explicit review criteria and a human escalation path for consequential ambiguity.
Outbound calling remains gated while the telephony-provider decision is unresolved. Asenda Talk is also still working toward feature parity with established voice-agent platforms. Those limits matter for any team planning a live banking workflow.
Ama’s final note on the test call was short: “Connection completed. Fraud intent unresolved across language switch.” That sentence gave the team a better launch signal than another completed-call count ever could.
Comments
No comments yet.