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. |
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. |
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. |
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. |
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. To make valid predictions, the contact center must have more than 30 agents. Various simulations have shown that a higher occupancy factor can be achieved with this method than with progressive. 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. |
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
Info |
---|
You can change the chosen method and its settings editing the Queue Campaign (section Campaign) |