What is the batch queue?
Every batch has a Queue tab, labelled Queue ({count}) on the batch detail page, listing one row per contact per call attempt. The count is every row in the queue, retries and cancelled items included. The tab describes itself: “Contacts waiting to be called. The dispatcher starts the next eligible contact whenever a line is free.”
Batch calls are not created ahead of time. A contact waits in the queue as Pending until the moment it is called. At that moment the call record is created and the item becomes Launched. So everything you do in the queue (pausing, cancelling, screening) takes effect before any money is spent on a call, right up until a contact is started. Batch Scheduling & Pacing lists the rules that decide which contact goes next.
The queue updates in real time: as contacts are called and results come back, rows change without a manual refresh. When a retry is due (for example after a voicemail or no-answer), it appears as a new queue item for the same contact with a higher attempt number. The retry policies themselves are on Batch Calling Rules & Retries.
Queue statuses
Each item carries a status pill. The tabs across the top of the queue are fixed views of the whole queue, each with a live count worked out across every row in the batch (not just the rows loaded on screen). Every row sits in exactly one view, so the counts add up to All. Tabs with nothing in them are hidden, except All and Pending.
Held items are Pending contacts whose list you have paused in the batch’s source lists. The dispatcher skips a paused list entirely, so these contacts will not be called until you resume the list; resuming it moves them back to Pending or Pending - Redial. They carry an amber List paused tag in the Status column and on Kanban cards. Contacts you pause yourself (the padlock) or that aren’t due yet are not counted here; they stay under Pending or Pending - Redial.
Pending - Redial separates repeat attempts from first calls. A retry after a busy line, no answer or voicemail, or a callback the contact asked for, is a new queue item with a higher attempt number; while it waits it sits here rather than under Pending, so you can see at a glance how much of the waiting work is first contact and how much is follow-up.
Attempts
The Att column shows the attempt number for each item. First attempts show1, and retries are highlighted as ×2, ×3 and so on.
The Scheduled column
Because nothing is pre-booked, the Scheduled column tells you what is known about each row’s timing:
Estimates come from the forecast in the batch’s Schedule section. They show the day a contact is expected to be called, not an appointment. See The forecast.
By default the queue is sorted into one sequence: called items first, then contacts due now, then items by their due or estimated day, with unscheduled items last.
Two ways to view the queue
A segmented control at the top right switches between two views. Your current tab, search and filters apply to the Table; the Kanban always shows its fixed columns.- Table: the full working view. Columns are Scheduled, Contact, Phone, List, Script (shows “Batch default” when no per-contact override applies), Dial order, Status, Screen (screening verdict) and Att (attempt number). A checkbox column on the left drives the bulk actions, and a padlock icon appears beside held and pinned items. Use the columns control in the header to hide columns you don’t need.
- Kanban: seven columns (Pending, Pending - Redial, Held, Launched, Completed, Suppressed, Cancelled) with a card per contact, so you can watch work flow left to right while a batch runs. Each column shows its first 50 cards in dispatch order, and its header always shows the true total.
Searching, filtering and sorting
The queue uses the same filter header as the other table pages:- Search matches contact name or phone number.
- Filters can be combined across these columns: Contact, Phone, List, Script, DNCR (Clear / Pending / Blocked / Override / Unknown / Error), Scheduled (date range), Lock (Locked / Unlocked) and Attempts (number).
- Sorts are available on the same columns, plus Dial order. On the Pending, Pending - Redial and Held tabs the table starts in dial order; sorting Dial order descending reverses the loaded rows.
Bulk actions
Tick individual rows, or the header checkbox to select every loaded row that matches your search and filters, then use the four buttons above the table (each shows how many rows are selected). Rows not yet loaded are never selected. Each button reports how many items it changed and how many it skipped (items in a state the action doesn’t apply to).
There is a point of no return. Once a contact has been started, its call is committed. Pause and Cancel leave launched items alone rather than drop a call mid-dial, and count them as skipped. To stop a contact being called, act while it is still Pending.
To stop the whole batch, use Pause Scheduler in the batch header. It stops the batch starting new calls; queue items keep their state, and nothing is individually locked. Resume Scheduler lets eligible contacts be called again. See Batches: Overview & Lifecycle.
Held and pinned items
The amber padlock in the Scheduled column (and on Kanban cards) marks a locked item. There are two kinds:- Held: an item you paused with the bulk Pause action. It shows Unscheduled · held and is never called until you resume it. Held items keep the batch open, so a batch with held contacts won’t complete on its own. These stay under the Pending or Pending - Redial tab; the Held tab is for contacts whose whole list is paused (see Queue statuses).
- Pinned: an item fixed to an exact date and time. It shows the time tagged pinned, goes ahead of ordinary work when that time arrives, and can be called at any time on its pinned day, regardless of business hours, the daily cap or the minimum gap.
Dial order
On the Pending, Pending - Redial and Held tabs, rows are listed in the order the dispatcher will call them, and the Dial order column numbers them 1, 2, 3 and so on. The order follows the batch’s source lists: every list at priority 1 comes before any list at priority 2 (the Priority you set on each source list in the batch’s Settings tab), lists that share a priority number take turns one contact each, and within a list the contacts who joined it most recently go first (or the longest-standing first, if the batch prioritises oldest first). Because lists at the same priority take turns live, the list that actually goes next may differ from row 1 here; the overall pattern is the same. Pinned contacts and requested callbacks always go ahead of this order. See Source Lists, Allocation & A/B Testing. A row the dispatcher would skip right now shows a grey reason chip instead of a number, keeps its place in the order, and isn’t counted in the numbering: Not due (waiting for its next eligible time), Manual hold (paused by hand until its pinned time), Screening (not cleared yet), Daily quota (its list’s daily or total quota is used up), Held (list paused) or Removed list (its list is no longer a source of the batch). Batch-wide limits such as calling hours, concurrency and the batch’s daily cap apply to every row, so they don’t appear here. Other tabs show — in this column. If the batch uses survey quota sampling, a note above the table reminds you that cells that still need completes are dialled first; the dial order shown doesn’t account for cells.Screening and suppression
The Screen column shows each contact’s consolidated screening verdict:
Verdicts age out: after the recheck period (30 days by default) a contact is screened again before any further attempt. A verdict also stops counting if the contact’s phone number changes, or if you change the batch’s screening gates. The separate DNCR filter reflects the contact’s latest Do Not Call Register wash result. See DNCR Washing.
To see why an item is held rather than called (a pause, a cancellation, an inbound return, the batch’s end date, or a screening block), read its Scheduled, Status and Screen columns. See Batch Screening Gates.
CSV export
The Export loaded rows button above the table exports the loaded rows that match your current tab, filters and search to a file namedbatch-queue.csv. Rows not yet loaded are not included, so load the rows you need first, then filter and export. The file has these columns:
Audit trail
Every change to a batch’s settings and queue is recorded as an audit event: settings changes, scheduler pauses and resumes, bulk pauses, resumes and cancellations (with counts and the affected items), screening runs and their results, and script changes. Each event records who performed it and when. The platform adds its own events automatically as items are called, finish, retry or are superseded by inbound calls. To review a batch’s audit trail, speak to the Voxworks team.Next Steps
- Batch Scheduling & Pacing: the rules that decide which contact is called next, and the forecast behind the estimated days.
- Batch Calling Rules & Retries: the per-outcome retry policies that create repeat queue items, and Cancel on inbound.
- Batch Screening Gates: the DNCR, opt-out and previously-called gates behind the Screen column.
- Call Statuses & End Reasons: what happens to an item’s call after it launches.