The Call Queue app is the primary tool for contact-centre call handling in Natterbox. It holds inbound callers in an intelligent queue and connects them to the most appropriate available Agent using the distribution and routing rules you define.
Available in the Call Policy? | Available in the Data Analytics Policy? | Available in the Digital Policy? | Available in the System Policy? |
|---|---|---|---|
✔ | ✘ | ✘ | ✔ |
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
Purpose: Holds inbound callers in a queue and distributes them to available agents, one at a time, based on the rules you configure.
Location: Action container, within a Call Routing Policy.
What is the Call Queue app?
The Call Queue app provides automatic call distribution for sales teams, support lines, contact centres and more. Inbound callers are placed into a holding queue — hearing hold music and announcements — until an agent becomes available. Rather than ringing everyone at once, the app selects the right agent on a prioritised basis and manages how long callers wait, what they hear, and what happens if no one answers.
It works across three layers:
The queue — where callers wait, and the order in which they are served.
The group — the agents eligible to take calls from this queue.
The agent — the individual selected for each call, according to the distribution rule.
ℹ️
Call Queue vs Hunt Group: A Call Queue holds callers and connects them to one agent at a time with ACD features such as skills routing, callbacks, wallboard visibility and wrap-up. To ring several people simultaneously with no queuing, use the Hunt Group app instead.
Before you begin
Make sure the following are in place before you build your queue:
A Natterbox group containing the agents who will take the calls. This group will need the Contact Centre Purpose. At least one group is required. See Creating a Group.
Availability Profiles and States configured so the platform knows which agents are available to receive queued calls. See Availability Profiles and States.
Skills assigned to your users — only needed if you are using skills-based routing to match callers to agents by skill. See How to enable skills routing.
A Call routing policy open in the Policy Builder, with an Action container ready to hold the app.
Account Settings reviewed — default hold music, TTS voice and External Caller ID are all inherited from Account Settings unless overridden in this app.
Use cases
Sharing workload evenly across a team by routing each call to the longest-idle agent.
Holding callers with hold music and informative announcements during busy periods.
Offering callers a callback — keeping their place in line — instead of waiting on hold.
Routing calls to agents by skill (e.g. language, product expertise) or prioritising VIP callers ahead of others.
Screening calls so agents hear a whisper announcement telling them which queue a call is from before the caller is connected.
Transferring the caller to a post-call survey or thank-you message after the agent hangs up.
Configuration reference
Give the app a name under Name this item, then configure it under Configure this item. Configuration is split across five tabs: Groups, Properties, Announcements, Screen and Callback.
Groups tab
The Groups tab defines which group of agents takes the calls and how those calls are distributed among its members. At least one group is required. You can add multiple groups to create priority tiers — the top group is tried first, then the next, and so on.
Click the + button to open the group dialogue, configure the fields below, then click Done.
Field | Value (* = default) | Notes |
|---|---|---|
Call Group | Dropdown of existing groups | The Natterbox group whose members will receive calls from this queue. Groups are created in the Admin Portal under Groups. |
Distribution Rule | Longest Idle* | Determines how a call is allocated to a member of the group. See the Distribution rules table below. |
Wrap-Up Type | Standard* | Early Exit | Extend and Early Exit | Controls whether agents can adjust their wrap-up period after a call ends. See the Wrap-Up types table below. |
Wrap-Up Time (seconds) | 60 | After an agent answers and then hangs up, this period must pass before the queue will dial them again — giving them time to complete after-call work. |
Wrap-Up Failed Time (seconds) | 60 | If an agent does not answer when dialled, this period must pass before they become eligible to be dialled again. |
Ring Time (seconds) | 30 | How long an agent is rung before the queue moves on to the next eligible agent. |
Call screening is enabled | Unticked* | Plays a whisper announcement to the agent before connecting the caller. Configured on the Screen tab. |
Call waiting is enabled | Unticked* | Allows an agent to be offered a queued call while already on another call. |
Skill routing is enabled | Unticked* | Tick this checkbox to enable skills-based routing for this group or to unlock the Callback tab. See the note on callbacks below. |
⚠️
Callback requires “Skill routing is enabled” to be ticked — but you do not need to actually use skills in your policy. No Request Skills app, no skill assignments, no skill configuration is needed. Simply tick the checkbox on at least one group, click Done, and the Callback tab becomes available. Think of it as a silent prerequisite that unlocks the feature — skills themselves are entirely optional unless you genuinely want skill-based call matching.
Distribution rules
Rule | How it selects an agent |
|---|---|
Longest Idle (recommended) | Selects the agent who has been idle (off the phone for this group) the longest, or who was last dialled (unanswered) the longest time ago. Only activity for this group is considered — calls in other queues or outbound calls are not counted. If a user sets themselves as available and their idle time already exceeds everyone else’s, they will immediately become first in line. |
Sequential | Rings each agent in a fixed order, starting from the top of the group list each time a new call enters the queue, regardless of whether they have answered previous calls. |
Least Talk | Selects the agent who has spent the fewest total minutes on calls for this group. |
Least Calls | Selects the agent who has answered the fewest total calls for this group. |
All Agents | Rings every available agent in the group simultaneously — whoever answers first takes the call. |
Wrap-Up types
Wrap-Up Type | Behaviour |
|---|---|
Standard | The agent receives the full wrap-up period as configured. They cannot end it early or extend it — the timer runs its course before the next call is offered. |
Early Exit | The agent can end their wrap-up period early (for example, by setting themselves back to an available state). The next call is offered immediately upon exit. |
Extend and Early Exit | The agent can both exit wrap-up early and extend the wrap-up period if they need more time to complete after-call work. |
Group ordering and priority
Once you have added two or more groups, use the up and down arrows to set their priority order. The number shown under the ↑↓ icon indicates each group’s priority rank. The queue uses this order as follows:
If any agents are available in the first (highest-priority) group, the queue attempts to connect the call to one of them.
If no agents are available in the first group, the queue checks the second group, and so on down the list.
ℹ️
Note: An agent may appear idle but still be within their wrap-up period — in which case they are ineligible to be dialled. This can result in a lower-priority group receiving calls while agents in a higher-priority group are still in wrap-up.
To edit or delete a group, click the corresponding icon next to that entry.
Skills-based routing (summary)
When Skill routing is enabled is ticked and you want to use skills-based matching, the following additional fields appear:
Skill Engine — choose Built in (uses the configured skill matching rules) or Lua (custom script logic).
Order Algorithm — Sum (agent skill values are added together to calculate priority) or Maximum (the highest individual skill value determines priority).
Agents Require All Skills — when ticked, an agent must possess every requested skill to be considered eligible.
Skills are assigned to users via the Natterbox Skills objects in Salesforce and requested at runtime using the Request Skills app earlier in the routing policy. If you have only ticked the checkbox to unlock Callback and are not using skills, you can ignore these fields entirely.
💡
Tip: For a full walkthrough of enabling and configuring skills routing, see How to enable skills routing.
Properties tab
The Properties tab controls queue-wide behaviour — how callers are ordered, what they hear while waiting, and the limits applied to the queue.
Property | Value (* = default) | Notes |
|---|---|---|
Queue Algorithm | Ordered by Priority, Time Queued* | Weighted Queuing Time | Ordered by Priority, Time Queued: Callers are served by priority first, then by how long they have been waiting. |
Transfer after Connect | Blank | After a call is answered and the agent hangs up, the caller is transferred to the endpoint specified here. Useful for routing to a post-call survey or a thank-you message via the Speak app. Supports macros via the macro selector. |
Hold Music | Auto* | Preset | Custom | Auto plays the hold music configured in Account Settings. Preset opens a dropdown of standard hold music tracks. Custom opens a URL field for an externally hosted recording (Shoutcast stream). See How to use custom hold music. |
How often (in seconds) to announce to the caller | 60 | The length of one announcement loop, measured from the start of one loop to the start of the next. A shorter value means more frequent announcements. |
Maximum calls this call queue should support | 100 | The maximum number of callers that can be held in the queue at one time. Once reached, new callers are passed to the next app in the container. |
Maximum time (in minutes) a caller can sit in a call queue | 30 | The longest a single caller can remain in the queue, in minutes. After this time the call is passed to the next app in the container. |
How long (in seconds) until an answered call is considered ‘solid’ | 120 | The minimum duration (in seconds) a connected call must last to be considered a “solid” call. Calls shorter than this may indicate wrong numbers, voicemails or spam. This metric is used in Wallboard queue components to show the percentage of solid calls. |
Key to exit the queue | null* (disabled) | 0–9, * or # | If set, callers can press this key to leave the queue. The call then routes from the app to the container it is linked to. Communicate this key to callers via an announcement. |
Override the Caller ID Name | Blank | Overrides the display name shown on the agent’s SIP phone when the queue connects a call. Supports macros via the macro selector to customise per call. |
Enable Auto Answer | Off* | When toggled on, the agent’s phone answers automatically. Two additional fields appear: How long (in seconds) before the call is auto answered and Sound the agent hears to announce auto answer call. Requires a compatible handset or softphone. |
Allow Agent to reject incoming call | On* | When enabled, agents can reject an incoming queued call. The call is then returned to the queue and offered to the next eligible agent. |
Announcements tab
The Announcements tab defines timed messages played to callers while they wait in the queue. Each announcement has a format, a wait time, and a play frequency. Announcements never overlap — if two have the same wait time, the first in the list plays first, and the next follows immediately after.
Click the + button to add an announcement.
Property | Value (* = default) | Notes |
|---|---|---|
Play Sound | Once* | Every Loop | Once plays the announcement only during the initial loop. Every Loop repeats it in every subsequent loop (the loop length is set in the Properties tab’s announce interval). |
Seconds to wait before playing sound | 60* | How many seconds to wait before the announcement is played, measured from either the start of the queue or the start of a new loop. |
Format | Sound* | Text To Speech | Tone | MP3 via HTTP | Shoutcast | The format of the announcement. Sound uses a pre-uploaded system sound. Text To Speech converts typed text to speech. MP3 via HTTP plays a file from a URL. Shoutcast streams from a Shoutcast server. |
Sound / Text / Tone data / URL | Depends on format | The content of the announcement. For Text To Speech, type the text to be spoken. For Sound, select from the dropdown of custom sounds (created in Account Settings). For MP3/Shoutcast, enter the URL. |
Ordering and editing announcements
Once added, announcements can be edited or deleted by clicking the appropriate icon. The order can be rearranged using up/down arrows (available when two or more announcements exist). However, the order does not determine when announcements play — that is controlled entirely by the Seconds to wait value. Order only matters when two announcements share the same wait time (in which case the higher one in the list plays first).
Rule-based announcements
Announcements can be made conditional by switching to Rule Based Announcements mode. This lets you apply rules (e.g. only play a position announcement when the caller is beyond position 5). Click the rule icon next to an announcement to configure conditions.
💡
Tip: Use staggered Seconds to wait values to build a natural flow. For example: a greeting at 0 seconds, a position update at 30 seconds, and a callback offer at 120 seconds.
Screen tab
The Screen tab plays a whisper announcement to the agent before the caller is connected. This lets the agent know which queue the call is from (useful when agents serve multiple queues) and optionally requires them to accept the call by pressing a key.
To use call screening, tick Call screening is enabled on the Groups tab for the relevant group, then configure this tab.
Property | Value (* = default) | Notes |
|---|---|---|
Announcement | Blank text field | The message played to the agent. Supports TTS text, pre-recorded sound tags (inserted via the sound selector, e.g. |
Accept Key | No acknowledgement required* | The key the agent must press to accept the call after hearing the whisper. If set to No acknowledgement required, the caller is connected automatically after the announcement plays. If a key is configured but the agent does not press it within the response time, the call returns to the queue. |
Maximum response time (seconds) | 10 | How long the agent has to press the accept key before the call is returned to the queue and offered to the next agent. |
Announcement repeat | 5 | How many times the whisper announcement is repeated while waiting for the agent to press the accept key. If an accept key is configured but remains unpressed after the specified number of repeats, the call progresses to the next app in the container (or the container itself). |
Preview your message
Click the play button to hear exactly what the agent will hear. The preview supports both sound files and TTS messages (including a mixture of both).
When playing, the play button changes to a stop button.
You do not need to save the policy to hear an updated preview after making changes.
Right-click the play button to select a different voice for the preview. This selection is remembered but does not affect what agents hear in production (which uses the default voice from Account Settings).
If macros are present in the message, you will be prompted to enter a value for each macro before playback begins (this is for preview purposes only).
Callback tab
The Callback tab lets callers request a callback instead of waiting on hold, keeping their place in line. When a callback is activated, the caller hangs up and the system calls them back when an agent becomes available.
⚠️
Prerequisite: The Callback tab is locked until at least one group has the Skill routing is enabled checkbox ticked. You do not need to configure or use skills in any way — just tick the checkbox, click Done, and the Callback tab unlocks. This is a UI-level prerequisite only; skills themselves are entirely optional for callback functionality.
Toggle Enable Callback on to reveal the configuration fields:
Property | Value (* = default) | Notes |
|---|---|---|
Enable Callback | Off* | Master toggle. When on, the remaining fields become active. |
Activation Key | # * | The DTMF key the caller presses to request a callback (0–9, #, or *). Communicate this to the caller via an announcement. |
Activation Position | 10 | The callback option is only available to callers at or beyond this position in the queue. For example, if set to 10 and the caller is at position 3, the option is not offered. |
Activation Queueing Time (seconds) | 300 (5 minutes) | The caller must have been waiting at least this long before the callback option becomes available. Works in conjunction with Activation Position — both conditions must be met. |
Caller can leave message | On* | When enabled, the caller can record a voice message after requesting a callback. The agent hears this message before the return call is placed. |
Access Control List | Any* | Allow | Block | Controls which phone numbers are permitted to use callback. |
Number of callback attempts | 1–5 (3*) | How many times the system will attempt to call the customer back if the initial attempt is unanswered. When set to more than 1, additional fields appear to configure the wait time between each attempt (configurable in seconds, minutes or hours). |
CLI Presentation | Withhold | Specified* | Default | The number presented to the caller on the callback. |
CLI | Blank text field | Only available when CLI Presentation is set to Specified. Enter the phone number to present on the callback. This is a mandatory field when visible. |
+ Add Custom CLI | Per-country override | Allows a different CLI to be presented for callers from specific countries. For each custom CLI entry, you set: CLI Presentation (Withhold or Specified), Country (from a dropdown list), and CLI number. Add as many country-specific overrides as needed. |
💡
Tip: To report on callbacks, see Create Callback Report with Skills.
Worked example: a simple sales queue
This example builds a basic queue that distributes calls evenly across a Sales group and offers a callback when the wait is long.
In your Call policy, add a Call Queue app to an Action container and give it a descriptive name (e.g. Sales – Call Queue).
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
On the Groups tab, click +, select your Sales group, set Distribution Rule to Longest Idle, and tick Skill routing is enabled (to unlock Callback — no further skills configuration needed). Click Done.
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
On the Properties tab, set Hold Music to Auto and leave the queue limits at their defaults.
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
On the Announcements tab, click + and add a Text To Speech announcement at Seconds to wait: 0 (e.g. “Thank you for calling Sales. An agent will be with you shortly.”). Set Play Sound to Once.
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
Add a second announcement at Seconds to wait: 120 informing callers they can press # for a callback. Set Play Sound to Every Loop.
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
On the Callback tab, toggle Enable Callback on. Set Activation Key to #, Activation Queueing Time to 120 seconds (matching your announcement), and leave other fields at defaults.
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
Save and publish the routing policy. (This is a mock scenario for handling multiple teams/call queues in a single policy.)
.png?sv=2026-02-06&spr=https&st=2026-06-17T14%3A02%3A25Z&se=2026-06-17T14%3A29%3A25Z&sr=c&sp=r&sig=%2FSW1vYptJd1mIXJB6A%2F6z1RvpzPoW8O3LIdOGrhby18%3D)
Place a test call to confirm the queue holds the call, plays hold music, delivers the announcement at 2 minutes, and successfully triggers a callback when you press #.
Result
When the queue connects a caller to an agent, the call exits the app. If Transfer after Connect is configured, the caller is transferred to that endpoint after the agent hangs up. Otherwise the call proceeds to the next step in the policy (or ends).
Other exit scenarios:
Caller presses the Exit Key — the call follows the link to the container connected from this app. This counts as the app being triggered.
Maximum Time is reached — the call passes to the next app in the container (or the container itself). This counts as the app not being triggered.
Maximum Calls is reached — new callers cannot enter the queue and are passed to the next app in the container.
Callback requested — the caller hangs up; the system retains their position and calls them back when an agent is free.
No agents available in any group — the caller remains in the queue (hearing hold music and announcements) until either an agent becomes available, the Maximum Time expires, or the caller hangs up / presses the exit key.
⚠️
Important: If the app is triggered (e.g. caller presses the exit key) but there is no link to a follow-up container, the call is hung up by default. Always provide an onward path for exited calls.
Best practices
Use Longest Idle as your default distribution rule. It provides the fairest workload distribution and is recommended for most teams.
Keep Ring Time between 15–20 seconds. Long ring times delay delivery to the next agent; very short times may not give agents enough time to answer.
Set a realistic Maximum Time. 30 minutes is the default, but consider your SLA — callers waiting beyond your acceptable threshold should be routed to an alternative (e.g. voicemail or overflow group).
Stagger your announcements. Do not play them too frequently (it interrupts hold music) or too infrequently (callers feel forgotten). Every 30–60 seconds is a good starting point.
Always pair Callback with a clear announcement telling callers which key to press and when the option is available.
Test thoroughly after changes. Place real calls through the queue to verify hold music, announcements, callback and agent delivery all work as expected before going live.