Ghanaian teams can use the six days before September 15 to turn a real Twi-English voice failure into a small, testable prototype for the Sahara CodeSwitch Africa Challenge. Start with one call that currently breaks down, then build the smallest agent flow that can recognise the switch, respond clearly, and record what happened.
At 4:40 p.m. in Kumasi, Ama is holding a notebook beside a support desk phone while a caller repeats a delivery question in Twi. The agent’s script has already continued in English twice. The caller is quiet now, then says she will call back later.
Ama has one more hour before the desk closes its daily queue. If the issue stays unclear, the request may be logged under the wrong category or never reach the person who can resolve it. That is the real failure to bring to a challenge: a customer’s meaning disappears during the handoff between languages.
This is an illustrative composite, but the situation is useful because it is narrow. It gives a team something to build, test, and explain before September 15.
Choose one voice moment that carries a real cost
A prototype does not need to solve every customer call. It needs to make one important moment work better.
Pick a moment your team can describe without jargon. A farmer reports a pest problem in Twi, then gives a location in English. A campaign caller hears “stop calling me” in Twi. A support caller asks the same question again because the first answer missed the point. A shop owner switches languages halfway through checking an order.
Write down four things before you open a builder:
- What the caller is trying to achieve.
- The exact point where the current experience fails.
- The bad outcome if it fails again.
- The one action your prototype should take next.
That last point matters. An agent that understands a caller but cannot make a useful decision still leaves work for the desk. A good challenge prototype might capture the request, classify it for follow-up, repeat the next step in the caller’s language, or stop a contact attempt when the caller opts out.
For ideas around repeated requests and missed meaning, see A Twi caller repeats a request. The bot may have missed the intent.
Build the conversation around language changes
Code-switching is often the point where a generic voice flow loses the thread. A caller may begin in English, move into Twi for the important part, then use English again for a name, place, or order reference. Treat that shift as part of the conversation design.
With Asenda Talk, teams can configure an agent’s persona, first message, and voice, then evaluate a flow using native Twi speech recognition and synthesis fine-tuned in-house. The platform is in early access. Its current work is focused on building and evaluating these voice-agent experiences, with more African languages in progress.
Keep the first message short. Make it clear what the caller can ask for. Then give the agent a simple recovery path when the meaning is uncertain: ask the caller to repeat the relevant detail, confirm what was heard, or route the request for review.
Ama’s team could build a prototype that says, in the language the caller is using, “I want to make sure I understood. Are you asking about the delivery date or the delivery location?” That is a small turn in the call. It can prevent a wrong ticket, a frustrated callback, and a desk team guessing from an incomplete transcript.
The goal is not to make a demo sound clever. The goal is to show that the agent has a sensible next move when a real conversation changes language.
Treat consent and call records as part of the prototype
Voice prototypes can create trust problems quickly if they treat consent as an afterthought. Build the boundary into the flow from the beginning.
Asenda Talk includes consent, opt-out, and an audit trail for every call, alongside telephony lifecycle webhooks that track call truth. For a challenge entry, this gives teams a concrete way to show what the agent said, what the caller chose, and what happened after the call.
If your scenario includes an outbound call, state the constraint accurately. Outbound calling is currently gated behind an explicit telephony-provider decision that has not been made live. Do not present a planned calling path as available functionality. A prototype can still demonstrate the agent logic, consent wording, opt-out handling, and lifecycle events without claiming that live outbound calls are ready.
That honesty makes the work stronger. It shows evaluators that your team understands the difference between a convincing voice interaction and a production-ready calling operation.
For a practical consent-focused scenario, read Twi Voice Pilot Consent: Why Every Call Needs a Verifiable Record.
Use the remaining days to test one difficult turn
Do not spend the week polishing a broad pitch deck while the call itself remains vague. Put the difficult exchange in front of people on your team who naturally move between Twi and English. Listen for the words they would actually use when confused, impatient, or ready to end the call.
Then test the same moment three ways: a clean English version, a clean Twi version, and a mixed-language version. Compare where the agent understood, where it guessed, and where it needed to ask a better question.
When Ama listens back to her prototype, the caller no longer has to repeat the whole problem. The agent confirms that the issue is the delivery location, records the request for follow-up, and gives a clear next step. The desk receives a usable handoff instead of a half-understood call.
That is enough to enter with: one real frustration, one defined risk, and one voice flow that handles it with care before September 15.
Comments
No comments yet.