The rise and rise of computer telephony integration (CTI) has created technological shifts, some of which have had a profound effect on the way outbound dialing is done. One that we get asked about a lot is soft dialing. So here is our own quick view of what this is, and what it means to users.
The automated dialing industry for managing outbound calls began in the days when standard switches and ACDs couldn't talk to software applications. Nor were they able to cope with the detection mechanisms required to filter out live calls for agents. So proprietary systems were developed that were able to do dialing, switching, detection and manage calling lists, all in one product bundle. Such systems still command a major share of the market.
Then came CTI, with the switch manufacturers and the software guys all clamoring to talk to each other. For our purposes, the essence of this is that we are gradually reaching a point where any software application can be engineered to talk to a switch and instruct it what to do, when to dial, how to route a call and so on. A number of companies are vying to set standards.
At the same time, the network providers have been busy rolling out ISDN (Integrated Systems Digital Network). When properly implemented, ISDN filters out all busies and other telco call outcomes, giving appropriate reason codes, and only live calls and machines get to the ACD.
So at a stroke, or almost, the scene is set for switches and their ACD successors to take over the world of automated outbound dialing. But there are a couple of provisos:
The bright CTI future promised is still not quite there. Depending on the dialing platform you have in mind, the task of CTI-enabling a software application can still be a daunting one, and a defining feature of success this market, is in-house CTI skills.
The second proviso relates to management of the call outcomes put through to the ACD. Some ACDs, do not have the means to distinguish live voice from faxes, modems and answering machines. Unless and until they do, you may want to add a 'detection server' (essentially a PC with answering machine detection capability, coupled into a fast port on the ACD, to listen to the connects) to your call center network, if machines are a significant proportion of these call outcomes, and screening them out is a must for you.
But consider this. If you are dialing consumers, then the level of faxes and modems encountered is likely to be so low, that you will not be bothered. The level of answering machines may be high. You may want your agents to leave a message. If you don't, then think about putting in a detection server, until all the ACD manufacturers get answering machine detection into their systems. But check the highlighted topic just here first, for some sobering comment on this subject.
In any case, don't be alarmed that having your agents screen out answering machines is going to cramp your productivity. If your predictive dialer can adjust its dialing algorithms to cope with answering machines, and if your agents are quick in terminating them, then you may find that your average talk times per hour have dropped by no more than a minute or so. If you are not sure about this, use Oceanic® to simulate answering machines being detected by first the dialer, then by agents.
Note
The eagle-eyed amongst you may have spotted that when the incidence of answering machines is high, the assumptions used in both the demonstration as well as the examples, lead to much more significant differences in talk times, than suggested in the preceding paragraph. We think that most call centers can do better in detecting and terminating answering machines than shown in the demonstration and the examples, but have chosen to err on the conservative side in them. If this is an important issue for you, you should, as advised elsewhere, adapt the examples to model your own situation, and not take them as gospel.