Call Statuses, End Reasons & Outcomes Reference

Overview

Every call in Voxworks carries several layered fields that together tell you where it is, why it ended, and what actually happened on it:

Status — where the call is in its life: waiting to dial, dialling, live, or finished (and if finished, how). This is the coloured value you see in the Call Log and filter on.
End Reason — the finer detail behind a finished call: who hung up, whether voicemail was reached, whether the call was handed to a human.
Progress — how far the call has moved through post-call processing (transcript, summary, analysis, automations). Mostly visible through the API.
Dispatch status — a short plain-text note on scheduled outbound calls recording where they are in the dispatch queue.
Outcome — the Post-Call Analysis classification of what happened in the conversation itself: appointment booked, not interested, message taken, and so on.

This page is the canonical reference for all of them, plus the rules for what you can cancel, reschedule, or retry in each status. Sibling pages cover the narratives: Dispatch, Concurrency & Delays for the queue-to-dial journey, Scheduling & Managing Calls for creating and managing calls, and Post-Call Analysis for configuring outcome classification.

The status pipeline

A scheduled outbound call moves through the pipeline in one direction: Scheduled → Queued → In Progress → a terminal status

Scheduled — the call is waiting for its scheduled time. Its dispatch status shows a countdown, and this is the only state in which a call can be cancelled.
Queued — the dispatch engine has claimed the call and the dial is starting. This state normally lasts only a moment. Once a call is Queued, a cancel can no longer win the race — dialling is already underway.
In Progress — the call is live. The Call Log shows an animated status dot, the row updates in place every few seconds, and you can listen in via Live Monitoring.
Terminal statuses — the call has finished, one way or another. See the table below.

Inbound calls, web calls, and test calls skip the first two states: the call record is created the moment the call connects, already In Progress. Note that “test call” here means the specific Test Call button (or any call on a number set to Test) — see Environments: Test vs Live for how that differs from Live inbound/outbound calls. Rescheduling is the one deliberate exception to the one-way rule: it returns a finished call to Scheduled so the same record dials again — see What you can do in each status.

Status reference

The Status column and filter in the Call Log use the display labels below. The API returns the raw value in the call object’s status field (a string, e.g. "in-progress").

Status	API value	Terminal?	Meaning
Scheduled	`scheduled`	No	The call is waiting to dial at its scheduled time.
Queued	`queued`	No	Claimed by the dispatch engine; the dial is starting. Momentary.
In Progress	`in-progress`	No	The call is live right now.
Completed	`completed`	Yes	The call connected and ended normally — the conversation ran its course, someone hung up cleanly, or the caller was handed to a human. The End Reason carries the detail.
Voicemail	`voicemail`	Yes	The call reached voicemail. Also surfaced as the Voicemail end reason — check both when filtering.
Dropout	`dropout`	Yes	The call dropped without connecting properly. Counted as a non-connection and retried automatically in batches.
Hang Up	`hang-up`	Yes	The contact hung up. On recent calls you will usually see Completed with a User Hangup end reason instead; this status still appears on older calls and remains a filter option.
Rang Out	`rang-out`	Yes	The call rang without being answered.
Failed	`failed`	Yes	The call could not be made or could not finish cleanly — a permanent dispatch failure, a connection error, or the platform’s stuck-call safeguard. System Notes on the call usually explain why.
Cancelled	`cancelled`	Yes	The call was cancelled before it dialled — individually, via the API, or as part of a cancelled batch.
User Rejected	`User rejected`	Yes	The person actively declined the incoming call.
User Unavailable	`User unavailable`	Yes	The person could not be reached — the ring timed out or the number was unreachable.

Two display notes:

The Call Log’s status filter offers All Statuses, Scheduled, Completed, Voicemail, Dropout, Hang Up, Rang Out, Failed and Queued. Live calls are easiest to find on the Dashboard or by their animated dot.
The Dashboard’s Call Success Rate chart counts the share of calls with status Completed — it is a connection metric, distinct from the objective-based Objective Met % described below.

What you can do in each status

The canonical eligibility rules for the three manual actions. Reschedule (app) is the Re-dial action on a batch’s call list, which moves the same call record back to Scheduled at a new time. Retry (API) creates a new call from the old one via the Retry Call endpoint — see the API endpoints reference. Web calls can never be retried.

Status	Cancel	Reschedule (app Re-dial)	Reschedule (API)	Retry (API)
Scheduled	Yes	Yes	Yes	No
Queued	No — dialling underway	No	No	No
In Progress	No	No	No	No
Completed	No	Yes	No	No
Voicemail	No	Yes	No	Yes
Dropout	No	Yes	No	Yes
Hang Up	No	No	No	Yes
Rang Out	No	Yes	No	Yes
Failed	No	Yes	No	Yes
Cancelled	No	Yes	No	Yes
User Rejected	No	No	No	Yes
User Unavailable	No	No	No	Yes

Key rules behind the table:

Cancel only works on Scheduled calls. The dispatcher claims calls atomically, so a cancel and a dial never race — whichever lands first wins cleanly. Single calls are cancelled via the API’s Cancel Call endpoint; batch calls in bulk with Cancel Batch (or held with Pause Scheduler). See Scheduling & Managing Calls.
The API’s Reschedule Call is stricter than the app — it only moves calls that are still Scheduled. For finished calls, use Retry Call.
Retry Call covers every terminal status except Completed. A retry reuses the original’s contact, script, outbound number, and objectives, links back to the original with a retry counter, and dials immediately unless you pass a new time.

Automatic batch retries

Batch calls that don’t connect are also retried automatically, on a per-outcome policy you can tune per batch. The platform classifies each finished call into a retry class using its status and end reason together:

Retry class	Triggered by	Default attempts	Default waits
Voicemail	Status Voicemail, or a Voicemail end reason	3	24 h, 48 h, 72 h
No answer	Status Rang Out or User Unavailable, or an end reason indicating no answer or a ring timeout	2	4 h, 24 h
Busy	An end reason indicating the line was busy or engaged	3	1 h, 4 h, 24 h
Transient error	Status Dropout, or Failed with any other end reason	2	1 h, 4 h

Permanent dispatch failures (status Failed with end reason Failed — for example an invalid number or a missing outbound number) are deliberately not retried: they can never succeed as they stand. If the contact rings you back before a retry fires, pending retries for them are cancelled by default. Every retry is a billed attempt — the full policy controls live in Calling Rules.

End reasons

The End Reason appears in the Call Details Metadata section, as a Call Log column and filter, in CSV exports, and in the API call object’s end_reason field (a string, e.g. "AI Hangup").

End reason	Meaning
in-progress	The call is still live — the field is only meaningful once the call has ended.
AI Hangup	The agent ended the call itself: the script reached its natural close, the conversation wrapped up with a goodbye, the silence timers expired, or the script’s Max Call Duration was reached and the agent said its time-limit goodbye.
User Hangup	The person on the other end disconnected first.
Handoff	The caller was successfully transferred to a human and the agent stepped out. The call shows Completed. See Transferring Calls.
Voicemail	The agent detected voicemail, left your configured voicemail message, and hung up.
Failed	The call ended without a clean close — a connection error, an unreachable or rejecting callee, a dispatch failure, or the stuck-call safeguard. Check the status and System Notes for the specifics.
cancelled	The call was cancelled before it dialled.
api_ended	A web call was closed via the API rather than by either participant hanging up.

Occasionally an end reason carries raw telephony detail instead — text mentioning a ring timeout, busy line, or a transient network fault. The retry engine and automations understand these and classify them into the retry classes above.

Correcting an end reason

Automatic classification can occasionally get it wrong — most commonly a voicemail greeting mistaken for a person, or vice versa. In the Call Details panel you can edit the end reason to one of four values: AI Hangup, Failed, User Hangup, or Voicemail. The change saves immediately and flows through to filters and exports. See Call Details.

How the agent decides a call is over

The agent ends calls itself only on an unambiguous close — an exchanged goodbye or an explicit “we’re all set”. Long readouts such as disclaimers are never mistaken for goodbyes, and offers to transfer or “anything else I can help with?” questions don’t trigger a hang-up. If a caller goes silent, the agent checks in first and only says goodbye after an extended silence — see Silence Tolerance.

Dispatch status strings

Scheduled outbound calls carry a plain-text dispatch note in the API call object’s dispatch_status field (a string, e.g. "DELAYED, rate limited"). The canonical set:

Dispatch status	Meaning
Scheduled	More than about two hours from entering the dispatch queue.
Will enter dispatch queue in ~25 min	Countdown in five-minute steps between two hours and ten minutes out.
Will enter dispatch queue in 3 min	Per-minute countdown inside the final ten minutes.
< 1 min, in dispatch queue	Due now; waiting briefly for a free platform slot.
DELAYED, rate limited	Your team’s hourly outbound calling rate is reached; dispatches automatically as the window rolls forward.
DELAYED, concurrency limited	Your team’s simultaneous-call limit is reached; dispatches as soon as a call ends.
dispatch failed	A transient dispatch error; retried automatically within seconds.
Failed to dispatch: (reason)	A permanent dispatch failure; the call is marked Failed and not retried.
Dispatched	Handed to the calling infrastructure; the call shows In Progress.
Cancelled	Cancelled before dialling.

For the full narrative — the two-minute dispatch window, queue ordering, priority tiers, and delay notifications — see Dispatch, Concurrency & Delays.

Outcomes

The Outcome is the single classification of what happened in the conversation, produced by Post-Call Analysis and shown in the Call Details Analysis tab. Outcome codes are stable snake_case values, so they are safe to build automations and reports against.

Default outbound outcomes

Outcome	Meaning
`appointment_booked`	A meeting, appointment or calendar booking was agreed with the contact.
`callback_requested`	The contact asked to be called back at another time.
`will_call_back`	The contact said they would call back themselves.
`not_interested`	The contact declined the offer or purpose of the call.
`opted_out`	The contact asked to be removed from the call list or never contacted again.
`wrong_number`	The person reached was not the intended contact.
`completed`	The call reached a natural end without any of the other outcomes.
`no_answer`	The call was not answered.
`voicemail`	The call reached voicemail or an answering machine.
`did_not_connect`	The call failed to connect.

Default inbound outcomes

Inbound and web calls use a different default set:

Outcome	Meaning
`appointment_booked`	A meeting, appointment or calendar booking was agreed with the caller.
`inquiry_answered`	The caller’s question or request was answered on the call.
`message_taken`	A message was taken for a human to follow up.
`transferred`	The call was transferred or handed to a human.
`callback_requested`	The caller asked to be called back.
`caller_abandoned`	The caller hung up before their request was resolved.
`wrong_number`	The caller had reached the wrong number or business.
`spam`	The call was spam, a robocall or an unwanted solicitation.
`unresolved`	The caller’s request could not be completed.

Custom outcome sets

A script can replace the default rubric with its own outcome options in its Post-Call Analysis tab. For outbound scripts, the three telephony codes — no_answer, voicemail, and did_not_connect — are always appended to a custom set if missing, so non-connections can never be misclassified. The Analysis tab’s footer records which outcome set was used (outbound, inbound, or custom).

Telephony-stamped outcomes

When the call’s status already proves what happened, the outcome is stamped deterministically from the status rather than judged from the transcript:

Status	Stamped outcome
Voicemail	`voicemail`
Rang Out	`no_answer`
Dropout	`did_not_connect`
Failed	`did_not_connect`
User Rejected	`did_not_connect`
User Unavailable	`did_not_connect`

Any other status leaves the outcome to the analysis of the conversation.

Objectives and Success Evaluation

Two further per-call results measure success against your script’s Call Objectives:

Call Objectives — each objective on the call is evaluated after the conversation and lands in one of three states: met, not met, or pending (not yet evaluated, or indeterminate). The Call Details panel shows them as toggles you can correct by hand, and CSV exports render them as Success, Fail, or Pending per objective.
Success Evaluation — a per-call text field summarising the objective results as a whole. It appears as a Call Log column and filter, in CSV and JSON exports, and as the Evaluation badge in Batch Analytics. Depending on when and how the call was evaluated you may see a simple verdict such as success, failure, or pass, or a compact summary counting objectives met versus total. The Dashboard’s Objective Met % chart is built from these objective counts; its Call Success Rate chart, by contrast, simply counts Completed statuses.

Statuses in automations and the API

Call Completed automations fire once a call finishes post-call processing, and can be filtered by call status in the trigger’s conditions — for example, run a follow-up only for Voicemail calls. Calls that never dialled — a permanent dispatch failure or a call cancelled before it started — skip processing entirely, so no automation fires for them. The trigger payload includes the call’s type, status, contact, and timing. See Automation Triggers.
Automations that branch on how the dial went classify calls into connected, voicemail, no_answer, or busy using the same status-plus-end-reason rules as the retry engine above.
The API’s Get Call Status endpoint returns the live status, progress, and end_reason for polling a call you created; Get Call Result adds the transcript, summary, objectives, and collected data once processing completes. See the API endpoints reference.

Next Steps

Dispatch, Concurrency & Delays — the journey from Scheduled to In Progress, and every dispatch status in context.
Scheduling & Managing Calls — create one-off calls and use the reschedule, cancel, and retry actions day to day.
Post-Call Analysis — configure the outcome set and custom classification fields your calls are scored against.
Calling Rules — tune the automatic retry policy your batches apply to voicemail, no-answer, busy, and transient failures.

Get Started & Build

Calls, Contacts & Batches

Numbers & Routing

Tools, Automations & Integrations

Account, Billing & Security

Call Statuses, End Reasons & Outcomes Reference

Overview

The status pipeline

Status reference

What you can do in each status

Automatic batch retries

End reasons

Correcting an end reason

How the agent decides a call is over

Dispatch status strings

Outcomes

Default outbound outcomes

Default inbound outcomes

Custom outcome sets

Telephony-stamped outcomes

Objectives and Success Evaluation

Statuses in automations and the API

Next Steps

​Overview

​The status pipeline

​Status reference

​What you can do in each status

​Automatic batch retries

​End reasons

​Correcting an end reason

​How the agent decides a call is over

​Dispatch status strings

​Outcomes

​Default outbound outcomes

​Default inbound outcomes

​Custom outcome sets

​Telephony-stamped outcomes

​Objectives and Success Evaluation

​Statuses in automations and the API

​Next Steps

Overview

The status pipeline

Status reference

What you can do in each status

Automatic batch retries

End reasons

Correcting an end reason

How the agent decides a call is over

Dispatch status strings

Outcomes

Default outbound outcomes

Default inbound outcomes

Custom outcome sets

Telephony-stamped outcomes

Objectives and Success Evaluation

Statuses in automations and the API

Next Steps