A speech layer should be evaluated on the language customers actually use, including accents, code-switching, short affirmations and consent phrases. If it was built mainly for another market, a polished demo can hide the errors that matter most in a Ghanaian banking call.
At 9:12 a.m. in an Accra meeting room, Kojo, a bank engineer with cold coffee beside his laptop, reaches the final slide of a pilot architecture review. The call flow works. The webhook events arrive. The transcript looks tidy.
Then the risk lead asks, “Was the speech layer trained for Ghanaian customers?”
Kojo pauses. This is an illustrative composite, but the decision in front of him is concrete: give a precise answer, or watch the pilot return to technical review with no approval date. The next meeting is already crowded with other projects. If this one slips, the test group loses its slot.
The speech model changes the risk assessment
The question reaches beneath the architecture diagram. A voice agent can connect a call, play a first message and pass text between services while still misunderstanding the customer.
That weakness becomes harder to spot when evaluation samples are clean English recordings. A Ghanaian customer may begin in English, switch to Twi when explaining a disputed charge, then use a brief affirmation that depends on the preceding sentence. The system has to preserve the meaning across those turns.
A generic speech API may perform well on broad benchmarks and still struggle with the language patterns present in the bank’s own calls. The review therefore needs evidence from relevant speech, not an assurance that the underlying provider supports “multiple languages.”
Asenda Talk’s Twi speech recognition and synthesis are fine-tuned in-house. That gives an engineering team a direct object to inspect and evaluate. It also creates a clear boundary: Twi is built and available for evaluation today; additional African languages remain in progress.
The distinction matters when the pilot involves a customer switching between Twi and English during a dispute. The bank needs to test whether intent survives the switch, especially around amounts, denials, corrections and agreement.
A connected call proves very little
Kojo moves back one slide. The diagram shows Vapi orchestrating the assistant runtime, with telephony lifecycle events entering a webhook pipeline. He stops describing the happy path and opens the event record instead.
The useful question changes from “Did the call connect?” to “What can we prove happened?”
A completed status cannot establish that the right person answered, that consent existed, that an opt-out was recognised or that the agent understood the customer’s final instruction. Those facts require separate events and an audit trail that preserves what the system observed.
Asenda Talk includes call-truth tracking through its telephony lifecycle webhook pipeline, along with consent, opt-out and audit records for each call. Metered per-minute billing also sits behind an operator-controlled real-money gate. That gate matters during early access because a configuration error should not quietly become a live calling bill.
For a bank review, these controls should appear as test cases:
- Trace one call from initiation through its final telephony state.
- Confirm how consent is recorded before the agent proceeds.
- Test opt-out phrases in Twi, English and mixed-language turns.
- Reconcile billed minutes against the recorded call lifecycle.
- Verify that administrators cannot read stored secrets after entry.
A deeper compliance review should also separate call completion from consent evidence, as explained in why a completed call does not prove consent.
The pilot needs claims that can survive testing
The risk lead asks Kojo to replay three evaluation calls. One contains a customer correcting the agent in English. Another includes a switch into Twi halfway through an explanation. The third tests an opt-out.
For a few seconds, the room is quiet. A fluent opening would mean little if the agent missed the withdrawal of consent near the end.
The review turns when Kojo shows the transcript beside the lifecycle and audit events. The team can now identify which layer produced each result: speech recognition, agent reasoning, speech synthesis, telephony state or compliance handling. A failure has somewhere to go.
That is the standard an early-access platform should meet. It does not need to pretend it has reached feature parity with Vapi, Retell AI or Bland AI. It does need to state what works, expose what can be evaluated and mark what remains gated.
Outbound calling is one such boundary. Asenda Talk has the calling pipeline, per-minute metering and operator gate, but the live telephony-provider decision has not yet been made. A responsible pilot plan should therefore avoid presenting unrestricted outbound calling as available. It should define the evaluation around the capabilities that can be demonstrated now, then make provider activation a separate approval.
Put the language evidence in the review pack
Before the meeting ends, Kojo replaces the broad “multilingual support” line in the pilot document. In its place, he lists the actual evaluation set: Twi, English, mid-call switching, short affirmations, corrections, consent and opt-out language.
The pilot proceeds to a scoped technical evaluation because the architecture review now has evidence to examine and boundaries it can enforce.
The next morning, Kojo’s coffee is still beside the laptop. This time, the review pack opens with recordings and event traces rather than a provider logo.
Comments
No comments yet.