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. If the call is dropped, the dialer will not recall the contact in this queue campaign (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:
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
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
This 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 and calls contacts directly from phonebar.
Here you have only to insert Agent Timeout, how long in seconds to ring an agent’s device.
Booked Progressive Dialing
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 avoids the risk of abandoned calls, because the call is immediately associated with agent.
System shows contact preview and agent clicks to start call.
Here 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).
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.  | To make valid predictions, the contact center must have at least 20-25 operators. 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.
= - DROPPED CALLSAgent 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
= + AGENT'S OCCUPANCY
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.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
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 (600sec in total so 2calls/second).
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.
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.
Please note that in the prediction calculation the dialer does not take into account the number of available Agents: the calculation is based instead on information such as the average call time, the average call waiting time, and so on.
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.
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.
You can change the chosen method and its settings editing the Queue Campaign (section Campaign)
