This topic looks at how retry rules are implemented in Softdial Campaign Manager™.
The retry rules are multi-layered, which makes for a degree of complexity that is unavoidable. In the Campaign Manager UI, we have tried to avoid exposing this complexity. However, in order to get an understanding of why Campaign Manager works as it does we will need to explore some of these complex issues.
Campaign Manager has 2 mechanisms that underpin the inventory management schemes it supports, providing the basic framework for how Campaign Manager deals with retries:
Campaign Manager has a caching mechanism that intermixes fresh data and scheduled retries, for delivery to the dialer engine. This has several implications:
Campaign Manager determines a specific time to attempt next contact based on a number of factors:
This algorithm is a Right Time To Call (RTTC) algorithm. It will be referred to in this topic as the core algorithm. It is expressed in flowchart form as follows:
These two mechanisms are fundamentally related, as explained below:
Success of RTTC depends on the system being configured to dial retries when they have been scheduled. This means by default, retries take precedence over fresh data. If fresh data is prioritised, retries that are scheduled will not get dialed at the scheduled time, and will expire and have to be rescheduled again.
The practice of dialing a list in its entirety before recycling is an outdated practice that was enforced by legacy dialer design where a list had to be imported into the dialer, worked and then exported. It is spectacularly inefficient, giving no control over the time at which a retry is attempted, and can result in large numbers of retries being scheduled and not even being cached until the list completes. The consequences of this are great performance with new data, and lousy performance on recalls once data is exhausted, thereby causing:
If this first pass through the list takes, lets say, 3 days, to complete, then by the time the first pass is done, there will be 2 days worth of retries that are already overdue. This situation in itself will leave dry periods where there is no fresh data but retries may not be scheduled until later in the day. In the event that a campaign is run and stopped before configured end-of-shift time, this also creates a glut of retries due in the time before the end of shift, that get swept into the next day.
The way to get best dialer performance is to maximise the chance of contact and to bring some stability to connect rates. A campaign that starts out with a 40% connect rate which degrades to 5% once fresh data is spent will perform far worse than one that starts out with a 25% connect rate that slowly degrades to 15%. At very low levels of live calls the dialer’s risk management is less effective; consider that a 5% connect rate means dialing 20 calls on average to get 1 live call.
By disabling RTTC and dialing the whole list up front, by the time retries are made, the likely success of those retries is reduced hugely, leading to a vicious circle of poor connect rates, and ever-more aggressive recycling of data.
With a RTTC strategy keeping connect rates for retries relatively high this prevents data churn and the need to retry a number more than 6 times.
In order to deal with the requirement to dial multiple numbers for a respondent, and cycle through these numbers in the most efficient way for a particular business need, retry strategies determine how the base algorithm is used to select...
Campaign Manager currently implements 7 retry strategies, each using the core RTTC algorithm, which seeks to answer the question 'Based on calling history and specified rules, can I retry a dial to number X, and at what time?'
Users will need to select the strategy that best meets their needs, using the options provided on the campaign configuration Database Input tab/ page via the Multiple telephone numbers button (Fig. 2):
Fig. 2 - Editing multiple telephone numbers
The options, with detailed explanation and suggested use, are:
The default mode. This will mean that all retries are performed using phone number 1 (i.e. the main number). Any other numbers in the list will be ignored.
In the case where there is only one phone number column for a respondent, this is the only viable option.
This approach dials and redials the first number until either a contact is made or a limit condition (e.g. too many no answers) is reached.
Upon reaching the limit condition, the second number is dialed and redialed until either positive contact is made or a limit condition is reached.
Note that in multiple number scenarios, it is likely that the database will have only partial data on phone numbers.
On rollover from one phone number to another, the outcome from the previous dial on the old number is used to schedule the first dial on the new number.
The settings Apply (retry management) totals to each number and Treat (retry management) totals as total for all phone numbers do not have any effect on this retry scheme.
This option helps to achieve maximum list penetration but only if the respondent is unaware that the dialer is tracking them. This option is optimum for cold-call marketing.
This approach dials the first number. If contact is made all well and good; If not the next number will be next to be dialed. Campaign Manager cycles round each of the numbers until positive contact is made or an overall retry limit is reached.
For the first pass through the set of numbers, the outcome from the previous dial is used to set retry time. For second and subsequent passes, the last outcome for the previous dial to that number is used to set the retry time.
This option helps to achieve maximum list penetration when the respondent is aware that they may be being tracked by a dialer. This option is optimum for soft collections and cold-call marketing in territories with a mature dialing industry.
This option is another modified version of Round Robin retry.
The first number is dialed; if successful, great. If not, and the outcome is one that has been defined as Not Present (typically no answer, answer machine, fax, modem - see Retry Options) then schedule the second number to be dialed immediately.
This does not result in the next call being placed instantly, due to the queuing and caching processes in Softdial Campaign Manager™ and Softdial CallGem™, but the call will be made as soon as possible.
This algorithm continues until all numbers for the respondent have been dialed once. For the second and subsequent passes, retry times are set by running the base algorithm against the last outcome for the number to be dialed. In the (unlikely) case that this yields a time in the past, the dial is scheduled for 5 minutes time.
If all of the alternate numbers have been dialed without a live outcome, the cycle will repeat after a delay defined by the last outcome delay.
Outcomes that are not defined as Not Present are treated as per the settings in Retry Options, i.e. will be retried after the defined delay for the outcome.
This option is designed to make contact with the respondent as quickly as possible, but as far as possible without compromising the need to maximise list penetration. Its primary use is in collections, where there are limits placed on the number of calls that can be made in a day to attempt to collect a debt. It may also be an optimum strategy for in-house telemarketing and customer retention programs where customers have several contact numbers.
This option behaves the same as Immediate retry of not present, except that it only makes one pass over each of the numbers for a respondent.
The logic is:
This option is often used for automated alerting of respondents either for medical alerts or public service warnings.
In certain collections environments it is either a legal or customer-mandated requirement to only make a single contact attempt for the debtor, either once, or on a given day. This option provides the best chance of making contact quickly within this constraint.
This option is similar to Immediate retry of not present using next number, with the exception that each alternate number is dialed immediately after the previous one for the first attempt only. Thereafter the retry delay settings for each outcome will be used to schedule the next attempt at each number.
From V10.7 - the next number to be dialed is determined by the precedence set for each outcome. This allows users to value a particular type of outcome more highly (for retry purposes) than other outcomes. When using this option respondent may be present outcomes such as Busy would be prioritised higher than Not Present outcomes such as Answer Machine and No Answer.
It also allows prioritisation based on cost of retry. For example, it may be more desirable to call a No Answer rather than an Answering Machine, because the call center will absorb a connection charge for answer machine calls.
This option is a modified version of Round Robin retry. Instead of making 1 call to each number before moving on to the next, the user can specify more than 1 call.
This option has 2 practical applications: