Dialer Methods in Queue Campaigns

Created by Jens Leijon, Modified on Wed, 27 Sep 2023 at 10:15 AM by Hannah Peters

This article explains the what the different Dialer Methods do. They are used to choose in which way the system should make outbound calls to your customers in Dialer Campaigns.


This article explains:




Progressive


How it works
The outbound dialer will generate one call as soon as there is an available agent in the queue. 
The system calls the customer first and when he/she answers the call, the system sends call to queue campaign, that distributes the call to available agent.

When is this method recommended?
This method is recommended when there are fewer than 30 agents.
Some simulations have shown that with less than 30 agents, busy factor is higher than that one obtained with predictive algorithm.

Algorithms are optimized to work with agents allocated only in one queue campaign and not optimized to work with agents allocated in several queues campaign.

For this method you need to choose:

During the creation of a queue campaign, if you choose Progressive Method, you just need to insert the following parameters:

  • Max Concurrent Calls: the maximum number of concurrent calls that will be originated by the dialer for this campaign (where 0=unlimited calls).
    If for example you have 20 agents but you insert 10 max concurrent calls, in this campaign there will be maximum 10 calls at the same time, because it is not possible to exceed the indicated number

  • Queue Timeout: time in seconds the dialer waits for a call in the queue to be answered before dropping it (Default value=3). So the contacted customer remains in the queue for 3 seconds. If it exceeds this time, the call is closed and classified as Dropped (If, on the other hand, within the 3 seconds the customer drops the call, this is traced as Abandoned).

  • Agent Timeout: How long in seconds to ring an agent’s device. If this parameter is set, every time a timeout is triggered, the call after the configured seconds switches from an agent to the next one


Scenario:




Power Dialing

How it works

This method is similar to progressive dialing but it works as a call multiplier. Calls are generated according to a defined power level, i.e. the number of contacts to call for each available agent. The system calls before the customer and when he/she answers the call, the system switches call to queue campaign, that switch call to agent.

When is this method recommended?

This strategy is efficient when we have a non-clean contact list. This is useful when we know that on a list the % of contacts who will answer is about 25%.
For example: 25% expected answers → Power Level 4 → 4 calls made simultaneously because you think that only 1 contact will answer.

Algorithms are optimized to work with agents allocated only in one queue campaign and not optimized to work with agents allocated in several queues campaign.

We do not recommend using a Power Dialer for less than 10 agents active at the same time.


For this method you need to choose:

  • Power Level: 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.
    If in a campaign we set 5, it means that algorithm works as progressive dialing but instead of generating 1 call per agent it generates 5 calls per available agent.
    If you choose a power level with a comma, the number of made calls will be equal to the number of available agents multiplied by the power level and rounded down to the lower integer.
    Scenario: 3 available agents x 4.5 Power Level = 13.5 that  is rounded to you 13 calls.

  • 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: How long in seconds to ring an agent’s device

Ring in use with power dialing method

We recommend to not enable ring in use on queue campaign.

Scenario 1: Ring in Use NO on queue campaign - NO on phonebar or webRTC agent section
The system does not route any extra calls if agents are busy. So if for example you have 3 available agents 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.

Scenario 2: Ring in Use YES on queue campaign - YES on phonebar or webRTC agent section
The number of calls will exceed the number of available agents. All exceeding calls will be routed to agents even if they are busy. So if for example you have 3 available agents and algorithm calculates that it can make 5 calls, 3 agents start to talk with the first 3 customers and 2 extra calls could be notified to agents who could receive the second call, even if they can not answer. 

Scenario 3: Ring in Use YES on queue campaign - NO on phonebar or webRTC agent section
Calls exceeding the number of available agents will be sent by the queue campaign but automatically rejected by the WebRTC or phonebar. 

Scenario 4: Ring in Use NO on queue campaign - YES on phonebar or webRTC agent section
Calls exceeding won’t be sent by the queue campaign.


Preview

How it works
This method is not based on Asterisk queues and it is a very simple method which does not differ too much from manual dial.

The dialer selects a customer record from a call list and proposes this call to an agent (the "preview" phase), who can accept it and let the dialer starts the call or decline it. In this case, the Agent will stay on the line during the progress of the call, until the customer answers or any other event (line busy, call unanswered, and so on).
There is a Preview symbol, which agent clicks to see contacts that he/she can directly call.


When is this method recommended?
Method used when you want to give the agent the possibility to call customers directly.
It is often used in combination with other features, e.g. an agent placed on inbound queues is also placed in preview and in the absence of incoming calls, he/she may decide to make call(s) in outbound queue campaign. It is also recommended if agents should be able to prepare/read customer details before the call.


For this method you need to choose:

Choosing this method, you have only to insert Agent Timeout, how long in seconds to ring an agent’s device.

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

There isn’t ring in use on queue (because the method is not based on a queue) so you can select this option only on Agent section.


Booked Progressive


How it works
This method is not based on Asterisk queues and the outbound dialer will book an agent (the first available in the queue and he/she doesn't receive other calls from the queues he/she belongs to) before starting the call. The system calls the agent first and then the customer. 
This method avoids the risk of abandoned calls, because the call is immediately associated with agent.
System shows contact preview and agent clicks to start call.

When is this method recommended?
This method is recommended when you want to be sure that the called customer is managed by an agent, because he/she is allocated for this customer before his answer. 

For this method you need to choose:
You have to indicate:

  • 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).

 

Editing the campaign on queue section, you have to indicate strategy, choosing among Round Robin Memory and Round Robin:

  • Round Robin Memory (recommended): if you have 5 agents in the queue system takes 1°, then 2°, then 3°. It keeps in memory the last agent contacted and calls the one after the previous one.

  • Round Robin starts always from the first agent

Ring in use with booked progressive method

There isn’t ring in use on queue so you can select this option only on Agent section (phonebar or webRTC).
In this case algorithm always generates number of calls equal to number of available agents, never extra calls.


Predictive


How it works
In this method the dialer uses the predictive interval to gather statistics about the calls and predicts the number of contacts to call that optimizes the Predictive Optimization, so the factor used to optimize the predictive algorithm, that can be Drop Rate or Agent busy factor (described below).
This system starts by working in progressive method (1 call for 1 agent), after enough time for the algorithm to understand how calls are handled, the algorithm collects real data statistics on how calls perform (number of real connections, call length) and efficiency increases.


When is this method recommended?

This method is designed to be more efficient than progressive (which is based on the number of agents available at that time), whereas predictive makes predictions by indicating, for example, that 300 calls can be made in 10 minutes.

With more than 30 agents, predictive method achieves a higher busy factor than with progressive method.

Algorithms are optimized to work with agents allocated only in one queue campaign and not optimized to work with agents allocated in several queues campaign.

For this method you need to choose:

With this method you have to choose among 2 Predictive Optimization:

  • Drop rate: is the number of dropped calls per total number of generated calls. Low predictive optimization percentage will minimize the number of dropped calls. The abandonment rate should be maintained an admissible level, while maximizing the agent's busy factor.

  • Agent busy factor: is concerned with agents idle time. High predictive optimization percentage will maximize agents working time. The agents' busy factor is maintained at an admissible level while the abandonment ratio is a low as possible.

For this dialing method you need to set the following parameters (change default only if you are expert about predictive dialer algorithms):

  • Predictive Optimization Percentage: percentage based on the selected predictive optimization factor (the range is between 1-95). 

    • With drop rate method by default the system indicates 3% of drop rate because in some states, regulations stipulate that the daily % of dropped calls must not exceed this percentage.

    • With agent busy factor method, algorithm calculates number of calls that should suit % of agent busy factor.
      If you indicate 70%, it doesn't mean that the agent's busy factor will be 70%, but that a prediction is made indicating the number of calls that could satisfy this 70%.

  • Predictive Interval: Time interval in minutes to be considered by the predictive algorithm to calculatedata collection amount of calls to generate for optimizing the predictive optimization factor Realtime  (by default 10minutes)

  • Max Concurrent Calls: the maximum number of concurrent calls that will be originated by the dialer for this campaign (where 0=unlimited calls)

  • Queue Timeout: time in seconds the dialer waits for a call in the queue to be answered before dropping it

  • Agent Timeout: How long in seconds to ring an agent’s device

Based on the inputs you select, the system gives a prediction output with the number of calls to be made in a certain interval.



Ring in use with predictive method

We recommend to not enable ring in use on queue campaign.

If you activate Ring in use on queue campaign, all exceeding calls will be notified to the agents.

Agent Availability Thresholds

When the Supervisor starts the predictive campaign, in a first time-window the campaign is started using a progressive typology. After the first time-window, the dialer will use the call statistics gathered during the first time-window to calculate the number of calls per second to be made in the next time interval. Once the second interval is finished, the predictive will have more and more data on which to set the prediction for the next time intervals.

In some cases, the Supervisor may wish to monitor the available Agents anyway and to force the re-calculation of the prediction. This may happen when there are many Agents available and few calls made per second or when there are few Agents available and many calls made per second.

To find a solution to the problem, two predictive thresholds (minimum and maximum) have been defined and it’s possible to define them in Advanced section of a predictive queue campaign. Here you can set min and max % (from 1 to 100)


To better explain these functions, let us suppose that in a normal working day there is a pause period in which many Agents disconnect simultaneously from Connectel. If the predictive had calculated a certain number of calls per second, you risk dropping a certain percentage of calls, until the next time-interval is triggered.

Using the Min Threshold percentage parameter, the Supervisor can configure when the dialer has to recalculate the prediction, in the case of Agents no longer available with respect to the previous interval.

What has been explained so far also applies to the Max Threshold percentage value, but in this case the parameter refers to when the number of available Agents connected to Connectel is greater than the available Agents present in the previous interval.
Scenario with Min Threshold:

Predictive interval of 10 minutes: system starts first interval with progressive method to collect data.
Then prediction is made: 20 agents → output of 300 calls, so from minute 10 to 20, dialer will make 300 calls.
At minute 20 calculation remains the same because min threshold is not triggered: 15 agents → output of 300 calls 

Consider instead the case where at minute 15 the agents become 5: min threshold is triggered and re-calculation is forced to avoid losing a certain percentage of calls by having a smaller number of expected agents

Scenario with Max Threshold:

Predictive interval of 10 minutes: system starts first interval with progressive method to collect data.
Then prediction is made: 20 agents → output of 300 calls, so from minute 10 to 20, dialer will make 300 calls.
At minute 20 calculation remains the same because max threshold is not triggered: 25 agents → output of 300 calls 

Consider instead the case where at minute 15 the agents become 35: max threshold is triggered and re-calculation is forced: having more agents available than planned it’s possible to increase the number of calls

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article