ElevenLabs Agents Outbound Calling: Twilio and Batch Calls

Check the Twilio number type

The native Twilio integration guide distinguishes purchased Twilio numbers, which support inbound and outbound use, from verified caller IDs, which support outbound only. Verify the selected number’s capabilities rather than assuming an outbound identity can also receive callbacks through the agent.

Make the callback experience part of the design. If a customer misses a reminder and returns the call, decide which system answers and which record it can use. The outbound presentation and inbound route need to form a coherent business experience.

Prepare the recipient file carefully

The batch calling guide describes CSV or XLS lists, a mandatory phone_number column and additional columns passed as dynamic variables. It supports immediate or scheduled execution and individual call review. Certain override columns require the corresponding agent security settings.

Use two contrasting internal recipients

Create a harmless example in which one test customer has a morning appointment and another an afternoon appointment. Inspect what each call says and the source variables it used. This catches an incorrectly mapped column more clearly than repeating the same sample data.

Include a missing optional value. Decide what the agent should say when that detail is unavailable rather than letting it improvise a commitment. Do not put sensitive production data into a trial file when synthetic records can verify the mapping.

Inspect capacity and retention requirements

The batch guide describes reserving part of available concurrency and says Zero Retention Mode cannot be enabled for batch calls. If that mode is required for your use case, check the documented individual-call route instead. Confirm the current product behaviour before selecting a campaign architecture.

Reconcile the customer outcomes

Review confirmation, no answer, a requested change and a request to stop as distinct outcomes. Confirm the person or system responsible for each follow-up. A processed batch and a completed customer task are different measures. Expand only after the team can trace the selected number, input variables, conversation and resulting action for every controlled test.

Designing the Agent Conversation Before Touching the Recipient List

A well-structured outbound call depends on decisions made before any file is uploaded or any schedule is set. The agent's conversation design determines whether a recipient understands the purpose of the call, can respond meaningfully, and leaves with a clear next step. Treating the conversation script as a secondary concern—something to finalise after technical configuration—tends to produce calls that are technically delivered but operationally incomplete.

Start by writing out every branch the conversation could take, in plain language, before considering how variables will be inserted. A reminder call might seem straightforward, but it contains at least four distinct paths: the recipient confirms and needs nothing further; the recipient confirms but wants to change a detail; the recipient wants to cancel; and the recipient asks a question the agent is not equipped to answer. Each path needs a defined endpoint. Leaving any path without a defined endpoint means the agent will either fall silent or improvise, and improvised commitments in a customer-facing voice call create reconciliation problems that cannot be easily corrected after the fact.

When writing each branch, separate what the agent can resolve autonomously from what requires a human to act. An agent can read back a booking reference. An agent should not confirm a medical appointment change as though that change has been applied in a clinical system. Draw that line in the script, and then verify it is also drawn in the agent's instructions. The script and the agent configuration need to agree on what constitutes a completed interaction versus a flagged one requiring staff follow-up.

Mapping Dynamic Variables to Actual Business Records

The columns in a batch recipient file are not merely technical fields; each one represents a specific piece of business information that must be traceable to an authoritative source. Before building the file, identify which system holds the data for each column, who is responsible for its accuracy, and how recently it was verified.

Consider an illustrative scenario where a business runs an outbound appointment reminder campaign. The recipient file might include a customer name, an appointment time, a location name, and a reference number. Each of those fields comes from a different place. The customer name might come from a CRM. The appointment time might come from a scheduling system. The location name might be a static value added manually by a coordinator. The reference number might be generated by a billing platform. If any of those sources is out of sync at the moment the file is compiled, the agent will deliver accurate-sounding but incorrect information to a real person.

A practical discipline is to require that every column in the recipient file has a documented source, a named owner, and a defined freshness threshold. Freshness matters because a file prepared on a Monday for a Wednesday batch run may reflect data that was accurate at preparation time but has since changed. Establish a cut-off: after a certain point before the scheduled call, the file is locked and any changes in the source systems are handled through the follow-up process, not by modifying the batch.

For columns that are sometimes empty—optional details that only apply to certain recipients—write explicit handling into the agent's instructions. The agent needs a prepared phrase for when that variable is absent, and that phrase should be neutral rather than compensatory. Saying nothing about a detail is usually better than saying something vague that a recipient might interpret as a commitment.

A Worked Illustrative Scenario: From File Preparation to Outcome Logging

The following is a fictional example constructed to illustrate evaluation questions, not a description of any real deployment.

A property management company wants to remind tenants of scheduled maintenance visits. The operations coordinator compiles a recipient file with columns for tenant name, unit reference, visit date, visit window, and a contact number for queries. Before uploading, the coordinator checks three things: that every phone number is in the correct format for the configured Twilio number, that no unit reference is duplicated, and that the visit window column contains no blank cells—because the agent's script references that window explicitly and the coordinator has confirmed the agent has no fallback instruction for a blank visit window value.

A test batch of two internal recipients is run first. One test record has a morning window; the other has an afternoon window. The coordinator listens to both calls and checks that the correct window was read for each. The coordinator also checks the reference number in each call log against the test records to confirm the reconciliation column is working. Only after both calls are confirmed correct does the coordinator upload the full recipient list.

After the batch runs, the coordinator reviews the call outcomes against four categories: confirmed with no further action needed; confirmed but tenant raised a query logged for follow-up; no answer, queued for a manual callback; and tenant requested the visit be rescheduled, flagged for the maintenance scheduler. The coordinator does not mark the batch as complete until every record has been assigned to one of those four categories and a named staff member or process owns the follow-up. The difference between a delivered call and a resolved tenant interaction is precisely that assignment step.

Evaluating Whether Batch Calling Fits a Given Use Case

Batch outbound calling is not equally suited to every outreach scenario. Before selecting it as the method, a business can apply a structured set of evaluation questions that help distinguish appropriate from unsuitable applications.

The first question concerns recipient homogeneity. If every recipient on the list needs essentially the same information with only personalised variables substituted, batch calling is likely a reasonable fit. If recipients need meaningfully different conversations depending on their situation—such as different eligibility conditions or different required disclosures—a single agent configuration may not serve all of them well, and separate campaigns or a different approach may be warranted.

The second question concerns the consequence of a missed call. If a missed call can be handled by a follow-up process that does not disadvantage the recipient, batch calling with a clear no-answer handling protocol is workable. If a missed call creates a time-sensitive problem for the recipient—for instance, if they need information before a deadline that cannot easily be extended—the process design needs to account for that urgency, and automated batch scheduling alone may not be sufficient.

The third question concerns the sensitivity of the information. Some outbound call content is routine and low-risk. Other content touches on financial, health-related, or legally significant matters. Where content is sensitive, the conversation design, the handling of call recordings, and the escalation path for recipient questions all require more careful definition than a straightforward reminder call would need.

The fourth question concerns recipient consent and expectation. Recipients who are expecting a call and know its purpose are more likely to engage productively. Recipients who are not expecting a call, or who may not recognise the calling number, are more likely to end the call before it completes. The business should consider how the recipient list was established and whether recipients have been notified that they will receive an automated call, and from what number.

Handling Exceptions During and After a Batch Run

Exception handling is where the practical quality of an outbound campaign becomes visible. A batch may run cleanly in terms of technical delivery while still producing a number of interactions that require human attention. Planning for those exceptions before the batch runs is more effective than responding to them after.

Define in advance what constitutes an exception. A no-answer is a predictable outcome that needs a defined protocol. A recipient who says they do not recognise the booking reference is a data quality exception that needs a defined escalation path. A recipient who becomes distressed during the call needs a defined handover procedure to a human staff member. A recipient who explicitly asks not to be called again needs a defined suppression process.

For each exception type, identify the staff role responsible, the system where the exception is logged, and the expected response time. These are not abstract process design questions—they are the practical commitments that determine whether an outbound campaign improves or damages the customer relationship.

In cases where the call involves any information that a recipient might dispute—a balance, a date, a reference number—consider how the business will handle a recipient who calls back to challenge what the agent said. The call record and the source data need to be preserved and accessible to the staff member who takes that callback, so they can understand exactly what was communicated and cross-check it against the authoritative record.

Coordinating the Outbound Number Presentation with Inbound Experience

The number displayed to a recipient during an outbound batch call shapes their decision about whether to answer and, if they miss the call, whether to return it. If the displayed number is unrecognised or associated in the recipient's mind with unsolicited contact, engagement rates may be lower than expected. Choosing a number that recipients can associate with the business—through prior correspondence, documentation, or a pre-call notification—is a practical consideration that sits outside the technical configuration but affects campaign outcomes.

When a recipient returns a missed call, what they reach needs to be coherent with what the outbound call was about. If the outbound campaign is for appointment reminders and a returning caller reaches a general voicemail with no relevant context, that is a failure of the customer journey even if the technical batch delivery was successful. The inbound experience for the outbound number should be designed as part of the campaign, not left as a default.

Where the number used for outbound batch calls cannot also receive inbound calls—because it is a verified caller ID rather than a purchased number—the outbound call itself needs to give the recipient an alternative route for callbacks. That alternative should be a number that is staffed appropriately for the volume and nature of enquiries the batch is likely to generate.

Acceptance Criteria Before a Live Campaign

A practical acceptance exercise for an outbound batch configuration can be structured around observable evidence rather than vendor assurances. For each of the following criteria, determine what observable evidence would allow a responsible staff member to confirm the criterion is met before the campaign goes live.

• The correct dynamic variable is spoken for each test recipient, verified by listening to the call and comparing it to the input record.
• The agent's response to a request to cancel or opt out produces a defined outcome that can be traced in the call log.
• A missing optional variable in the input file produces the prepared neutral phrase, not a gap or an improvised commitment.
• The outbound number displays correctly on a receiving handset, confirmed by calling a known internal number and checking what appears on screen.
• The inbound experience for the outbound number is coherent with the campaign purpose, confirmed by calling the number and experiencing what a returning recipient would encounter.
• The reconciliation column in the call log matches the reference in the input file, confirmed by comparing a sample of records after the test batch.
• The staff member responsible for each exception category can be named, and each knows their role before the live batch runs.

These criteria can be documented as a pre-launch checklist and reviewed by a second person before any campaign reaches real recipients. The checklist serves two purposes: it reduces the likelihood of errors in live campaigns, and it creates a reviewable record of the decisions made before the campaign ran, which is useful if any recipient later raises a question about what they were told.

Running a small controlled test batch with internal or consenting test recipients, treating the results as evidence rather than assumption, and requiring named human ownership of every exception category before scaling are the practical steps that distinguish a campaign that is technically configured from one that is operationally ready.

Related guides

• Synthflow vs Retell: Visual Flows, Tools and Launch Work
• Cartesia for Outbound Calling: Voice Models and Call Workflows

Comparing business systems? Explore Sysevo outbound campaigns or book a Sysevo demo against the same requirements. This is an independent Sysevo editorial guide based on the linked vendor documentation, reviewed 2 November 2026. Examples are illustrative; no hands-on vendor test or guaranteed result is claimed. Sysevo publishes this guide and sells its own software.

For current Sysevo subscriptions and usage options, compare plans and pricing.