Skip to main content

​
What are Source Lists?

A batch dials contacts, and source lists are where those contacts come from. Instead of loading a fixed set of numbers into a batch, you attach one or more of your contact lists to it. The scheduler then draws contacts from those lists according to the rules you set — which list gets called first, how many calls each list may use per day and in total, which Call Script and outbound number each list’s contacts get — and keeps drawing as the lists grow. Source lists are managed in the List allocation section at the top of a batch’s Settings tab. The same allocation also appears read-only on the Summary tab (as a Source lists card before the batch has run) and in the batch analytics once calls complete, so you can compare results list by list. Two ideas underpin everything on this page:
  • Lists are live feeds, not snapshots. While a batch’s scheduler is active, new contacts added to an attached list flow into the batch automatically.
  • Each contact is queued once per batch. However many of the batch’s lists a contact belongs to, they get exactly one place in the queue.

​
Adding source lists to a batch

Open the batch’s Settings tab. The List allocation table has a row at the bottom with two ways to add a source:
  • Add lists — opens a searchable picker of your existing lists (with a Search lists… field). Each option shows the list name and its contact count; lists already attached are marked Added and can’t be selected twice.
  • Drag & drop a CSV — the adjacent drop zone (“Drag & drop a CSV or browse to add a new list”) creates a brand-new list from a file and attaches it in one step. The Create list from CSV dialog lets you name the list, review and deselect parsed contacts, and optionally map extra CSV columns to typed custom variables before importing. Rows with invalid phone numbers are listed separately and skipped, and duplicate phone numbers within the file are imported once. Australian numbers are normalised to international format (for example 0412 345 678 becomes +61412345678).
When you add a list it joins the allocation with the next priority number, no quotas, an Active status, and the Batch default script. Its current members are queued immediately. Removing a list asks for confirmation (Remove source list?) because it is not just a settings change: queue rows that came from that list are cancelled immediately. Calls that have already launched are unaffected. Changes in the List allocation table save as you make them and the batch schedule replans automatically — you don’t need to press Replan after editing the allocation.

​
The List allocation table

The panel header explains the model: “How daily slots split across source lists. Lower priority numbers get scheduled first; daily and total caps limit how many contacts can be planned from each list.” Above the table, the Allocation mix bar shows each list’s share of the batch’s contacts. The Total row sums contacts and quotas and holds the batch’s default script selector (No default script until you choose one). A contact whose list has no script override and whose batch has no default script is never dialled — the row simply waits — so always set at least a batch default script.

​
Priorities: which list gets called first

Priority is an ordering, not a share. When the scheduler fills each day’s call slots it works through eligible contacts in strict order:
  1. List priority — all of priority 1’s eligible contacts are planned before priority 2 is touched.
  2. Order within the list — contacts are taken in the order they joined the queue.
Two or more lists can share the same priority number. Contacts from equal-priority lists are interleaved round-robin — one from each list in turn — so neither list monopolises the day. This is the natural setup for an A/B-style comparison across two lists: give both priority 1 and they get called evenly side by side. If a higher-priority contact isn’t eligible for a particular slot (for example a retry that isn’t due yet), the scheduler skips ahead to the next eligible contact rather than wasting the slot.

​
Daily and total quotas

Quotas cap how much of the batch’s capacity a list may consume:
  • Daily Quota limits planned calls from the list per calendar day (in the batch’s timezone).
  • Total Quota limits planned calls from the list across the batch’s lifetime.
Everything already committed counts toward the quota — calls planned for the day, launched, completed and retries — so a quota is a true ceiling, not a per-replan allowance. When a list hits its daily quota, the scheduler moves on to lower-priority lists for the rest of that day and returns to it the next day. When a list hits its total quota, no further contacts are planned from it. A common pattern: give a premium list priority 1 with a daily quota of 50, and an overflow list priority 2 with no quota. The first 50 calls each day go to the premium list; the remaining capacity flows to the overflow list. Contacts on more than one list. Because each contact is queued once, a contact who belongs to several of the batch’s lists is attributed to all of them by default — their call counts against the daily and total quota of every attached list they belong to. One of those lists is recorded as the contact’s primary list (the highest-priority one, i.e. the lowest priority number), and it is the primary list’s script and number the contact receives. An alternative attribution mode that counts each call against the primary list only, and finer per-list sampling controls, exist on the platform but are not configurable in the app. Speak to the Voxworks team for further custom configuration.

​
Script overrides and precedence

Each list can send its contacts to a different Call Script, which is how one batch runs different conversations for different segments. The script used for a queued contact resolves in this order:
  1. Contact-level assignment — a script set for that specific contact when it was added (see Adding Contacts to a Batch).
  2. List override — the Script column for the contact’s primary list.
  3. Batch default — the default script in the Total row.
Changing a list’s script updates the plan for calls that haven’t launched yet; calls already placed keep the script they dialled with.

​
Outbound number overrides

The Number column works the same way for caller ID. Each list can place its calls from a different outbound number — useful when one batch spans regions or brands. At the moment a call dials, the from-number resolves in this order:
  1. List override — the Number column for the contact’s primary list.
  2. Batch setting — the Trunk field under the batch’s Calling rules.
  3. Account default — your team’s default outbound number.
The full from-number story, including what happens when no number can be resolved, lives on Outbound Caller ID & Default Number.

​
A/B testing script variants

A/B testing is a gated feature: it isn’t self-serve in the app today. A source list can carry an A/B test — two or more script variants, each with a label and a weight, splitting that list’s contacts between competing scripts — but it’s set up by the Voxworks team on your behalf. If you want to run an A/B script test, reach out to the Voxworks team directly to have it configured for your account. Once a list has an A/B test configured, an A/B badge appears beside its script in the List allocation table, on the Summary tab’s Source lists card, and in the batch analytics. Once a contact is assigned a variant, that assignment sticks: every attempt for that contact — including automatic retries after voicemail, no-answer or busy outcomes — carries the same variant and script forward rather than re-rolling it, and the variant is recorded against each queue row. That keeps the two arms of the test clean: a contact never drifts between variants mid-test, so completion rates and objective results in the batch analytics remain directly comparable between scripts. There is no in-app editor for creating A/B variants on a source list — this is by design, since setup goes through the Voxworks team. Speak to your Voxworks contact to request the feature or configure a new test.

​
Script versions on batch calls

Batch calls always launch with the current version of the assigned script at the moment each call dials, and the exact version used is recorded against the queue row and the call. In practice this means:
  • If you publish an improved script version mid-batch, calls that haven’t dialled yet pick up the new version automatically; calls already made keep the version they ran with.
  • A retry uses the same script as its original attempt, at whatever version is current when the retry dials.
Because the version is recorded per call, you can always tell which script version a given result came from. If your campaign needs calls pinned to the script version that was live when contacts were queued — rather than tracking the latest — the platform supports it, but it is not configurable in the app. Speak to the Voxworks team for further custom configuration. See Script Versions & Publishing for how script versions work generally.

​
Live intake: lists keep feeding the batch

While a batch’s scheduler is active, its source lists behave as feeders:
  • New list members join the queue automatically. When contacts are added to an attached, active list — from the Contacts page, a CSV import, an automation or the API — they are folded into the batch’s queue. Intake happens immediately when contacts are added through the platform’s list endpoints, and the scheduler also re-checks list membership on its regular planning pass, so new members are picked up within a few minutes either way.
  • New contacts join the back of the queue with the list’s script, and are planned into future schedule slots by the normal priority and quota rules.
  • New rows are screened before dialling. If screening gates are enabled on the batch, folded-in contacts start in a pending screening state and are held until screening clears them — they never launch unscreened. See Batch Screening Gates.
  • Pausing a list stops it feeding and dialling. Set a list’s status to Paused and the scheduler stops planning new calls from it, and holds its already-planned calls at launch. Set it back to Active and it resumes where it left off — nothing is cancelled by pausing.
  • Removing a list cancels its pending queue rows immediately, as the confirmation dialog warns.
This makes “trickle” campaigns simple: launch a batch against a list that your website, CRM integration or an automation keeps topping up, and the batch calls each new contact at the next appropriate slot indefinitely (subject to the batch’s schedule window).

​
Deduplication

Batches guarantee one queue row per contact:
  • Within a batch, a contact is queued exactly once no matter how many attached lists they appear on, and the platform enforces this at the database level — concurrent intake from several sources can never double-queue a contact. The contact keeps a record of all the batch lists they belong to (used for quota attribution), with the highest-priority list as their primary.
  • Adding contacts to a launched batch filters out anyone already in the batch; if every selected contact is already present, the addition is rejected outright.
  • Within a CSV import, duplicate phone numbers are imported once.
Deduplication applies per batch, not across batches — the same contact can appear in two different batches. Use the minimum-gap and screening settings to control how often the same person can be called across your calling activity; see Batch Screening Gates.

​
Next Steps

  • Batch Scheduling & Pacing — business hours, daily caps, ramp profiles and how the day’s call slots are generated.
  • Batch Queue Management — inspect every queued contact, filter by list, and lock or reschedule individual rows.
  • Batch Calling Rules & Retries — per-outcome retry policies and how retries interact with quotas and variants.
  • Lists — creating and maintaining the contact lists that feed your batches.