ICTBroadcast released predictive dialing support in year 2019 and it was needed to efficiently use the broadcasting and communications technologies , With predictive dialing mode set, ICTBroadcast automatically predict and dial required number of concurrent calls to engage available and active agents
In this document we have discussed, how predictive dialing works in ICTBroadcast also what parameters are important to predict number of calls to be generated at any time,
While implementing predictive behavior we faced two question.
How many channels / calls needed ? and when these channels need to be dialed ? as It is required that whenever any agent got free, there will be a call waiting for his attention !
To answer above questions and to conclude a final algorithm we have divided this post into following sections
Concerned Entities The entities that algorithm can utilize.
Dialing Factors Factors which can decide campaign speed
Target Handles Variable which are responsible to control campaign pace
Required Statistics The statistic or variables which are required to conclude target handles.
Design Final design / algorithm for predictive dialing
Concerned Entities
We have to monitor following entities to predict active number of calls
Campaign / Queue
Agent campaigns can have one queue per campaign, all statistic will be collected and account for queues.
Active Agents
No of active agents, Available to campaign / queue at given time
Active Contacts / Calls
The 3rd parameter is total number of outgoing, in queue and in service calls.
Dialing Factors
Using following factors we can decided either dialer need to increase / decrease the required number of concurrent
channels.
Limit factors
“”Active agents””
“”Active channels””
“”Calls in Queue””
“”Average Handled”” (talk + hold + wrapup) time
Boost factors
Low ASR
Free Agents
Average Call Setup time
Average Abandoned time
Custom factors
Desired queue time
Acceptable Abandoned ratio
Target handles
We can control a campaign speed or concurrent number of calls by following
Existing handlers
Normally ICTBroadcast use the following two parameters for campaigns to control dialing speed of related campaign
Channel Auto: Total number of channels assigned to campaign
Channel Offset: Difference of channels, when user want to increase or decrease channels from dashboard GUI,
further this parameter is also used to reduce number of concurrent when balance is not sufficient to maintain a high
number of concurrent channels.
New handlers
We can add / replace above handling parameters in campaigns statistics with following agent related predictive parameters
Agent Auto: Total number of active agents in a campaign at any given time
Agent Offset: Additional required channels, Which ICTBroadcast has to dial to address low ASR issue. to kill the call
setup time etc …
Required Statistics
As mentioned above, we need two additional parameter to control number of concurrent channels, here are the details of
sub parameter which are required before, we can determine actual value of above mentioned parameters.
Agent Auto
We use no of active agent as agent auto, without any modifications.
Agent Offset
It will be a bit complex and require all following sub parameters to calculate its value
Average setup time: Average time required to dial and get call answered (i.e ring time)
Average handle time: Average talk time with agents including hold time and wrap-up time
Average Success Rate (ASR): Success rate i.e no of rejected, busy calls vs no of answered calls
And
Calls in setup: Current number of ringing calls or calls in setup
Total active calls: Total active calls
Available Agents: Total number of agents currently logged in and handling or available for calls
Free Agents: Logged agents which are free to take new calls
Anticipated Agents: Agent in handle mode, which are about to free, see
current handle time + average setup time >= Average handle time
And also needed to keep agent offset under an upper limit
Channel Auto: number of channels allocated to campaign
Channel Offset: number of additional or fewer calls, as per user or system desecration