Outbound List Management
Every outbound campaign requires a list of contacts to dial against before it can start making calls. This customer database (of records to contact, a.k.a. calling list, campaign table) managed by the CRM application may contain many thousands of client records, each containing a contact number or media address.
Managing your customer database is a complex business;
- you have a pool of respondents that you have one or more phone numbers for
- you may have rules constraining calling certain numbers to certain times of day
- you may be calling across multiple time zones
- you will have business rules that you want to introduce to recycle your data intelligently and flexibly.
This is mixed in with the need to schedule callbacks for specific agents as well as pooled callbacks.
Softdial Campaign Manager™ delivers all of this in an easy-to-manage application that your call center supervisors can understand.

Over the years of our involvement in the call center industry we've seen all sorts of practices develop for managing inventory. These have been borne out of dialer vendors' implementation of tools to manage recycling of lists.
Much of the early dialer vendor implementations of recycling have been adopted as received wisdom on best practice. Mechanisms such as manual control of recycling particular outcomes, or dialing the entire list without working any retries are practices that don't make best use of dialer resources, but are still pervasive.
The number of times customers insist on using a practice that wastes their dialer investment is saddening.
It is this (and the notion of having to import and export lists rather than work directly with a database) that led us to implement the first version of Softdial Campaign Manager™ back in 2001.
At its launch, Campaign Manager was too radical a departure from industry norms to gain wide acceptance. The intervening years have seen the design decisions we took at the turn of the millennium proven time and time again in the field.
This topic discusses those design principles and in doing so exposes some limitations of industry best-practice ideas. It also describes in detail what the inventory management options in Campaign Manager do, and why.
Regardless of this, there may be reasons why customers want Campaign Manager to behave in a way that it was not designed to operate. A significant proportion of received enhancement requests concern inventory management features that customers wish us to implement.
These requirements vary widely and often conflict, which presents us with a dilemma. We have chosen to address this by providing the means to customise Campaign Manager through its published Campaign Management API.

In order to understand the more esoteric concepts in this section, some design fundamentals must first be explained.
Campaign Manager was designed to fulfil 2 tasks, namely:

Managing data flow is essentially about performing bulk fetches and caching for feeding numbers in to the dialer, and serialising database update for outcomes, retry management and line-of-business data update, whilst managing integrity of the database. This is more-or-less textbook behaviour for a transaction processing monitor. Indeed Campaign Manager implements a limited form of TP monitor that performs these activities for a prescribed view format, which
- must have a single unique identity column (primary key)
- may be formed by joining tables in whatever way the customer wants, subject to the view being update-able

The task of managing dialing inventory to maximise profitability is slightly more taxing...
There are two key elements to managing dialing inventory to maximise profitability:

This is concerned with maximising the chance of connecting to a customer on a given phone number or set of phone numbers. If we assert a value for every connect (which arises from the opportunity to sell or collect) then it follows that the optimum strategy is the one that yields the best level of contact for a given number of call attempts.
There are many variables to consider in order to come up with an optimum strategy; not least of which is the type of business the call center is engaged with. A collections house will want to deploy a strategy far different to that of a telemarketer or a market research organisation. There are some constant requirements that the inventory management scheme will need to deal with. These are:
- the ability to
- schedule a retry or a call attempt for a particular time of day
- make use of call history to select suitable (or unsuitable) times for calling
- limit contact on certain numbers to certain times of day based on various business rules (time zoning, business-hours calling of business numbers, optimum times-of-day for different types of number, customer contact preference)
- contractual requirements imposed by the customer
- legal requirements
All contractual requirements we have come across in Campaign Manager's life can be met by existing rules in Campaign Manager.
The key characteristic of these requirements is the need to schedule a call to be made (roughly) at a particular time of day. A strategy that ignores this imperative is going to yield significantly worse retry performance than one that takes account of history of contact attempts and other intelligence. Beware any strategy that says 'Dial all the numbers, then redial all the no answers, then answer machines...'. There is no scope for intelligent selection of time to call in such a model.
Let us look at some common-sense aphorisms for time-of-day calling:
- A telemarketing operation will get higher connect rates calling home numbers outside of business hours than inside business hours.
By skewing the time-of-day rules for calling home numbers, work numbers and mobiles it is possible to even out connect rates throughout the call center shift, leading to better overall performance than would be possible given normal fluctuation of connect rates during the course of a day.
- It is pointless to flog a dead horse.
By making intelligent decisions on whether a lead is 'spent' you can avoid 'flogging a dead horse' type dialing. Your retry scheme should enable you to make decisions on a number of different bases to determine whether or not it is worth retrying the customer.
- If you call somebody at the same time-of-day as you did yesterday you'll likely get the same outcome.
By scheduling retries to take place at a particular time-of-day, you get significant improvement in connect rates for retried calls.
- If you know the called party is present (because the line is busy), call them again soon.
- If you said you'd call somebody at a particular time-of-day, you get best results by honouring your promises.

Why is an issue for profitability? Let us consider a simple case.
We have a customer database with 100,000 numbers which we will dial. We will then recycle all of the no-answer and answer machine calls after the first pass through the list. There were, say, 40,000 live calls and 60,000 no-answers and answer machines.
The graph below was produced by using output from Oceanic®, the outbound workload planning tool. Oceanic® is a simulator that uses the core of the SCC dialing engine to model call center behaviour, and enables what-if scenarios to be modelled. We have made a number of assumptions:
- The outbound campaign had respondent answer profiles consistent with outsourced marketing campaigns (mean talk+wrap time of 40 seconds).
- Ring No Answer (RNA) is set at 18 seconds.
- Answer Machine Detection (AMD) is turned off.
- Network latency is typical for the North American Telephone Network.
In the simulation runs, we varied the number of agents on the campaign (the coloured lines), and the connect rate (x axis), and plotted the resulting wait time (in seconds, y axis).
Fig. 1 - Graph - Expected Performance
Two conclusions can be drawn from this graph:
- For a campaign of this type, deploying less than 20 agents gives sub-optimum performance.
- Performance degrades exponentially (i.e. increased wait times) when connect rates are lower than 25%.
Regarding point (1), there is nothing that we as a manufacturer can do about staffing levels, other than advise our customers
We can, however, configure our product to minimise the effect of point (2) above. The effect of degradation in performance relating to data quality is key to understanding why it is important to keep the dialer fed with consistent quality data.

In the simple case we outlined, the connect rate for the first pass was 40%. The connect rate for recycled data is likely to be of the order of 15%. It stands to reason – if you get an answering machine or no answer first time you call, the most likely outcome is a repeat of your original outcome.
So assuming 20 agents, the dialer, for the first 100,000 dials, will yield talk time per hour of 46 minutes and 4 seconds. It would take 20 agents a total of 578.9 agent-hours to process this first pass. For the next 60,000 dials, talk time per hour will be 41 minutes and 22 seconds. It would take 20 agents 145 agent-hours to process this second pass; so all in all, 723.9 agent-hours.
If the retries of no-answers and busies were blended in with fresh data in proportion, this would yield an overall connect rate of 30.625% over 160,000 dials. It would take 714.7 agent-hours.
So by blending in a single pass of retries you can achieve a notional saving of 9.2 agent-hours, or a 1.28% improvement in cost performance. This is not a huge amount, but the fact that recycling takes place several times compounds this saving (just like compound interest).
Let us consider the effect of recycling. When the need for repeated retry is applied as is the case in the real world, the cost performance improvement of blending retries with fresh data is compounded. If we extend our simple retry scheme to make a further 6 attempts of calls failing no answer we see some very significant degradation in connect rate:
The algorithm used to figure out the retry connect rate is a log algorithm which errs on the side of being generous, in order to make for a watertight case. We would expect a sixth retry of a no answer to have less than an 8% chance of connect in reality.
The number of agent-hours is based on an agent pool of 20. If we sum the number of agent-hours required when using simple recycling it is 1235 agent-hours.
If we merge the retries in with fresh data, we make 292733 dials for 77322 live calls, a connect rate of 26.4%. On the basis of a connect rate of 26.4% it would take 39-agent hours to process 10000 calls, or 1141 agent-hours in total.
We can now see a material difference in performance – an 8% improvement in cost performance. And this is conservative. The worse the degradation in performance on multiple passes, the larger the improvement gained by merging retries with fresh data.

A final thought on this subject: dialers are also not renowned for their ability to deal with fluctuating connect rates. SCC, with its simulation-based approach, reacts to fluctuations in connect rates as quickly as it is possible to do. Nonetheless, even SCC will perform better with a consistent set of data than one with fluctuating quality of data.
The cost argument as presented does not take into account any improvement in performance that might be gained from placing retries at a time of day when they are likely to be answered. Clearly it is better to attempt contact at times of day where success is more likely. This is not easily quantified and if vendors of right-time-to-call solutions are to be believed performance improvement will be orders of magnitude. This is apocryphal.
Our field experience tells us that in the round, by placing retries at a best time to call, the level of successful connects will be 3-5% higher for the first retry. This will have a cumulative impact on retries for the 3rd or 4th time may be 10% more effective than they otherwise might be.
On a predictive campaign, we can confidently assert that blending of retries will yield at least a 10% improvement in cost performance over simple recycling, and 15% is a realistic expectation of performance improvement.
Preview and progressive campaigns do not benefit from the smoothing of connect rates that blending of retries brings to predictive. Nonetheless, there are performance gains to be made by blending retries. Preview campaigns tend to be run where there is a greater likelihood of the called party answering, so there will be fewer retries made. When running preview, regardless of connect rate, right party contact rates tend to be around 40%. This means that a strategy that recycles non right party contacts an average of 2 times before connect will be around 6% more successful on recycled calls than simple recycling. In simple terms this equates to a cost performance improvement of not less than 4%.

A well-constructed inventory management scheme that takes account of all available intelligence to schedule retries in the mix with fresh data, will yield significantly better performance than a simple recycling strategy. Contact center cost performance for processing a given database, if retrying no-answers and answer machines 6 times, will be at least 10% better with intelligent retry management than using simple recycling techniques.
If your contact center's operating margin is currently 20% of turnover, a 10% improvement in cost performance will enable you to increase margins to 28% - effectively a 40% increase in profitability.
The scenarios described in this document underplay the value of intelligent recycling. Since we are making a commercial case this is deliberate.
The lower the initial database quality, the greater the advantage brought about by intelligent recycling. With data quality in all sectors of the contact center industry degrading, the difference in performance between simple recycling and intelligent recycling will become the major differentiator in outbound contact center performance.
In answer to all of those people who ask us for a means of simple recycling our answer is this:
“Yes we can show you how to configure Campaign Manager to do what you want...
However we'd rather you took our advice and stayed profitable.”