Review a Voice Campaign Retry Before Calling Anyone Again

A voice campaign retry review should explain why another attempt is appropriate. “Failed” is not enough information. A busy recipient, an invalid destination and a setup failure require different responses, and some unresolved outcomes should be investigated before anyone is called again.

Burki's campaign history and controlled failure explanations help an operator distinguish previous attempts from the next run. Use them to make a deliberate retry decision rather than treating a rerun button as a general repair tool.

Read the reason behind the outcome

Start with the actual attempt. Was the call admitted? Did the carrier report an answer? Did a conversation occur? Was the intended business action completed? These questions should not be collapsed into one status.

Provider status values describe call behavior within their own systems. For example, Twilio documents its statuses in the Call resource reference. A provider status is useful evidence, but it is not a universal definition of successful customer contact.

If a call failed before reaching the recipient, repair the configuration or funding problem before considering another attempt. Repeating the campaign cannot make an invalid prerequisite disappear.

Review eligibility as it exists now

A person who was eligible during the first run may no longer be eligible. Recheck current suppression, permissions and the business reason for contacting them. A failed call does not grant new consent or override a later preference.

Review timing and attempt limits too. The next run should use the intended schedule and source number, not assumptions carried over from an earlier launch.

The campaign guide provides the broad workflow. The actual rerun review should show current contacts and outcomes so the operator can judge the next attempt from fresh information.

A hypothetical busy result

Imagine an authorized callback attempt that receives a busy result and no connected conversation. Staff may decide a later attempt is appropriate under the business's approved process.

Before relaunching, they check the recipient's current preference, the proposed time and the maximum attempt count. They keep the first attempt in history and make the later attempt visible as a separate run decision.

Now change the example to an uncertain call outcome. The operator cannot establish whether the recipient was reached. That case needs inspection first. Treating uncertainty as ordinary failure can produce an unwanted repeat call.

Avoid retrying completed business work

A call can have an imperfect ending after a useful action already happened. If an appointment or request was created, staff should inspect that action before using the campaign outcome to justify another call.

Likewise, a completed telephone connection does not prove that the customer received the intended information. Review the evidence relevant to the campaign's purpose rather than assuming connection status answers every business question.

This is why the run record should retain the call identity and available outcome details. A summary count alone is too coarse for deciding which individual contacts need another attempt.

Use a short approval worksheet

For each proposed retry group, record the original reason, evidence reviewed, remaining prerequisites, intended time, attempt limit and approving operator. Exclude contacts whose outcome or permission remains unresolved.

Check the actual contact list when the rerun dialog opens. If data is still loading or cannot be refreshed, do not approve from a remembered count. Changes made by another operator or an earlier import may affect the eligible audience.

The contact-management guide helps with audience preparation, but contact presence alone does not establish retry eligibility.

After the new run, compare its results with the previous run using the run filter. Keep both visible in history so the team can explain what changed and whether the repair worked.

Before your next retry, choose one failed contact and write the reason you believe another call will produce a different and appropriate outcome. If that reason is simply “the system said failed,” inspect the attempt more closely before launching.