Scripted campaigns, conversational agents and self-serve builders are different products: a practical evaluation framework for African businesses comparing what is live now with what vendors place on their roadmaps.

Treat scripted campaigns, conversational agents, and self-serve builders as separate products during evaluation. Ask each vendor to show what works in a live environment today, then list every capability that remains planned, gated, or dependent on a third party.

Start with the job the call must do

A scripted campaign follows a defined path. It works well when every recipient should receive the same message, answer a small set of questions, or take a simple action. Examples include appointment reminders, payment notices, event confirmations, and a one-question survey.

A conversational agent handles variable replies. It needs to understand intent, keep context, recover from interruptions, and hand off when it cannot safely complete the task. This is the better fit for support triage, lead qualification, service questions, and conversations where callers may move between Twi and English.

A self-serve builder is the operator-facing product used to create, configure, test, and manage either of those experiences. It may let a team set a persona, first message, voice, prompts, call rules, and reporting without engineering support.

Do not accept “voice AI platform” as the product category. A vendor may offer a strong campaign tool while lacking open-ended conversation. Another may have an impressive demo agent but require vendor staff for every change. Your first requirement should name the actual job, the language used on calls, and who must be able to make changes.

Separate the call experience from the operating model

A capable conversation does not prove that a business can operate it safely at scale. Evaluate the caller experience and the operating model independently.

For the call experience, test the exact scenarios your customers will use. If callers speak Twi, run Twi tests. Include greetings, names, place names, corrections, numbers, silence, interruptions, and Twi-English switching. Ask vendors whether their speech recognition and synthesis are native to the language or supplied through another provider. That distinction affects where model quality, support responsibility, and future improvements sit.

For the operating model, ask who can edit a script or agent, who approves a launch, how a stop request is stored, and how a disputed call is investigated. A campaign can sound natural and still create a compliance problem if opt-outs fail to block retries across every route. Review the practical consent and retry guidance before treating a call log as sufficient evidence.

Require a “live now” column in every comparison

Build a comparison sheet with three columns: live and available, available with a stated prerequisite, and roadmap. Keep the wording exact.

“Live and available” means your team can use the capability in the environment you plan to operate. “Available with a prerequisite” means it works only after a specific condition is met, such as a provider account, approved phone numbers, a production credential, or an operator decision. “Roadmap” means it should not influence a launch decision until the vendor can demonstrate it.

This distinction matters especially for telephony. A platform may have an agent builder, speech models, webhook handling, and call-status records while outbound production calling remains gated by an unresolved telephony-provider decision. That is meaningful progress, but it is not a live outbound calling offer. Asenda Talk’s telephony status explains why this boundary should be visible during procurement.

Ask for a written answer to these questions:

• Can we place and receive production calls today in our intended market?
• Which provider, account, number type, and approval steps are required?
• What happens if a call disconnects, fails to start, or receives a stop request?
• Which items are planned rather than currently available?
• Can we test the same configuration before committing budget?

A vendor that clearly names limits is easier to evaluate than one that uses future capability to answer a present-tense question.

Test evidence, not dashboard labels

Terms such as “completed,” “connected,” and “started” can mean different things across platforms. For a campaign team, the useful question is whether the system can show the call’s actual lifecycle: attempt, connection, conversation outcome, disconnect, retry eligibility, and final disposition.

Ask to inspect webhook events or records for a small test set. Trigger a declined call, a disconnected call, an opt-out, and a successful outcome. Then confirm that the audit trail connects each event to the correct call and that an opt-out prevents the next retry.

This is also where billing needs scrutiny. Per-minute pricing can be appropriate, provided the system records usage accurately and gives the operator control before real money is spent. Confirm who opens the spending gate, what meter is used, and how the operator reconciles a disputed charge with call-truth data.

Match the builder to the team that will run it

Self-serve does not mean every setting should be editable by everyone. A campaign manager may need to change the first message and approved script branches. A technical administrator may need to control telephony settings, credentials, environments, and billing gates.

Look for role boundaries that match that reality. Secrets should be write-only and masked after entry. Production credentials should not appear in shared configuration screens. Separate test and production environments prevent a prompt experiment from becoming a customer call.

Asenda Talk currently provides agent configuration, in-house Twi speech recognition and synthesis, a Vapi-orchestrated assistant runtime, lifecycle webhooks, metered billing controls, consent records, and masked environment-aware secret management. It is in early access and is still moving toward feature parity with established voice-agent platforms. Treat those limits as planning inputs, especially where production telephony is involved.

Run a bounded evaluation before choosing

Choose one call type, one language mix, and one success measure for a short evaluation. For example, test inbound Twi-English service triage and measure whether callers reach the right outcome, whether agents recover after interruptions, and whether your team can audit each disposition.

Bring your own scripts, consent wording, escalation rules, and representative test calls. Do not score a vendor on an idealized demo. Score the system on the paths that produce customer risk or operational work.

Before the next vendor meeting, create the three-column comparison sheet and add one line for telephony readiness, language behavior, consent enforcement, audit evidence, billing control, and configuration ownership. Require a demonstration or documented limitation for every line.