> ## Documentation Index
> Fetch the complete documentation index at: https://docs.firetone.com.au/llms.txt
> Use this file to discover all available pages before exploring further.

# Queues

> Where an inbound caller waits, who is offered the call, and what today's queue actually does with the strategy you chose.

A queue holds callers and offers them to agents. It lives under **Inbound**,
beside processes and numbers, because a queue is a property of *how a number
is answered* — not of a shift, and not of the phone system's inventory.

## What happens to a caller, in order

<Steps>
  <Step title="Answered, then music">
    The call is answered and the hold music starts at that moment, before
    anybody's phone rings. Resolving who to ring takes a moment, and silence
    in that moment is what a caller hears as a dead line.
  </Step>

  <Step title="Every member's every device rings at once">
    Not one device per person: an agent who takes queue calls in the browser
    as well as on a handset has both ring, exactly as a direct call to them
    does.
  </Step>

  <Step title="The first to answer wins">
    Everybody else stops ringing, and the call is attributed to whoever
    actually picked it up.
  </Step>

  <Step title="Or the wait runs out">
    After **Max wait** the call leaves the queue. If the queue takes
    messages, the caller is offered voicemail; otherwise they are told nobody
    is free and the call ends.
  </Step>
</Steps>

<Note>
  **The strategy is stored, and today every queue rings everyone.** The four
  choices — ring everyone, longest idle first, take turns, in order — are
  saved on the queue and shown back, and the call path is a ring-all against
  the available members whichever is chosen. Full distribution, with skills
  and wrap-up, is still to come. Choose the one you want; expect ring-all
  until then.
</Note>

## Members

Members are **agents**, rostered individually, each with a priority.

A member is rung when they are a **human** agent whose extension is enabled.
Priority orders the list and, because the ring is simultaneous, does not yet
stagger who is tried first.

<Warning>
  A **virtual agent can be added to a queue and is not rung by it**. The
  queue path asks for human members only. To have a virtual agent answer,
  point the number or the flow at it directly — see [virtual
  agents](/tenant/ai/virtual-agents).
</Warning>

Rostering needs `queues:write`, which a supervisor holds as well as an admin.
Adding somebody who is already a member replaces their priority rather than
failing.

## Settings

| Setting          |                                                                                                                      |
| ---------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Hold music**   | this queue's own, otherwise the organisation's, otherwise the switch's                                               |
| **Strategy**     | see the note above                                                                                                   |
| **Max wait**     | seconds before the call leaves the queue. 0 is no limit; a queue that has never been given one behaves as 60 seconds |
| **Team**         | which team this queue belongs to, for filtering and reporting                                                        |
| **Record calls** | see below                                                                                                            |
| **Voicemail**    | whether a caller who could not be connected is offered a message                                                     |

Hold music is resolved most specific first, so a queue with its own music
costs nothing extra to play — see [the audio
library](/tenant/inbound/audio).

## When nobody can be reached

Two different failures, deliberately told apart:

| What the caller hears                         | Recorded as                                                  |
| --------------------------------------------- | ------------------------------------------------------------ |
| nobody was available, or a voicemail greeting | **failed**, or **voicemail** — the queue had nobody to offer |
| the wait ran out while they were on hold      | **timed out**, or **voicemail**                              |
| they hung up first                            | **abandoned**                                                |

Those demand opposite responses from whoever reads the report: staff the
queue, shorten the wait, or find out why callers are giving up. A timeout and
an abandon are told apart by the clock rather than by what the switch called
the error, because that text would silently reclassify every one of them the
day it changed.

The stock "nobody is available" wording is the closest sentence the switch
ships. A tenant with a real queue records their own.

## What you see live

Waiting calls and the longest current wait, from the live wait tracker rather
than from the call records, so every node agrees about the same queue.

<Note>
  Where the figure cannot be read, FireTone reports it as unavailable rather
  than as zero. A staffing decision made on an invented number is worse than
  one made on an honest "unknown".
</Note>

Each visit to a queue is its own record, so a call sent from one queue to
another keeps both. A single queue against the call would keep only the last
one, losing the queue that actually made the caller wait.

## Recording

Calls answered through this queue can be recorded by switching **Record
calls** on here.

Recording is on if **any** level says so — organisation, team, extension,
queue, trunk or process — so this can add recording and cannot switch off a
policy set above it. See [Recording, and what is
kept](/guides/recording-and-retention).