Splitting a mixed Twi and English utterance between two recognizers can remove the words that connect intent, identity, and urgency before a support workflow sees it. A bilingual voice agent needs to preserve the whole turn, then confirm the details that determine the next action.
At 8:17 on a rainy Monday in Kumasi, Ama, a composite customer-support lead, is holding a paper order slip beside her desk phone. Her daughter’s schoolbag is open on the floor. A caller says, “Medaase, but my order no, I need it before the programme tomorrow.”
The English recognizer catches “I need it before the programme tomorrow.” The Twi recognizer catches fragments around “Medaase” and “order no.” Neither transcript reliably carries the relationship between them: the caller is not making a general delivery request. She is referring to her specific order and a deadline that changes what the support team should do next.
Ama’s queue already has unanswered calls. If the workflow treats this as a standard enquiry, the order may remain where it is. The caller could arrive at tomorrow’s programme without what she paid for.
One utterance carries one intent
Code-switching is normal conversation for many Ghanaian callers. A person may use Twi for ownership, emphasis, relationship, or the part of the sentence that feels most natural, then switch to English for a product name, date, delivery status, or a formal request.
Two-pass transcription creates a risky handoff. One system listens for English. Another listens for Twi. A later step tries to stitch the results together.
By then, the useful meaning may already be broken apart.
Words do not merely sit beside each other in a support call. They establish what a caller is referring to, what they want done, and how soon it matters. If “my order” lands in one transcript and “before tomorrow” lands in another, a workflow may still detect delivery-related words. It may miss the instruction that should raise the case.
This matters most where automated routing makes decisions from transcripts: delivery escalations, billing disputes, missed appointments, callback requests, and consent or opt-out requests. A partial transcript can send a caller to the wrong queue with complete confidence.
The failure often appears after transcription
The recognizer is only the first link in the chain. Once a mixed-language sentence arrives as two imperfect fragments, downstream steps inherit the uncertainty.
A classifier may tag the call as “order status.” A summarizer may produce a neat English sentence that omits the caller’s ownership of the order. A support agent may see an apparently complete note and have no reason to replay the audio. The error becomes harder to spot precisely because the workflow looks orderly.
For Ama, the first transcript could lead to a routine callback. The caller’s actual message had a narrow window: the item was needed for an event the next day. That difference is the difference between a standard queue and a human handoff.
The useful test is not whether each recognizer produces plausible words in isolation. Test whether the final record preserves the intent of the full turn. Can the system identify the item, the requested action, the deadline, and the language switch without guessing?
What Happens When a Billing Caller Switches Between English and Twi Mid-Sentence? explores the same problem when the missing detail affects a payment conversation.
Preserve the turn before deciding what it means
A safer design keeps the audio and transcript associated with one caller turn, even when the language changes inside it. It records language uncertainty rather than silently replacing uncertain words with a confident summary.
That does not mean every mixed-language turn can be automated. It means automation has a clear condition for stopping.
For a support workflow, define the details that require confirmation before action: account or order reference, payment amount, callback number, delivery date, opt-out request, and escalation deadline. If any one of those details is unclear after transcription, the agent should ask a short confirmation question or pass the call to a person.
Asenda Talk is being built around native, in-house Twi speech recognition and synthesis, alongside English conversation, rather than routing Twi through a third-party wrapper. It currently lets early-access teams configure agent persona, first message, and voice, with Vapi orchestrating the assistant runtime. Teams should still evaluate mixed-language calls against their own vocabulary and call types before relying on automation.
Outbound calling remains gated behind an explicit telephony-provider decision that is not yet live. The call lifecycle pipeline, consent handling, opt-out records, audit trail, and call-truth tracking are important controls for any future calling workflow. They do not repair a lost meaning upstream. The transcript and confirmation design have to do that work first.
Test the switches your callers actually make
Ama does not need a language demo. She needs a workflow that catches the meaning of a caller’s request before it sends the case onward.
Her test set should include complete customer turns, not isolated English and Twi clips. Include product names in English inside Twi sentences, Twi ownership words around English order references, corrections after an agent repeats a detail, and urgent requests where one missing phrase changes the queue.
Then review the output as a support lead would. Does the transcript preserve what the caller meant? Does the routing decision match it? Can an agent inspect the original turn when the system is unsure?
The next morning, Ama’s team can see the caller’s full request in one call record, flag the time-sensitive delivery, and avoid turning a bilingual sentence into a generic ticket.
Comments
No comments yet.