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 or hits a busy line), 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: 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.”
Each gate is a simple switch on the card, and the switches are the only thing that decides whether a gate applies. Every queued call starts out unscreened and cannot dial until it has been checked; change a gate and everything still waiting is checked again against the new setting.
Retry attempts are re-screened before they dial too, 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 deep dive.
If you need a screening rule beyond the three built-in ones, speak to the Voxworks team for further custom configuration.
Retry policy
The Retry policy card controls automatic follow-up calls for attempts that didn’t reach the contact — “Click to add or remove retry events. Each point is the delay after the previous call attempt.” It is a timeline. Each row is one outcome, with a row of milestones running left to right and an Active switch on the right:
Click a milestone to add a retry at that delay; click it again to remove it. Selected milestones fill in and are numbered 1, 2, 3 in the order they will run — so the row tells you at a glance how many follow-up calls a contact will get and how far apart. Each delay is measured from the end of the previous attempt, not from the start of the batch.
Default policy
All three start switched on. Turning a row off stops retries for that outcome; turning it back on gives you a single retry at a sensible starting point (1 day for voicemail, 4 hours for no answer, 1 hour for a busy line), which you can then adjust.
If a batch was set up with a delay that isn’t one of the eight milestones, the row warns: “Custom saved times are not shown. Selecting a milestone replaces them with this timeline.” The batch keeps running on its saved times until you click a milestone, at which point the timeline takes over.
Contact is busy, callback requested
Below the three outcome rows is a separate switch: Contact is busy, callback requested — “Reschedules another call at the contact’s requested time”. It is on by default. This is not a backoff. When the contact asks to be called at a particular time, that time is what is booked — see Scheduling calls for the rules a requested time has to satisfy.How a retry actually runs
A retry is not an instant redial. When an attempt ends in a retryable outcome:- A new entry is added to the batch 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.
- The entry becomes eligible to dial only after the delay has elapsed, measured from when the previous call ended.
- 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.
What is never retried
- Completed calls and calls the contact ended (Hang Up) — the conversation happened; there is nothing to retry.
- Cancelled calls.
- Failures. A call that failed — for a temporary fault or a permanent one such as an invalid number — is not retried by the batch. Temporary dispatch faults are already retried by the platform before the call is marked failed; see Dispatch, Concurrency & Delays.
How outcomes are classified
Each finished call is classified into one of the three retry outcomes based on its call status and end reason (see Call Statuses for the full list):
Calls that don’t match any of these complete their queue entry with no retry created.
Cancel on inbound
Below the retry timeline sits a single toggle:Cancel pending retries when contact calls back inbound — Stops a retry from dialling out to someone who already returned the call.It is on by default. When a contact with pending retries calls one of your numbers, their retries 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:
- Retries that have not yet dialled are cancelled outright.
- Retries that have already been handed to the dispatcher but have not connected are stopped too, and read Cancelled - inbound call received in the Call Log.
- No new retry is created for a contact who has already rung in since the outbound attempt began.
- 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, so you can see exactly which follow-ups were dropped and why, and they are still counted in the batch’s reporting.
- 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.
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 — the deep dive on DNCR, opt-out and previously-called screening, including what happens when a check can’t complete.
- Batch Scheduling & Pacing — business hours, daily caps and ramp profiles: the calendar your retries are planned into.
- Batch Queue Management — queue statuses, attempt counters, and per-contact actions like pausing or cancelling entries.
- Call Statuses — the full list of call statuses and end reasons behind the outcome classification.