> ## 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. # Call Statuses, End Reasons & Outcomes Reference > The canonical reference for every state a Voxworks call can be in: the status pipeline, end reasons, dispatch status notes, post-call outcome taxonomies, Success Evaluation, and exactly what you can cancel, reschedule, or retry in each status. ## 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](/calls/history) 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](/scripts/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](/calls/dispatch-and-concurrency) for the queue-to-dial journey, [Scheduling & Managing Calls](/calls/scheduling-calls) for creating and managing calls, and [Post-Call Analysis](/scripts/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](/calls/live-monitoring). * **Terminal statuses** — the call has finished, one way or another. See the table below. Inbound calls, [web calls](/calls/web-calls), and [test calls](/calls/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](/getting-started/environments) 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](#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](/dashboard/overview) 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](#success-evaluation). *** ## 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](/api-reference/overview). 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](/calls/scheduling-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](/batches/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](/routing/transferring-calls). | | **Voicemail** | The agent detected voicemail, left your configured [voicemail message](/scripts/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](/calls/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](/conversation-dynamics/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](/calls/dispatch-and-concurrency). *** ## Outcomes The **Outcome** is the single classification of what happened in the conversation, produced by [Post-Call Analysis](/scripts/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](/scripts/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](/batches/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/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](/api-reference/overview). *** ## Next Steps * [Dispatch, Concurrency & Delays](/calls/dispatch-and-concurrency) — the journey from Scheduled to In Progress, and every dispatch status in context. * [Scheduling & Managing Calls](/calls/scheduling-calls) — create one-off calls and use the reschedule, cancel, and retry actions day to day. * [Post-Call Analysis](/scripts/post-call-analysis) — configure the outcome set and custom classification fields your calls are scored against. * [Calling Rules](/batches/calling-rules) — tune the automatic retry policy your batches apply to voicemail, no-answer, busy, and transient failures.