Group dialing

Group dialing has the same basic sample management requirements as Extension dialing. The same properties in DPM are used for dialer, dial, and call result configuration. Likewise, the same underlying sample management provider is used to get sample records to dial. The only real difference is that interviewers are associated with a group and calls are then made for the group instead of for the extension. When a group call is connected it is transferred to the interviewer who has been waiting the longest in that group.

For extension dialing, interviewer wait times can vary greatly between attempts to connect a respondent, as one request might get several no answers, while another obtains a connection first time. However, for group dialing, the wait time is effectively the average time taken to get a connected call for the group of waiting interviewers. In other words, the wait time variation should be smaller for group dialing than for extension dialing because the first connected call is given to the interviewer who has been waiting the longest.

Besides averaging out the wait time, group dialing can also reduce waiting times by predictively dialing more calls than there are waiting interviewers. Predictive dialing algorithms attempt to strike a balance between maximizing productivity (by reducing waiting times) and minimizing silent calls caused when a call is connected and there is no interviewer available to take the call.

Preview dialing is handled differently when dialing for a group of interviewers. When an interviewer requests a record, the sample management system locates the first eligible record for that interviewer and tests whether this record needs previewing. If the first eligible record needs previewing, sample management returns the record to the interviewer without dialing the number. The interviewer has time to preview the record and read the comments before returning the record either to the dialer for dialing or back to sample management. If the first eligible record does not need previewing, sample management sets the extension available for group dialing and increments the count of waiting interviewers. The record is then dialed for the group. Note that the record is unlikely to be returned to the original interviewer as it will be connected to the interviewer who has been waiting the longest.

All interviewers in a group should use the same interviewing engine whenever possible. If the engine load balancing script finds that an engine is very overloaded, it will allocate new interviews to a different interviewing engine in order to balance load. However, splitting the group in this way makes predictive dialing less efficient.

There is a separate dialing group for each combination of interviewer qualifications. Although this means there are more groups, it reduces the number of interviewers in each group which greatly simplifies the routing of calls to waiting interviewers.

Each unique set of qualifications is assigned a number which is appended to the project name to form the group name; for example, PROJ1:1.

The interviewer session engine maps interviewer qualifications to group ID numbers. New interviewer qualification groups are created as necessary when interviewers log in. The ID is passed to the dialing provider via the InterviewerQualGroup interview property.

Hook status is monitored by subscribing to the OnInfoChanged event from the extension object for each waiting interviewer.

If the extension for a waiting interviewer goes on hook, the interviewer is removed from the table of waiting interviewers and an error is returned to the interviewer. Because the number of waiting interviewers is based on the number of entries in the table of waiting interviewers, the detection of an extension going on-hook is immediately reflected in the predictive dialing algorithm.

Fail-over occurs in the same way as it does for extension dialing.

Various dialing statistics are available from the Dialing Statistics object that exists for each dialing group. These include:

▪Call attempt statistics for the last n calls and the date and time of each attempt. (n is defined by the CallAttemptHistorySize CatiParameters property, which defines the number of call attempts to hold in the history for each dialing group.)

The object also provides a number of helper methods that can be used to provide summaries of the data for call attempts and active calls.

How respondents are connected

How autodialing works

The following diagram shows how a respondent is connected for group dialing:

The diagram shows that there are three separate threads involved in group dialing.

The steps involved in group dialing are:

2 The QSamp group dialing provider adds the interviewer to the table of waiting interviewers and creates an event synchronization object for the request thread to wait on once the dial request has been queued. (Each project–dialer–group combination has its own table of waiting interviewers, for example, a table for project A, dialer D1 , group 1, and another table for project A, dialer D1, group 2. These tables are held in memory only.)

4 The group dial request is queued for the project-dialer-group combination. Since there is a dialing worker thread per project, there might be several concurrent dialing requests for different dialers and groups.

3 Based on the number of calls being dialed for the group and the number that were predicted to be dialed based on the current dialing statistics, the worker thread gets additional records from the sample management provider.

2 If the call has been connected, the sample record is added to the table of waiting interviewers for the connected extension and the waiting interviewer event is signaled. This, in turn, causes thread A to remove the waiting interviewer entry from the table and return the sample record.

▪The dialing worker thread is signaled by requests to the dial request queue. For predictive algorithms that look at the ring time of the in-dial calls, the dialing worker thread calls the predictive algorithm automatically after an n millisecond time-out.

▪The sample management providers for each project are single threaded. Calls are queued when multiple threads attempt to call GetSampleRec or ReturnSampleRec for the same project at the same time. User interface delays can occur when the GetSampleRec or ReturnSampleRec calls take longer than a few hundred milliseconds. For example, the user interface will be slow to update when a call is connected, or when the interviewer dispositions a call by selecting a call outcome.

To avoid contention on the sample management provider, separate sample management provider collections can be created for each thread. In the skeleton code, separate sample management provider collections are created:

If the same thread is used to handle requests, to retrieve new sample records, and to handle dialer dispositioned call outcomes (including call connects), consider separating the requests in order to retrieve new numbers in a separate thread.

The number of calls that should be in-dial at any one point is calculated by the project's dialing algorithm component. This is stored in DPM in the PredictScript property in SampleManagements>ProjectName>DialingPredict.

When dialing starts for the day or restarts after a break, the predictive algorithm requires some initial statistics on which to base its calculations. In other words, a certain number of call attempts need to exist in the call history before the call statistics work reliably. The details of what is required can vary between algorithms and is therefore specified in the algorithms themselves.

The StatisticsSync sample management property resets the statistics back to the start-up state. The dialing provider checks the value of this property every five seconds.

A predictive algorithm written in mrScriptBasic is supplied with UNICOM Intelligence Interviewer. This script is loaded and cached by the dialing component. You can use the DialingPredictSync sample management property to force the script to be reloaded, but this property is only checked every 60 seconds. For further information about this algorithm see Predictive dialing algorithms.

Silent calls occur when a connection is made but there is no interviewer available to take the call. You can record a message that can be played to participants when this happens. Each dialer must use the same file for every project. The file is named in DPM in the SilentCallAudioFile property in DefaultCatiProjectParameters.

UNICOM Intelligence Interviewer is able to switch between predictive and nonpredictive dialing according to the current dialing statistics. Predictive dialing takes place only while the silent calls limit has not been met. This limit is calculated as a percentage of silent calls against total connected calls, with the default limit being 3%. Once the limit has been reached, group dialing continues but over-dialing does not. The percentage of silent calls must be less than the target silent calls limit before predictive dialing can resume. The default target silent calls limit is 2.5%.

These defaults are configurable using the project's TargetPredictiveSilentCalls and MaxPredictiveSilentCalls properties. The dialing provider caches these properties in order to minimize the number of calls to DPM. The DialingSync sample management property can be used to force this property to be reloaded. It is checked every five seconds.

The DialingActivity report in the session engine displays the current predictive dialing state for each project running on that engine. An example of the report XML is as follows:

<DialingActivity EngineStartTime="2006/04/18 12:03:24"
CurrentDialers="1">
  <Project Name="museum"
     CurrentInterviewers="20"
     WaitingInterviewers="4"
     SilentCalls="2.4%">
     <Group ID="1" CurrentInterviewers="12"
        WaitingInterviewers="3"
        Mode="Predictive"
        SilentCalls="1.7%" />
     <Group ID="2" CurrentInterviewers="8">
        WaitingInterviewers="1"
        Mode="NonPredictive"
        SilentCalls="3.2%" />
  </Project>
</DialingActivity>