Talk To Us!
Contact centre technologies – Issue three
Hello, from Aculab call central.
In this post, the third of these, I’ll be taking a closer look at the technology used in contact centres. If you’ve got a question, you’re welcome to post it below, in the comments section.
Diallers – how and why
In the previous post, I introduced predictive diallers, with the ‘hows’ and ‘whys’ of using them.
Diallers are used to increase productivity by predicting the number of calls that need to be generated to ensure that a real person on a call can always be connected to an agent or account representative.
That provides the agent with a steady flow of live contacts and increases h[is/er] ability to get a payment or a promise-to-pay, or whatever other appropriate result is desired.
In fact, with outbound IVR, you might not wish to connect to an agent; merely wish to play a recorded message to a real subscriber rather than their answering machine. But that’s a thought for another post.
Detection functions
We met call progress analysis (CPA) in an earlier post as a means of screening no-answers, busy signals and disconnects, in order to present only live speakers to agents.
CPA takes place as the outbound call is being established (the pre-connect phase) and as it’s being answered (the post-connect phase).
Essentially, CPA employs a number of detection functions – telephony resources or media processing firmware and algorithms typically provided by DSP boards or host media processing (HMP) software – which listen on the line and determine what is happening.
Proceeding in an orderly manner
Those telephony resource functions detect information from the telephone network, such as dual-tone multi-frequency (DTMF) signals, used to enter a PIN, for example, and what are known as call progress tones. That latter includes ringing, busy/engaged, voicemail, special information tones (SIT) or ‘triple tones’, and fax tones. And, in addition to all that, there are ‘caller ring-back tones’ (CRBT), which just might be music file, instead of ringing.
Answering the call
Also mentioned previously was answering machine detection (AMD), which involves telephony resource algorithms that detect the frequency, noise gate and energy of the audio signal. By doing so, the firmware attempts to distinguish whether the call is answered by a human, or if a voicemail or answering machine greeting is being presented on the line.
Unfortunately, there’s no BS detector – or expletive detector.
What if…
Other software, associated with the telephony line protocol in use, provides complete cause code functionality for non-connected or disconnected calls, which is useful for statistical analysis and, of course, to direct the dialler application’s behaviour during operation.
So now we know
So now we know all we want or need to know about the call – before it’s passed to an IVR or to an agent. But there are implications to consider, which I’ll look into in the next post. Don’t miss it. Bye!
- Joeb Logger
