Skip to main content

​
Overview

Every outbound call your agents place is dialled from one of your team’s Voxworks phone numbers — that number is the caller ID the person you’re calling sees on their screen. The from-number is chosen differently depending on where the call is created (the New Call modal, a batch, an automation, or the API), and every path shares the same safety net: if no number is specified, the call falls back to your team’s default outbound number. This page covers how the from-number resolves on each surface, what the default is, what happens when nothing can be resolved, and which number is presented when a call is transferred to a human. For claiming and managing the numbers themselves, see Phone Numbers.

​
How the from-number is chosen

The sections below walk through each surface.

​
The New Call modal

When you schedule a single call with New Call, the modal includes an Outbound Number (Optional) field with a Select Outbound Number dropdown. The first option is Use Default, followed by each of your team’s phone numbers.
  • Pick a specific number to present that caller ID for this call. The number must belong to your team — if it has been released or deleted in the meantime, scheduling fails with “Selected phone number is not available for this account”.
  • Leave it on Use Default and Voxworks picks your team’s first active number at the moment the call is scheduled. Permanently assigned numbers rank ahead of temporary trial numbers.
  • If your team has no numbers yet, the field shows “No phone numbers configured - will use default” — and because there is genuinely nothing to dial from, scheduling then fails with “No phone number configured for this account. Reserve a number before placing a test call.” Claim a number first (see Phone Numbers).
Test calls placed from the Test Call button follow the same default-number resolution — see Test Calls.

​
Batches

A batch can dial from different numbers for different lists — useful when one batch spans regions or brands. The from-number for each queued contact resolves in this order at the moment the queue item launches into a call:
  1. List override — the Number column set against the contact’s primary source list (the dropdown offers Account default plus each of your numbers). See Source Lists.
  2. Batch-wide default — a fallback number set on the batch itself, underneath the list-level override. There’s no in-app control for this yet — speak to the Voxworks team for custom configuration.
  3. Account default — your team’s default outbound number.
Because resolution happens at launch, changing a list’s Number column affects calls that haven’t launched yet; calls already placed keep the number they dialled with.

​
Automations

Calls created by an automation’s Create Call pipeline step show a From Number (optional) field (placeholder: Trunk phone number (uses default if empty)). Leave it empty and the call is dialled from your team’s default outbound number, resolved at the moment the call dials. See Automation Steps for the rest of the step’s configuration.

​
The API

Calls created through the Create Phone Call endpoint must state their from-number explicitly — there is no default fallback:
  • from_number is required and must be a phone number that belongs to your team. It accepts any common format (0429069971 or +61429069971) and is normalised to E.164. Omitting it returns “from_number is required”; a number you don’t own is rejected with “from_number not found or does not belong to your team”.
  • The destination comes from the contact object you pass — its phone_number also accepts any common format. At runtime the agent sees it as {{contact.phone}} (string, e.g. +61412345678).
See the API Reference for the full request shape.

​
Default-number fallback and failure mode

From-number resolution has two moments:
  1. When the call is created. The New Call modal and batch launches resolve Use Default / Account default into a concrete number up front, so the call record already carries its from-number.
  2. When the call dials. As a safety net, any scheduled call that reaches dial time without a from-number (an automation-created call, for example) is dialled from your team’s default outbound number.
If the fallback itself cannot resolve — the account has no usable default number — the call is not dialled. It moves to Failed, clearly distinguished from calls that dialled and didn’t connect. See Call Statuses for how failed calls appear in the Call Log. Your default outbound number is set on your account; there is no in-app control for changing which of your numbers acts as the default. Speak to the Voxworks team for further custom configuration.

​
Caller-ID transparency

Voxworks presents honest, answerable caller IDs:
  • You can only present numbers your team owns. Every surface validates the from-number against your team’s numbers — there is no way to present an arbitrary number, a competitor’s number, or a number you haven’t claimed. Caller-ID spoofing is not supported.
  • Calls are never sent as “Private” or “No Caller ID”. The person you call always sees a real Australian number they can inspect and return.
  • The number is answerable. If someone calls back the number your agent dialled from, the call is answered by whatever inbound script you’ve assigned to that number — so pair each outbound number with a sensible inbound script or AI Receptionist. See Assigning an inbound script.
  • Local presence is a number choice, not a trick. Presenting as a local landline (02/03/07/08) or a mobile (04) is decided by which number type you claim — see Number types.
The Test / Live label on a number is an organisational flag only; it does not change the caller ID presented.

​
The number presented during live transfers

When your agent hands a call to a human — via Live Handoff, an Intent Pathway, or the Warm Handoff tool — the platform dials your team member and presents the caller ID of the call in progress:
  • On an inbound call, your team member’s phone shows the original caller’s number — not your Voxworks number. Staff see who they’re about to speak with, can screen it like any direct call, and can ring the customer back on the number that appears in their call history.
  • On an outbound call, the transfer presents the Voxworks number the call was placed from, so it’s recognisable as one of your business lines.
  • On a browser test call, if the call carries one of your numbers as its identity, that number is presented the same way during the transfer.
Either way, the number on your team member’s screen belongs to the conversation, not to some anonymous switch — and the agent still briefs them privately before merging the caller in. For the full transfer experience, see Transferring Calls.

​
Next Steps

  • Phone Numbers — claim numbers, name them, and assign the inbound script that answers each one.
  • Source Lists — set per-list outbound numbers inside a batch.
  • Automation Steps — configure the Create Call step, including its From Number field.
  • Transferring Calls — what callers and your team experience during a live transfer.