Dialers v4 EN

Owned by Daniel Olivera (Unlicensed)
Jan 21, 2016
21 min read

 

 

Voice

 

 

Config variables

 

  • Dialer type: PowerDialer, VoiceBroadCast, Progressive (with assignation by agent), Predictive (at least 50 agents)

  • Name: The Dialers name. Any name can be used for VoiceBroadcast. For PowerDialer and Predictive an incoming campaign must be selected and for Progressive an outbound campaign must be selected.

  • Enabled: If it is active.

  • Dial string: It is what is used to make the call. For example: DAHDI/G1/ or SIP/CARRIER/

  • Context: It is the context for which the dialer will enter. For the VoiceBroadCast, PowerDialer and Predictive, is the context where a call will enter, connected with a client and matches with a workflow. In Progressive is the context to which the call is made to the client and connected to the Agent. (Already exists preassembled Contexts, each with the Dialers name)

  • Max: Maximum number of simultaneous calls

  • Time between calls: Is the waited time between one call and another. The idea is tat for example if I take 100 channels to dial and the server can not handle so many requests at the same time, we put a time between calls, for example 300 ms. Usually it is set on 0, if it is set on -1 in PowerDialer, executes overdialed to have mor agentes busy by statistical formula.

  • Timeout: Maximum waiting time to call a destination or in Progressive to try to contact an Agent.

  • Retry: Maximum ammount of calls to a number on the base. In Progressive to try to contact an Agent.

  • Audios: Audio or Audio concatenation (with &) to be sent to the workflow, usefull for VoiceBroadcast.

  • Callerid: Number that the call has on exit.

  • AMD: If the Answering Machine Detection is active, this variable arrives ${am} on 1 or 0 and it is possible to use the amd activity to hangup the Voice Mail calls.

  • DNCR: Do Not Call Registry, allows to verify if the BlackList blocks the registry.

  • Variables: All that is wanted to be sent to the Workflow.

     

 

Process

The system starts according to the created scheduler.

When starting, the system creates a task for each Dialer defined in the system, the same start and end according to the scheduler they have. All values can be seen on the Monitoring Dashboard in real time for that dialer.

Two dashboards can be seen that indicates the ammount of processed and not processed calls as well as the nuber of agents on their respective states, also a there is a real time graph that shows  the total of active calls, busy agents and calls that are being dialed.

Note: In some occasions it is possible to see on the graph that the ammount of busy agents is greater than the total as well as viewing the dialing with a negative value. This happens when the campaign makes manual calls or when it has incomming calls that are not from the dialer, anyways the graphs show the evolution of the dialer.

It is possible at any time to stop or turn on again the campaign manually and upload new lists or black list registries, it is also possible to download the lists of the dialer by pressing the lists button located on the right upper corner of the screen.

The task is executed, the task is the responsible for making the calls obtained from the calls spool (calls_spool table), this are obtained according to the dialer type and are dialed according to the dial string of the same (it can be by TDM or VOIP), note that it will only work on Digital lines, VOIP or Analogics with Disconnect Supervision (inverted polarity). Once the call is executed, its status will change. Calls are only obtained from the active list.

 

SPOOL

 

CAMPAIGN: Name of the dialer for the contact

DESTINATION: Contact telephone number

STATUS: Status of the contact

  • STATUS: 0 - PROCESSING (it is dialing)

  • STATUS: 1 - TO PROCESS (it is on the spool ready to be processed, are the ones taken by the dialer)

  • STATUS: 3 - BLOCKED (bloqued by DNCR, it will be deleted from the spool at the daily maintenance job)

DATA: values given to the workflow to be able to use.

ALTERNATIVES: alternative numbers for the contact separated by :

RETRIES: 0 initially, > 0 amount of retries for that number

CONTACT: auto-generated to differentiate the contact

DIALERBASE: name of the uploaded dialers base, it has name plus the uploaded date.

PRIORITY: 9999. to 1, initially all are inserted with a high number, but by reasons of the calls scheduler of the dialer, calls will be inserted with 1 to be executed immediately while the dialer is active. If it is required to give priorities to others, it is possible to insert them with intermediate values.

AGENTPHONE: For Progressive dialer, to which agent goes each contact.

The calls are deleted from the spool if they are answered or exceed the amount of retries defined by the dialer.

 

If the system could process the call, it is deleted from the table, if it was occupied or no answer or if there where no channels, the call is retried, increasing retry by 1, this is to not be taken immediately and others will be processed before retrying it.

It is should be noted that that between call and call, the TBC time in milliseconds is waiting, which is usually 0 (no delay). If the server can not hold and/or there are a lot of simultaneous channels, it is better to put the delay in for example 300 ms so that if there are a lot of calls, those are not generated at once and be too fast for the system to process.

 

It is important not to overlap a lot of channels, if we have 30 channels and have 2 campaigns at the same time with a maximum of 20 channels, it is likely to result in dialer errors allowing to repeat some calls. Also when having more than 1 campaign, for a better performance it is a good idea to leave 1 pivot channel, since being an asynchronous system based on events, it is possible that at some millisecond it is dialing on other campaigns and the system does not have info that it is really active occupying an channel, therefore in border cases it is possible to jump a campaign, anyways if it jumps and was not possible for the system to create a channel becase there are not, this will be processed later when the existent in the spool are completed as it will have one more retry.

Within the callerid (name) it is the VoiceBroadCast:Campaign:Dial number, this allows the tracking the system events to know how many calls are active by campaign and allows to re-insert calls in the spool that could not reach destination.

 

Contacts upload

CSV file that has: campaign, telephon number, status, data. The correct format is MSDOS CSV (separated by ;  and line break \n)

The dial order is the excel order, the only thing that varies is that the uploaded ones go to the end, while the ones with high priority or scheduled will go first.

 

 

Base.csv

 

campaign

telephone

data

alternative numbers

priority

agentphonev(Progressive)

campaign

telephone

data

alternative numbers

priority

agentphonev(Progressive)

test1

098344484

variable1=valor1:variable2=valor2

099111111:099121212

9999

1001

 

 

Base.csv
test1;098344484;var1=val1:var2=val2;099124484:099111111;99;1001

 

 

VoiceBroadCast

 

Introduction

The VoiceBroadCast system is to make auto dialed campaigns. A database with phone numbers is uploaded  and this are sent to an IVR workflow which can be used to reproduce notifications, audios,
dynamically or statically. You can also perform automatic static or dynamic surveys, as well as according to an option, the client can be redirected to a campaign.

In this case the important thing is to set the number of channels as the VoiceBroadCast use every possible channel most of the time.

 

Steps

  1. The dialer obtains the number of calls to make, if the amount is 0 it waits and asks again, else it obtains according to:

  1.  

    1. Number of available channels (Maximum - Used)

  2. The dialer obtains the contacts according to the amount and the next rules:

    1. Asks for that campaign contacts that are active for the base that has the status as Active.

    2. Or any contact that is scheduled for that campaign with maximum priority

    3. Sorting the contacts by Priority and amount of retries (Priority --> 1 is going to call first) 

  3. If DNCR (do not call registry) is active, it only let to make the call if the number is not on the black list.

  4. All variables are sent to the workflows either campaign or contact.

  5. The contact registry of the dialer is sent with retry + 1 to the business logic, this allows to create the Respooling Logic (to reinsert the contact for not being able to be reached with its alternative)

  6. If the amount of retries for a number is exceeded, then if alternative numbers exists it obtains the first and inserts it as main number, then the rest of the numbers are left as alternatives and the process starts again.

  7. The call is made

  8. If it is unattended or an error occurs, the amount of retries is increased and the contact goes to the bottom of the list to be dialed later.

  9. If it is attended, the assigned workflow is executed step by step.


 

Base.csv
test1;098344484;NOMBRE=Sebastian Gutierrez:Monto=200;099124484:099111111;9999;

 

Standard flow

 

exten=> _X.,1,Set(CHANNEL(Language)=es)exten=> _X.,2,Answer(5) exten=> _X.,3,Set(CALLERID(num)=${EXTEN}) exten=> _X.,4,Set(CALLERID(name)=${CDR(campaign)}) exten=> _X.,5,Set(__dialed=${EXTEN}) exten=> _X.,6,Set(__REALDIALED=${EXTEN}) exten=> _X.,7,Playback(${sound},) exten=> _X.,8,Read(__confirma,IVRDemoDesicion,1,,1,5) exten=> _X.,9,GotoIf($["${confirma}" = "1"]?12:10) exten=> _X.,10,GotoIf($["${confirma}" = "2"]?7:11) exten=> _X.,11,Hangup() exten=> _X.,12,GUID(__guid) exten=> _X.,13,Set(CDR(guid)=${guid}) exten=> _X.,14,Set(CDR(campaign)=${CDR(campaign)}) exten=> _X.,15,Set(MONITOR_FILENAME=${guid}) exten=> _X.,16,Set(__Ani=${EXTEN}) exten=> _X.,17,Set(CDR(type)=record) exten=> _X.,18,Set(AUDIOHOOK_INHERIT(MixMonitor)=yes) exten=> _X.,19,SipAddHeader(CTI: {"Guid": "${guid}" , "Screen": "FALSE" , "Form": "${FORM}" , "Campaign" : "${CDR(campaign)}" , "Callerid" : "${CALLERID(num)}" , "ParAndValues" : "${PARAVAL}" , "Beep" : "TRUE" , "Answer" : "TRUE" , "Dialer" : "${DIALERRECORD}"}) exten=> _X.,20,Queue(${VBQUEUE},TtKk,,,600,,,,,) exten=> _X.,21,Goto(VoiceBroadCast,${EXTEN},11) exten=> h,1,Set(HASH(rates)=${ODBC_Data(select rates.gateway\, rates.rate\, rates.cost\, rates.note FROM rates LEFT JOIN provider ON provider.name=rates.gateway WHERE provider.status = 'true' AND substring( '${EXTEN}'\, 1\, length( prefix_regexp ) ) REGEXP prefix_regexp ORDER BY length(prefix_regexp) DESC\,rates.rate ASC)}) exten=> h,2,Set(talkedminutes=${MATH(${CDR(billsec)} / 60,f)}) exten=> h,3,Set(talkedminutes=$[CEIL(${talkedminutes})]) exten=> h,4,Set(chargedbalance=${MATH(${talkedminutes} * ${HASH(rates,rate)},f)}) exten=> h,5,Set(realbalance=${MATH(${talkedminutes} * ${HASH(rates,cost)},f)}) exten=> h,6,Set(CDR(charged_balance)=${chargedbalance}) exten=> h,7,Set(CDR(real_balance)=${realbalance}) exten=> h,8,Set(CDR(note)=${HASH(rates,note)}) exten=> h,9,Set(CDR(carrier)=${HASH(rates,gateway)}) exten=> h,10,Set(CDR(userfield)=${userfield}) exten=> h,11,Set(CDR(direction)=outgoing) exten=> h,12,Set(CDR(causecode)=${HANGUPCAUSE}) exten=> h,13,Hangup()

 

Variables that reach the flow: ${sound}, ${am}, ${FORM}, ${VBQUEUE} all variables configured for that campaign. with that it is possible to design, instead of a simple BroadCast flow, IVRs where automatic surveys are generated automatically.

 

Progressive dialers

Introduction

 

In this case, this dialer is one step below regarding PowerDialer or Predictive to maximum automation, but we are still on a system of purely automatic calls. The Progressive dialres are based on the Agents availability.

The progressive dialers, usually are very suitable for Centers with a low or moderate volume of calls, where they would not be able to collect enough information to obtain reliable statistics.

Basically it calls the agent and when it answers the call is made, this makes that many attempts could be busy, wrong number, etc using time from the agent. The workflow that is used is the outbound, that is why we use outbound campaigns on Progressive and not inbound (There is not queue handling but it exists the wrapup concept) . 

The contacts have Agents properties, this means that each contact is asociated to a phone number of an Agent which is going to have that contact.

 

Steps

  1. The dialer obtains the amount of calls to make, if it is 0 waits and asks again, else it obtains according to:

    1. Amount of available Agents that are not in wrapup

  2. This dialer obtains the contacts according to the quantity and the next rules:

    1. Asks for that campaign, contacts that are active, for the base that is set as active but for the agents that are available, one for each.

    2. Or any contact that is scheduled for that campaign with max priority, while the agent is active.

    3. Sorting the contacts by priority or amount of retries (Priority --> 1 is going to call first)

  3. If DNCR (do not call registry) is active, it only let to make the call if the number is not on the black list.

  4. All variables are sent to the workflows either campaign or contact.

  5. The contact registry of the dialer is sent with retry + 1 to the business logic, this allows to create the Respooling Logic (to reinsert the contact for not being able to be reached)

  6. If the amount of retries for a number is exceeded, then if alternative numbers exists it obtains the first and it is inserted as main number, then the rest of the numbers are left as alternatives and the process starts again.

  7. If it is unattended or an error occurs, the amount of retries is increased and the contact goes to the bottom of the list to be dialed later.

  8. The call is made to the agent, if for any reason it could not be answered, it will be retried without affecting the amount of retries once the agent is available again.

  9. The contacts registry is sent to the Agent so that actions could be made based on the business login and to be able to make the Respooling for the contact if it is required (having all his data). The agent also gets data from the CTI (to be able to open forms with the data of the client to call)

 

 

Base.csv

 

 

Standard flow

 

PowerDialers

Introduction

Unlike Progressive, the Power Dialer does not call the agent first and then makes the call, it is very similar to a Predictive but with a more basic calculation of over dial.

The first thing that the system does is to dial while exist available agents to answer calls on the campaign, for example if there are 2 agents available, it is going to make 2 calls simultaneously and until one is contacted, once a client is reached it is sent to the campaign. On the 99% of the cases the agent should be free to answer instantly. This avoids having to deliver busy or inexistent calls to the agents and deliver only the ones answered. This way of working is exactly de same on VoiceBradCast dialer, PowerDialer and Predictive, the only thing that changes is the amount of calls that are being executed.

The PowerDialer tries to have all the agents with a call with its over dial.

Steps

  1. The dialer obtains the amount of calls to make, if it is 0 waits and asks again, else it obtains according to:

    1. Normal Mode (TBC >= 0): Amount of available Agents that are not in wrapup without exceeding the max amount of channels for that campaign.

    2. OverDial Mode (TBC -1): Same as Normal Mode but with a percentage of over dial based on the statistic model (Predictive)

  2. The dialer obtains the contacts based on the amount and the next rules:

    1. Asks for that campaign, contacts that are active for the base that is set as active.

    2. Or any other contact that is scheduled for that campaign with maximum priority.

    3. Sorting the contacts by Priority and Amount of retries (Priority --> 1 is going to call first)

  3. If DNCR (do not call registry) is active only lets to make the call if its not on the black list.

  4. All  variables are sent to the Workflows, either campaign or contact.

  5. The contact registry of the dialer is sent with retry +1 to the business logic, this will allow to create the Respooling Logic (re insert the contact for not being able to be reached)

  6. If the amount of retries for that number is exceeded then, if there are alternative numbers, the first one is set as main and the rest are left as alternatives and the process starts over.

  7. The call is made

  8. If it is not answered or an error occurs, the amount of retries is increased and the contact goes to the bottom of the list to be dialed later.

  9. If it is answered and AMD is enabled then if it is MACHINE the registry is reinserted with the next alternative number unless it is the last retry of the contact. If it is HUMAN is going to the ACD to be distributed between the available agents.

  10. If it is answered and AMD is not enabled it goes straight to the ACD to the agents.

  11. The contact registry is sent to the agent so that actions could be made based on the business logic and to be able to make the Respooling of te contact if it is required (having all his data).

 

 

Base.csv

 

Standard flow

 

 

Predictive Dialer

Introduction

The Predictive dialers behavior is based on phone numbers data bases, and they do it as their name says, on a "predictive" way.

This means that comes into play an algorithm based underlyingly on statistics strategies, which take multiple variables from the Call Center and calculate various factors to be able to put the Agents in contact with the contact numbers in the most efficient possible way.

By general rule, the main utility and vantage of the Predictive dialers resides on the volume of calls from the Centers in which are based on, given that they are grounded on statistics techniques, their most reliability redounds on the Law of Big Numbers. This is why, in small Call Centers it is little recommended for its base behavior. 


Essentially, the conceptual idea behind the predictive dialers is:

  • First the ideal time to make calls to clients must be calculated using various statistics strategies, which includes:

    • Calculate the average time between each call that result in success, and each call that fails.

    • Calculate the average proportion of calls that result in success and failure and with that it is weighted an average estimated time for all calls in general.

    • Use other factors that affect the times, such as average preparation time to accept another call from each agent and Wrapup

 

The more sophisticated the algorithm is, the better in general terms the Predictive Dialer will be. In fact this is one of the key factors that will determine its success in the future. A lot of predictive algorithms are based on the Erlang distribution.

  • In second place, the calls are launched for the numbers stored on the data base, abiding this calculated time:

    • With calls in progress, the Predictive dialer must be able to identify any type of inconvenience where the client could not be reached, mainly for the type of tone he receives, according to the national convention of tones from his country.

    • Also it is able to detect Fax tones and other possibilities that follows some type of standards.

    • In case that an event of this kind occurs, depending on the event, the application must be able to dial the phone properly according to what happened.

    • Besides the ability to detect VoiceMail given that by general rule they are "Not available" symbols, to be able to try the call again later. The detection is relatively easy, in function of the total voice response time, since the majority of the answers of physical people use to be a simple "Hello?", while the answering machines often use long phrases.

    • At the time it receives an answered call, it is sent to the Agents queue to be answered shortly.

With this system, the agents will only lie in wait for the machine to do its work, and by general rule, they do not have the possibility to take the call if desired, this will put directly in communication with the agent.

Firstly, this method can be ideal and, if we are really in front of a quality Predictive Dialer, this premise is true. But in return we are dealing with some inconvenience that we must overcome when choosing this type of Dialers:

  • If on the interval in which the agent answers a call and the operator receives it there is no answer, it is probably that the client abandon the call. In this case most of the Predictive Dialers put the number to be called in a future, but we can generate dissatisfaction on the client.

  • If we want to use it with commercial purposes from Business to Business, it is possible to be quite inefficient, because most of Business use an IVR which is likely to prevent our Predictive Dialer from completing its purpose in good conditions.

  • As we mentioned, if we have few calls in the Center, it is possible that the statistics algorithms do not return quality numbers and so the first problem occurs, being a very inefficient system.

 

Base.csv

 

Standard flow

 

Scheduler

 

The dialers scheduler is to be able to Schedule calls and for the dialer to make them at the right moment, for this it exists a WebService of Rest type which allows to schedule the calls. It is possible to do it from Forms, Workflows or from external systems.

 

Basically the process is that exist a table where the calls are scheduler whit the necessary information.

calls_scheduler

 

calldate

campaign

destination

alternatives

agentphone

data

calldate

campaign

destination

alternatives

agentphone

data

time and date to be executed

prueba1

098344484

099111111:099121212

1001

variable1=valor1:variable2=valor2

The scheduler is located in calls_spool with priority 1 for the calls that must be executed on that minute, which is going to make the dialers to take it as soon as posible to make it. On the base it takes the name as Schedule and Date to be able to see which calls where scheduled and which should be made to be able to compare it with the calldate from CDR.

 

Web Service

REST

 

RESPOOL

The respool is given by a webservice that allows to reprocess a contact that was answered due to the business logic, it can insert a contact as it is requested with alternative numbers, priority, etc.

A registry is sent to the CTI

Dialer: Ventas->, 098344484, 1, Par1=val1:Par2=val2, 091121212:099888888, 1, 12, basetesting, 99, 1001

(campaign, destination, status, parameters and values, alternatives, retries, contactid, basename, priority, agent phone)

With this data and the next webservice, it is possible to add any type of business logic to the dialer from Forms or third-party applications. (The first alternative number arrives as primary number as it is considered that the main number was already contacted, anyways you can do a reschedule of that main number to itself)

 

REST

 

CTI

Example CTI event that arrives to the Browser.

 

LIST MANAGEMENT 

The system allows to have multiple lists for a campaign, when uploading the lists they will be inserted on that order, the first for a campaign it is marked as active, then the rest as inactive.

The supervisor can decide from the dialers dashboard, which list wants to be active, the dashboard shows the lists in the system the amount of registries that is left for each one, allowing to activate or deactivate the same and the amount of registries per agent. To visualize the amount of registries for each agent, the agents icon must be pressed on the desired list.

It is important to know that the scheduled calls are always priority, no matter what list is executing.

Once a list has ended and has 0 registries, this will be deleted from the system, an email is sent (AlertMail Configuration) noticing that the base has ended and the next uploaded base is activated automatically.

The process may delay up to 10 seconds on activating the new list if one has no registries.

The dialers will only select contacts from the active list.

 

SMS

Basically it works on a similar way to the rest of the dialers we have, it puts on memory 50 messages of state 1 from the table sms_spool sorted by income position of the same, it searches if it is on the black_list, if it is there, the sms is not sent and puts in state 3.

 

States

STATE: 0 NONE
STATE: 1 TO PROCESS
STATE: 3 BLOCKED 

campaign

destination

message

device

idm

data

campaign

destination

message

device

idm

data

prueba1

098344484

este es mi sms

Dinstar

autonumerico

datos extra

 

Base.csv

campaign

destination

message

priority

campaign

destination

message

priority

prueba1

098344484

este es mi sms

9999

Base.csv

 

WebService

Sending an sms

 

Scheduler

The SMS dialers scheduler is to be able to schedule SMS and that the dialer makes it on the right moment, for this it exists a WebService of REST type that allows to schedule the same, it is possible to do it from Forms, Workflows or from external systems.+

 

Basically the process is that exists a table where all scheduled calls are, with all the relevant information.

sms_scheduler

calldate

campaign

destination

data

calldate

campaign

destination

data

time and date that it is wanted to be executed

prueba1

098344484

The message

 

The scheduler is located on the sms_spool with a priority of 1 for the sms that needs to be executed on that minute, which is going to do that the dialers take it as soon as possible to send the message, it takes the base name Schedule and the Date to be able to see the sms that are scheduled and when they should be made to be able to compare with the dateprocessed from sms_repo

 

Schedule SMS

 

 

Formatting from excel to CSV

It is needed to be changed firstly the delimit option inside the control panel > Clock, Language and Region options > Change date, time or numers format.

 

1) Change date,time or number formats

 

2) Additional settings...

 

3)We change the list separator combo so it shows a semicolon.

Apply and close.

 

4) BASE CREATION

Necessarily we will have to insert a row at the beggining of all our bases independently of the dialer type that we will use, so as the time of exporting to csv, it is guided by the heads we have whether there are 5 or 6 in total

 

4) We are headed to file>save as

We select that the filed type is CSV (MS-DOS)

 

5) Right click to the generated file, choose edit to visualize it on CSV mode and check that it is exported correctly.

 

6) This is the generated file. Erease the first line completely and save again.

7) Finally the file is ready to be uploaded to uContact

*We can see on line 3 and 5 that if one of the fields is empty, the delimiter is going to generate the relevant commas so that the base is uploaded anyways.

*Also we can see that at the end of the line at the 9999 a comma is inserted, creating an aditional field to be consistent to the bases requeriments to be uploaded to uContact correctly.

 

CLARIFICATION

Suposse we have a base without alternative numbers or priority.

 

Without those fields this would be the resulting CSV after making the import.

We proceed to delete the first line, and the optimum result would be: