For each queue, you can choose among the following Outbound Dialer Methods, so strategies to generate calls:
Progressive Dialing
How it works | When this method is recommended |
|---|---|
The outbound dialer will generate one call as soon as there is an available agent in the queue.  | This method is recommended when there are fewer than 30 agents. Algorithms are optimised to work with agents allocated only in one queue campaign and not optimised to work with agents allocated in several queues campaign. |
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 numberQueue 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:
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 We recommend to not enable ring in use on queue campaign. If you activate Ring in use both on queue campaign and on phonebar or webRTC agent section, the algorithm checks number of available agents. If for example you have 5 agents and they are all available, the algorithm generates 5 calls (1 per agent). After that, no more calls are generated, because the algorithm does not create more calls than the number of agents it finds available. Other calls can arrive, only when an agent calls an other agent directly or if conditions external to the dialer occur. |
Power Dialing
How it works | When this method is recommended |
|---|---|
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 system calls before the customer and when he/she answers the call, the system switches call to queue campaign, that switch call to agent. | 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%. Algorithms are optimised to work with agents allocated only in one queue campaign and not optimised to work with agents allocated in several queues campaign. |
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
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 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 Scenario 2: Ring in Use YES on queue campaign - YES on phonebar or webRTC agent section Scenario 3: Ring in Use YES on queue campaign - NO on phonebar or webRTC agent section Scenario 4: Ring in Use NO on queue campaign - YES on phonebar or webRTC agent section |
Preview Dialing
How it works | When this method is recommended |
|---|---|
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). |
  | Method used when you want to give the agent the possibility to call customers directly. |
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 ( phonebar or webRTC). |
Booked Progressive Dialing
How it works | When this method is recommended |
|---|---|
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 to start the call. In this way System calls before the agent and then customer.  | 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. |
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
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 There isn’t ring in use on queue so you can select this option only on Agent section (phonebar or webRTC). |
Predictive Dialing
How it works | When this method is recommended |
|---|---|
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, algorithm collects real data statistics on how calls go (number of real connections, call length) and efficiency increases.  | 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 optimised to work with agents allocated only in one queue campaign and not optimised to work with agents allocated in several queues campaign. |
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.
If you need to modify other parameters of a queue campaign, you can explore here documentation about edit section.
Scenario Predictive Optimisation with Drop Rate
When Predictive is activated you indicate a predictive interval, so when it starts, for 10 minutes it begins with a progressive method because it has to collect data and track call trends (number of calls, calls duration, number of agents).
In the next 10 minutes it processes this data and makes a prediction based on the drop rate optimisation factor: with this parameter it must respect predictive optimization percentage in that interval (If drop rate is e.g. 3%, dropped calls in the 10 minute interval must not exceed that %).
For example elaborated data inform that in the previous 10 minutes there were 20 agents, so prediction calculates to make 300 calls in the next 10 minutes.
On 300 calls generated, 100 customers answer: if more than 3 out of 100 calls dropped, a check is triggered which warns that the algorithm has exceeded the daily % of these calls and method returns to progressive.
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. |
| Info |
|---|
You can change the chosen method and its settings editing the Queue Campaign (section Campaign) |
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 XCALLY. 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 XCALLY 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
