Outbound Dialer Methods
Overview
For each Queue Campaign, you can choose from different Outbound Dialer Methods, that define the strategy the dialer uses to generate and manage outbound calls.
Selecting the right method is essential to align with your campaign goals, agent availability, and compliance requirements.
Discover the available Dialer Methods:
Progressive Dialing
How it works | ✅ Recommended Use Case |
|---|---|
In the Progressive dialing method, the outbound dialer places one call as soon as an agent becomes available in the queue. This ensures a direct connection between agents and contacts with minimal delay.
📞 Call Flow: | This method is highly recommended for setups with fewer than 30 agents.
|
When setting up a Queue Campaign with the Progressive dialing method, you only need to configure a few essential parameters to control how the dialer behaves:
Max Concurrent Calls: defines the maximum number of simultaneous outbound calls that the dialer can originate for this campaign (where 0=unlimited calls).
If you have 20 agents but set Max Concurrent Calls to 10, the dialer will never place more than 10 calls at the same time, even if more agents are available.Queue Timeout: sets the maximum time (in seconds) that the contacted customer will remain in the queue waiting for an agent to answer (Default value=3 seconds).
If no agent answers within this time, the call is marked as Dropped.
If the contact hangs up before the timeout, the call is marked as Abandoned.Agent Timeout: defines the number of seconds the system will ring an agent's device before moving the call to another available agent.
If an agent does not answer within this time, the call is rerouted to the next available agent in the queue.
Scenario:
If you need to modify other parameters of a queue campaign, you can explore here documentation about edit section.
Ring in use with progressive method It is not recommended to enable “Ring In Use” for Queue Campaigns using the Progressive Dialing method. The Ring In Use setting determines whether the dialer should consider agents who are ringing as still available or busy. This affects how many calls the dialer can initiate at a time. If Ring In Use is enabled on both the Queue Campaign and the agent’s Phonebar or WebRTC settings, then the Progressive Dialer algorithm strictly checks the number of available (idle) agents before initiating calls. 🎯Best Practice: Do NOT enable “Ring In Use” on Progressive queue campaigns.
|
Power Dialing
How it works | ✅ Recommended Use Case |
|---|---|
The Power Dialing method is similar to Progressive Dialing but functions as a call multiplier. 📞 Call Flow:
For example: Power Level = 4 | 5 available agents → The dialer initiates 5 × 4 = 20 calls simultaneously. | This method is designed to maximize agent occupancy, even if many contacts do not answer. Power Dialing is ideal when:
|
When setting up a Queue Campaign with the Power Dialing method in XCALLY Motion Bull, you must configure the following parameters to control dialing behavior:
Power Level: defines how many outbound calls are made for each available agent. The range can be set between 1 and 10, but pay attention not to increase too much this value in order not to lose calls.
How it works: The total number of calls =Number of available agents × Power Level
If you choose a power level with a comma, the result is rounded down to the nearest whole number.
Example: 3 available agents | Power Level = 4.5 | Dialer will generate 13 calls (3 × 4.5 = 13.5 → rounded down to 13)
🎯Best Practice: start with a moderate Power Level (e.g., 2–4), then adjust based on real-time answer rates and agent occupancy.
Max Concurrent Calls: specifies the maximum number of outbound calls that can be active (ringing or in conversation) at any given time for this campaign.
Value: Any positive integer where
0= Unlimited concurrent calls
Example:
Even if the Power Level calculation results in 40 potential calls, if Max Concurrent Calls is set to 25, only 25 calls will be placed at once.
🎯Best Practice:
Set this based on your system capacity, available trunk channels, and agent count to avoid overloading your infrastructure.
Agent Timeout: defines the maximum time in seconds that the system will ring an agent’s device before trying the next available agent.
🎯Best Practice:
Typical values range from 10 to 20 seconds, depending on your agents’ response behavior.
If you need to modify other parameters of a queue campaign, you can explore here documentation about edit section.
Ring in use with power dialing method We strongly recommend NOT enabling “Ring In Use” for Queue Campaigns using the Power Dialing method. When using Power Dialing, this setting influences whether calls exceeding the number of available agents are still attempted — and how they are handled by the system and agents’ devices. In Power Dialing, the system may generate more calls than available agents (based on the Power Level). The Ring In Use setting determines whether agents are considered available even while ringing or on a call, and how additional calls are treated. 🎯Best Practice: DO NOT enable Ring In Use on the Queue Campaign, regardless of agent-side settings. |
Scenario | Ring In Use (Queue Campaign) | Ring In Use (Phonebar/WebRTC) | Behavior | Outcome |
|---|---|---|---|---|
1 | ❌ Disabled | ❌ Disabled | System only calls when agents are fully available | If 3 agents are free and the algorithm calculates that it can make 5 calls, 3 agents start to talk with the first 3 customers and 2 extra calls will be automatically rejected and considered like dropped. |
2 | ✅ Enabled | ✅ Enabled | System ignores current agent status (e.g., busy or ringing) and the number of calls will exceed the number of available agents. | If 3 agents are free and the algorithm calculates that it can make 5 calls, all 5 calls are routed; 2 extra calls may ring agents already on a call, but they can’t answer, leading to confusion or missed calls. |
3 | ✅ Enabled | ❌ Disabled | Calls exceeding the number of available agents will be sent by the queue campaign | Extra calls are automatically rejected by the WebRTC or phonebar, resulting in unnecessary call attempts and Dropped calls |
4 | ❌ Disabled | ✅ Enabled | System limits calls to number of available agents | Extra calls aren’t sent, no risk of rejected calls or agent overload |
In Progressive, Power and Predictive dialing campaigns, when the dialer places a call to book an agent (i.e., connect the agent to a customer), it expects the agent to answer promptly.
If the agent rejects the incoming call — either by declining it manually on the Phonebar/WebRTC or due to device behavior — this action is tracked and logged for audit and reporting purposes.
The event is recorded in the table: cm_hopper_history and the system sets the call status to: Agent Reject
Preview Dialing
How it works | ✅ Recommended Use Case |
|---|---|
The Preview Dialing method offers a more controlled and agent-driven approach to outbound calling. Unlike automated methods (e.g. Progressive, Power, or Predictive), Preview Dialing is not based on Asterisk queues and functions in a more manual and interactive manner. 📞 Call Flow:
| Preview Dialing is ideal when you want to give agents maximum control over who they call and when. 🔎 Recommended Use Cases:
|
When setting up a Queue Campaign using the Preview Dialing method, you only need to configure Agent Timeout, specifying how long (in seconds) the system will ring the agent’s device after they accept a previewed call.
If you need to modify other parameters of a queue campaign, you can explore here documentation about edit section.
Ring in use with preview method Since the Preview Dialing method does not rely on queues, the “Ring In Use” option is not available or applicable at the Queue Campaign level.
|
When an agent opens the Preview modal to recall a contact, they have access to a History tab that provides valuable information about the contact’s previous interactions within the campaign.
This tab displays up to the last 10 records of the contact’s rescheduling activity, showing how many times and when the contact has been rescheduled by agents.
The information is visible to all agents associated with the campaign, promoting better coordination and awareness.
This feature helps agents avoid redundant calls and better plan their outreach strategy.
Booked Progressive Dialing
How it works | ✅ Recommended Use Case |
|---|---|
The Booked Progressive dialing method operates independently from Asterisk queues. Unlike traditional queue-based methods, this approach first books an agent—selecting the first available one who is not currently handling calls from any queues they belong to—before initiating the outbound call. 📞 Call Flow:
| This method is recommended when it is critical to ensure the customer is always connected to a dedicated agent before the call begins. |
When setting up a Queue Campaign with the Booked Progressive method, you need to define the following:
Max Concurrent Calls: the maximum number of concurrent calls that will be originated by the dialer for this campaign (where 0=unlimited calls)
Agent Timeout: time in seconds an agent phone will ring (Default value=3).
When editing the campaign in the Queue section, you must select an agent assignment strategy. The following options are available:
Round Robin Memory (✅ Recommended): the system remembers the last agent contacted and continues from the next agent in the list. It ensures balanced distribution of calls among agents.
Round Robin starts always from the first agent
If you need to modify other parameters of a queue campaign, you can explore here documentation about edit section.
Ring in use with booked progressive method The Booked Progressive method is not based on Asterisk queues, so the “Ring In Use” option is not available at the Queue Campaign level. Instead, this setting can only be managed per agent, in the Phonebar or WebRTC configuration. |
In the Booked Progressive dialing method, agent rejection is treated differently from other dialing modes such as Progressive, Power, or Predictive.
When an agent rejects a call, this action is not logged in the cm_hopper_history table. The system does not record a Hopper entry with the status Agent Reject, and the rejection does not influence the agent’s penalty score or call assignment priority.
The rejection event is tracked in the database table: report_agent_preview: this table logs agent behavior specifically for Booked Progressive and Preview methods, where agent interaction occurs before the customer is dialed.
Predictive Dialing
How it works | ✅ Recommended Use Case |
|---|---|
The Predictive Dialing method leverages a dynamic algorithm to optimize outbound call efficiency. It uses a predictive interval to gather real-time statistics to determine the optimal number of contacts to call. The predictive optimization factor can be set to prioritize either:
📞 Call Flow:
| This method is recommended when you have 30 or more agents available in the campaign, and you aim to maximize efficiency (achiving a higher busy factor). E.g. predictive indicates that 300 calls can be made in 10 minutes.
|