> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Batch Calling Rules & Retries

> Configure how a batch handles calls that don't connect: screening gates, per-outcome retry policies with backoffs, cancelling retries when a contact calls you back, and the end-of-day summary email.

## What are Calling rules?

Every batch carries a set of **Calling rules** — the guardrails that sit around the dialling itself. They cover three things: **Screening gates** (who may be dialled at all), the **Retry policy** (what happens when a call reaches voicemail, rings out, hits a busy line, or fails for a temporary reason), and the **End-of-day summary** (a daily email digest of how the batch performed).

You'll find them on the batch edit page:

**Batch Scheduler → *(your batch)* → Settings**

Scroll below the Schedule section to the **Calling rules** heading, described as *"Screening gates, retry policy, and end-of-day summaries."* Changes take effect when you click **Save** in the batch header.

Calling rules answer a different question from the [Schedule settings](/batches/scheduling): scheduling decides *when* fresh calls are placed; calling rules decide *whether* each contact may be dialled and *what happens after* an attempt that doesn't connect.

***

## Screening gates

Before a queued contact is dialled, it is checked against each screening gate you have enabled. As the card puts it: *"Contacts that fail an enabled screening gate are blocked from dialling."*

| Gate                  | Description (as shown in the app)                                                    | Default |
| --------------------- | ------------------------------------------------------------------------------------ | ------- |
| **DNCR**              | Blocks numbers listed on the ACMA Do Not Call Register.                              | On      |
| **Opt-out**           | Blocks contacts who opted out on a previous call.                                    | On      |
| **Previously called** | Blocks contacts who already have a call record (this batch's own attempts excluded). | Off     |

Each gate is a simple switch on the card. Retry attempts are re-screened before they dial, so a contact who joins the Do Not Call Register or opts out between attempts is not called again.

Screening is deliberately cautious — if a check cannot complete, the contact is held rather than risked. The full behaviour, including how the queue reports blocked and held contacts, is covered in the [Batch Screening Gates](/batches/screening-gates) deep dive.

The card also notes: *"Other custom screening gates available upon request."* Speak to the Voxworks team if you need a screening gate beyond the three built-in ones.

***

## Retry policy

The **Retry policy** card — *"what to do on voicemail, no-answer, busy"* — controls automatic follow-up calls for attempts that didn't reach the contact. Each row is one call outcome with three columns: **Max attempts**, **Backoff (hours)** and an **Active** indicator.

### Default policy

| Outcome             | Max attempts | Backoff (hours) |
| ------------------- | ------------ | --------------- |
| **Voicemail**       | 3            | 24, 48, 72      |
| **No answer**       | 2            | 4, 24           |
| **Busy**            | 3            | 1, 4, 24        |
| **Transient error** | 2            | 1, 4            |

Read each row as: after the first attempt hits this outcome, retry after the first backoff value; if the retry hits it again, wait the second value; and so on, up to **Max attempts** retries. With the defaults, a contact whose calls keep reaching voicemail is tried again roughly 24, 48 and 72 hours after each attempt, then left alone.

### Editing the policy

* **Max attempts** — a number from 0 to 10. Setting it to **0** switches retries off for that outcome; the **Active** switch on the row simply reflects whether any attempts are configured.
* **Backoff (hours)** — a comma-separated list of waits, one per attempt (for example `1, 4, 24`). If you allow more attempts than you list backoff values, the last value is reused for the extra attempts. Attempts you add without a backoff value default to 24 hours.

### How a retry actually runs

A retry is not an instant redial. When an attempt ends in a retryable outcome:

1. A new entry is added to the batch [queue](/batches/queue) for the same contact, with its attempt counter increased — the Queue tab shows repeat attempts as **×2**, **×3** and so on in the **Att** column.
2. The entry becomes eligible to dial only after the backoff has elapsed, measured from when the previous call ended.
3. From there it is planned like any other queued contact: it waits for the next available slot inside the batch's business hours and daily caps, and is re-screened against the enabled screening gates before dialling.

So a "1 hour" backoff means *at least* one hour — if the backoff expires outside your calling window, the retry lands in the next window instead.

A contact's attempt counter accumulates across outcomes. If a contact has already been retried twice — for any mix of reasons — a further retry is only created when the latest outcome's **Max attempts** allows more than two retries.

Every retry is a normal billed call attempt, so review the policy before you launch a large batch — with the defaults, a single unreachable contact can generate up to three follow-up calls.

### What is never retried

* **Completed** calls and calls the contact ended (Hang Up) — the conversation happened; there is nothing to retry.
* **Cancelled** calls.
* **Permanent failures** — calls that failed because the number is invalid or the batch is missing required configuration are never retried, because a repeat attempt cannot succeed. Only temporary faults are retried.

***

## How outcomes are classified

Each finished call is classified into one of the four retry outcomes based on its call status and end reason (see [Call Statuses](/calls/statuses) for the full list):

| Retry outcome       | Triggered by                                                                                                   |
| ------------------- | -------------------------------------------------------------------------------------------------------------- |
| **Voicemail**       | The call ended with the **Voicemail** status — the agent reached the contact's voicemail rather than a person. |
| **No answer**       | The call **Rang Out**, or ended with a no-answer or ring-timeout reason — the phone rang but nobody picked up. |
| **Busy**            | The line was busy or engaged when the agent dialled.                                                           |
| **Transient error** | The call **Failed** or ended as a **Dropout** due to a temporary network or provider fault.                    |

Calls that don't match any of these — including permanent failures — complete their queue entry with no retry created.

***

## Cancel on inbound

Below the retry table sits a single toggle:

> **Cancel pending retries when contact calls back inbound** — *Stops a retry from dialling out to someone who already reached you.*

It is **on** by default. When a contact with pending retries calls one of your numbers, their unlaunched retry entries are cancelled — there is nothing more awkward than your agent ringing someone an hour after they already spoke to you.

A few details worth knowing:

* Only retries that have **not yet dialled** are cancelled (entries still Pending or Planned in the queue). A retry that is already on a live call is not recalled.
* Only **retry** entries are affected. A contact's original, not-yet-attempted first call stays in the queue.
* Cancelled entries remain visible in the Queue tab with the status **Inbound returned**, so you can see exactly which follow-ups were dropped and why.
* The cancellation applies per batch according to each batch's own toggle — a batch with the toggle off keeps its retries even if the contact calls in.

***

## End-of-day summary

The **End-of-day summary** card — *"daily email digest of completed calls, outcomes, retries"* — configures a per-batch email recap. It is **Disabled** by default; use the switch on the card header to enable it.

| Setting                          | Description                                                                                                            | Default |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------- |
| **Send time** (batch local time) | The time of day the digest is generated, in the batch's timezone (set in the [Schedule section](/batches/scheduling)). | 18:00   |
| **Recipients**                   | Comma-separated email addresses, e.g. `team@example.com, ops@example.com`.                                             | Empty   |

As the card states, the digest **includes**: completed by outcome, appointments booked vs capacity, retries scheduled for tomorrow, suppressions, queue health, and tomorrow's planned capacity per list.

Enable it on long-running batches — it is the quickest way to spot a batch that is burning its daily cap on retries or holding a growing pile of suppressed contacts without opening the app.

***

## Next Steps

* [Batch Screening Gates](/batches/screening-gates) — the deep dive on DNCR, opt-out and previously-called screening, including what happens when a check can't complete.
* [Batch Scheduling & Pacing](/batches/scheduling) — business hours, daily caps and ramp profiles: the calendar your retries are planned into.
* [Batch Queue Management](/batches/queue) — queue statuses, attempt counters, and per-contact actions like pausing or cancelling entries.
* [Call Statuses](/calls/statuses) — the full list of call statuses and end reasons behind the outcome classification.