A repeated account detail is a signal to inspect the speech layer before rewriting the call script. If the agent mishears a Twi phrase, clearer prompts will only make the wrong interpretation more consistent.
At 8:07am, Kojo, a support lead in Accra, heard the caller give the same account detail twice. She slowed down the second time, separating each word while Kojo held a cooling cup of tea and watched the transcript update beside the call status.
The agent still responded as though she had supplied a different detail.
This is an illustrative composite, but the risk is concrete. If the agent records the wrong account information, the support request may attach to the wrong record or fail altogether. The caller could hang up believing the issue was logged when the system had captured something else.
Kojo’s first instinct was familiar: revise the script. Add a stronger instruction. Tell the agent to confirm important details.
Then he replayed the same phrase.
Repetition is evidence, not reassurance
A caller repeating herself can look like successful recovery. The agent asks again, the caller answers again, and the conversation moves forward. The call may even reach a completed state.
But repetition only helps when the system can recognize the answer accurately. If both attempts produce the same incorrect transcription, the script has done its job while the speech layer has failed.
That distinction matters in bilingual support calls. A caller may begin in English, switch to Twi for the detail that feels easier to express, then return to English. The hardest part of the conversation can sit inside that switch. This pattern deserves direct testing, as explored in What Happens When the Hardest Part of a Support Call Switches to Twi?.
Kojo stopped treating the repeated question as a dialogue problem. He marked the timestamp, saved both recognition outputs, and compared them with the audio.
The question changed from “How should the agent ask this?” to “What did the speech system hear?”
Test the speech layer before touching the prompt
A useful evaluation starts with the smallest unit that could have failed. In this case, that unit is the caller’s spoken account detail.
Replay the original audio and inspect the recognition result for each attempt. Did the system miss the same word twice? Did it split a phrase incorrectly? Did the error appear when the caller switched languages, spoke more slowly, or placed an English account term inside a Twi sentence?
Next, test the phrase independently of the full call. Use several natural pronunciations and speaking speeds. Include background noise representative of the intended calling environment, but keep each test controlled enough to identify what changed.
Then check synthesis. If the agent reads the captured detail back, can a Twi-speaking reviewer understand it without relying on the transcript? Recognition and synthesis can fail at different points, and a polished voice does not prove that the underlying detail survived the exchange.
Asenda Talk’s Twi speech recognition and synthesis are fine-tuned in-house. That makes the speech layer something the team can evaluate and improve directly, rather than treating language performance as an opaque result from a third-party voice wrapper. The platform remains in active early access, so this work should be approached as measured evaluation, not assumed parity with established voice-agent platforms.
The call record must show what actually happened
At 8:19am, Kojo had three artifacts open: the audio, the transcript, and the call lifecycle record. The agent had reached its configured closing message. That alone could not establish that the account detail was correct.
A reliable review needs to separate conversational completion from task completion. Did the caller provide the detail? What did recognition produce? What value did the agent confirm? Did the downstream action use that same value? If the caller corrected the agent, did the final record preserve the correction?
Asenda Talk includes a telephony lifecycle webhook pipeline with call-truth tracking, plus consent, opt-out, and audit records for each call. Those records create a place to inspect what the system did at each stage. They do not turn a green status into proof by themselves. The evidence still has to agree.
The same caution applies when a caller moves between languages. A completed status can conceal a disputed phrase or an abandoned correction. What Really Happened When the Bilingual Call Was Marked Complete? examines that gap in more detail.
Turn one repeated phrase into a release test
Kojo left the script unchanged.
Instead, he added the phrase to a speech evaluation set with the original audio, the two incorrect outputs, and the expected interpretation. Before that workflow could be trusted, the team would need to test close variants and confirm that the call record retained the right value from speech input through the final action.
That is the practical value of the first repeated question. It gives the team a reproducible case. One timestamp can become a regression test for the next speech-model update, a review checkpoint for bilingual calls, and a reason to block a workflow until the captured detail is verifiable.
For Asenda Talk, outbound calling is still gated behind an explicit telephony-provider decision that has not been made live. The operator-controlled real-money gate should remain part of that boundary. A voice agent should not place metered calls merely because its script reads well in a configuration screen.
By 8:31am, Kojo’s tea was cold. The prompt had no new paragraph. The evaluation set had one difficult phrase it had lacked that morning, tied to the exact moment the system needed to prove what it heard.
Comments
No comments yet.