Twi Stop Requests: How to Block Every Call Route Before the Next Retry

A Twi request to stop calls must be captured as an opt-out immediately, enforced against every eligible calling path before another call is placed, and retained with enough evidence for a later review. A transcript alone is insufficient: the campaign team needs a durable suppression record, the call event that created it, and proof that later call attempts were blocked.

In London in 1854, physician John Snow investigated a cholera outbreak centered near the Broad Street water pump. He mapped deaths and gathered accounts from local residents while the cause of cholera was still disputed. Snow’s findings helped prompt the removal of the pump handle. The outbreak was already declining, and the episode did not settle the scientific debate on its own, but it gave public health officials a concrete way to interrupt a suspected source of harm while the evidence was still being assembled.

Steven Johnson recounts the investigation in The Ghost Map. Its useful lesson for a voice campaign is modest but important: when a credible signal says “stop,” the next action should not depend on a later analyst finding the right recording, transcript, or spreadsheet row.

Turn a spoken stop request into a durable decision

A customer may say “don’t call me again” in Twi, English, or a mix of both. Your system should treat the meaning as the event that matters, then retain the language evidence that supports the decision.

For each stop request, capture:

• The contact identifier used for the call, in a form that matches the audience or calling list.
• The call ID, agent ID, campaign or workflow ID, and timestamp.
• The detected opt-out intent and the words or transcript segment that led to it.
• The language context, especially when the conversation moved between Twi and English.
• The source of the decision: automated detection, human review, or a manual correction.
• The suppression scope and effective time.

The distinction between capture and enforcement matters. A campaign manager may be able to find a transcript showing that a customer asked to stop. That does not prove the customer has been removed from the next outbound queue.

Native Twi recognition deserves evaluation here because an English-first transcript can lose the meaning of a short request, particularly in a mixed-language call. Asenda Talk is built around native Twi speech recognition and synthesis fine-tuned in-house. Teams should still test the phrases, accents, code-switching patterns, and conversational context that occur in their own campaigns before relying on any automated classification.

Block the next call across every route

An opt-out must change the eligibility decision before the next automated call. That means checking suppression at the point where a call is about to be initiated, not only when a list is first uploaded.

A practical control is simple: every new outbound call request checks the current suppression status for that contact. If the contact is suppressed, the system records a blocked attempt and does not initiate the call. If the campaign uses multiple lists, agents, integrations, or retry workflows, each route must use the same suppression decision.

This is where timing exposes weak designs. A customer could ask to stop during an afternoon call while a retry job has already prepared an evening call. If suppression only runs during list import, the campaign can call again even though the stop request exists somewhere in the records.

Asenda Talk has consent, opt-out, and audit-trail capabilities for every call, along with telephony lifecycle webhooks and call-truth tracking. Those capabilities support the workflow, but the operating rule needs to be explicit: a stop request takes priority over pending retries, scheduled calls, and list membership until an authorized process changes that status.

For a related operating standard, see A Twi Stop Request. No Further Calls Until Suppression Is Proven.

Preserve evidence that can survive a dispute

When someone disputes a later call, the team needs more than a statement that “the system handled it.” It needs a sequence of events.

The audit record should show the original call, the opt-out capture, the suppression decision, and any later attempt that was blocked or allowed. If a call was allowed after a prior stop request, the record should make the failure visible rather than hiding it behind a generic campaign status.

Review these cases regularly:

• A Twi stop request with a low-confidence transcript or unclear intent classification.
• A contact whose phone number appears in more than one audience.
• A manual change that removed or altered suppression.
• A call initiated close to the opt-out timestamp.
• A provider webhook that arrived late, failed, or could not be reconciled to a call record.

Call-truth tracking is useful because billing events, telephony lifecycle events, and customer consent events can otherwise live in separate places. The same discipline helps when reconciling call charges, as covered in What Happens When Billed Voice Minutes Cannot Be Matched to Call Events?

Make the control real before outbound calling goes live

Asenda Talk is in active early access. Its outbound calling path remains gated behind an explicit telephony-provider decision that has not been made live. That is the right time to define the stop-request rule, test it with realistic Twi and mixed Twi-English conversations, and decide who can override a suppression record.

Run a controlled test before enabling paid calling. Create a contact, place a test call, issue a stop request in Twi, confirm the audit event, then attempt a scheduled retry through every campaign route. The expected result is a recorded block, with no new call initiated.

John Snow did not wait for every question about cholera to be settled before acting on the evidence he had. A campaign team should apply the same restraint at a smaller scale: when a customer withdraws permission, pause the next call first. Investigate and refine the detection later.