A procurement brief for voice automation should put verified language coverage before workflow features when callers move between Twi and English. A live call test can reveal failures that a feature checklist, English demo, or polished dashboard will miss.
Consider an illustrative Monday morning in Accra. Esi, a support-desk lead with a chipped blue mug beside her laptop, is evaluating tools to handle routine calls. Her draft brief prioritises ticket creation, call routing, CRM fields, and reporting.
At 9:17, she asks Kwaku, a colleague from the finance desk, to play a customer in a live test. He starts in English, switches to Twi while explaining the problem, then returns to English for the account details. The agent produces a confident response, but it has misunderstood the Twi explanation. If this happened on a real call, the wrong issue could enter the support queue and the customer might receive an irrelevant answer. Esi stops taking notes.
The workflow passed while the conversation failed
The demo had completed several visible tasks. It answered promptly. It followed the configured greeting. It captured a reference number and selected a workflow.
Those successes made the deeper failure easy to miss. The system had moved the call forward without understanding the part that explained why the person called.
For a Ghanaian support desk, language coverage cannot be reduced to a dropdown labelled “multilingual.” The useful questions are more demanding: Can the system recognise natural Twi? Can it respond in Twi? What happens when a caller changes language halfway through a sentence? Does the transcript preserve the request, or quietly replace uncertainty with plausible English?
That last failure is especially dangerous because clean output can look trustworthy. What Happens When a Twi Request Disappears From an English Transcript? examines the operational consequence: the record may appear complete while the caller’s actual request is missing.
Esi’s first brief treated language support as one row in a comparison table. After the call, she moves it to the top and changes the wording from “supports Twi” to “demonstrates Twi recognition and speech in a live, mixed-language scenario.”
Replace language claims with testable evidence
Vendor claims often compress several different capabilities into one phrase. “Supports African languages” might describe translated scripts, a general-purpose model, prerecorded prompts, or a roadmap item. None of those proves that a voice agent can handle a natural Twi conversation today.
A stronger procurement process turns every important claim into an observed test.
Prepare short call scenarios based on the work the desk actually handles. Include a caller who begins in Twi, inserts an English product term, corrects a detail, and asks to opt out. Ask a fluent reviewer to judge the recognition, spoken response, meaning, and recovery when the agent is uncertain.
Keep the test narrow enough to diagnose. If the agent misunderstands the request, you need to know whether speech recognition, reasoning, synthesis, orchestration, or workflow mapping caused the failure. A final pass or fail score hides that distinction.
Save the transcript, audio where consent permits, call outcome, and reviewer notes. Test evidence should survive the sales meeting.
Procurement must follow the whole call
Language accuracy is the first gate, but it cannot be the last. A production voice system also needs a reliable record of what happened before, during, and after each call.
Can the team distinguish an attempted call from an answered one? Can it trace webhook events through the telephony lifecycle? Are consent, opt-out, and audit records attached to each call? Can administrators manage secrets without exposing stored values? Does billing remain disabled until an authorised operator deliberately opens the real-money gate?
These checks matter because a fluent conversation can still create operational harm. An opt-out that never reaches the calling system is one example; What Happens When a Voice Agent Ignores a Customer’s Opt-Out? shows why consent controls belong inside the system design.
Asenda Talk’s current early-access platform lets teams configure an agent’s persona, first message, and voice. Its Twi speech recognition and synthesis are fine-tuned in-house rather than passed through a third-party Twi wrapper. Vapi orchestrates the assistant runtime, while Asenda Talk tracks the call lifecycle, metered usage, consent, opt-outs, and audit events.
The caveat belongs in the same paragraph as the capability: outbound calling remains gated while the live telephony-provider decision is unresolved. Early-access buyers should evaluate what works now and record the remaining gap explicitly.
Rewrite the brief before comparing vendors
By lunchtime, Esi has removed “multilingual support” from the feature checklist. In its place is a test protocol: one live Twi call, one mixed Twi and English call, one correction, one opt-out, and an inspection of the resulting records.
Workflow automation still matters. So do integrations, reporting, configuration, and price per minute. They enter the comparison only after the agent proves it can understand the person whose request starts the workflow.
On Tuesday morning, Esi’s chipped blue mug is back beside the laptop. The procurement meeting now begins with a call, not a slide deck.
Comments
No comments yet.