> ## 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. # Source Lists, Allocation & A/B Testing > Feed a batch from one or more contact lists, control how daily calling capacity splits across them with priorities and quotas, override the Call Script and outbound number per list, and run A/B script tests. ## 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. | Column | Description | Default | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | | **#** | The list's priority rank badge. | Order added | | **List** | The list's name. | — | | **Script** | The Call Script used for this list's contacts. **Batch default** uses the script chosen in the **Total** row at the foot of the table. An **A/B** badge appears here when the list carries an A/B test. | Batch default | | **Number** | The outbound number used for this list's contacts. **Account default** falls back to the batch-level and then account-level number. | Account default | | **Contacts** | How many contacts the list currently holds. | — | | **Priority** | Scheduling order across lists — lower numbers are called first. Minimum 1. | Next available | | **Daily Quota** | Maximum calls planned from this list per day. Leave empty for no limit. | No limit | | **Total Quota** | Maximum calls planned from this list across the whole batch. Leave empty for no limit. | No limit | | **Status** | **Active** or **Paused**. Toggle with the pause/play button on the row. | Active | 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](/batches/adding-contacts)). 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](/numbers/caller-id). *** ## 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](/scripts/versions-and-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](/batches/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](/batches/screening-gates). *** ## Next Steps * [Batch Scheduling & Pacing](/batches/scheduling) — business hours, daily caps, ramp profiles and how the day's call slots are generated. * [Batch Queue Management](/batches/queue) — inspect every queued contact, filter by list, and lock or reschedule individual rows. * [Batch Calling Rules & Retries](/batches/calling-rules) — per-outcome retry policies and how retries interact with quotas and variants. * [Lists](/lists/overview) — creating and maintaining the contact lists that feed your batches.