Answering Machine Detection (AMD)

AMD is often used in an attempt to improve predictive performance. The business case for use of AMD is not clear-cut and in many cases using AMD will reduce rather than improve business performance. To get a reasoned assessment of how AMD use may affect a call center's business please discuss with your Sytel account representative.

Use of AMD does not impact the Softdial API or the simulation engine, so from an interface perspective there is no new work to integrate AMD with Softdial. When implementing AMD there are some additional challenges that need to be addressed.

Most AMD algorithms work in the same way; monitoring audio data to detect a pause after an initial greeting. This means that each and every live call is held up for not less than 3 seconds, and often 4 - 8 seconds while the DSP resources on the telephony platform attempt to figure out whether the call is an answering machine or not. This behaviour has a number of side effects:

1. The length of time between the call being placed and the call being classified is increased by an average of 4-5 seconds. This negates performance benefits brought about by screening answering machines except in cases where the number of answering machines is several times that of live respondents.
2. Due to the increased amount of time spent classifying calls, trunk provisioning requirements increase slightly over non-AMD environments.
3. Compliance with local legislation. A well-tuned AMD algorithm will detect answering machines correctly 85% of the time. 15% of the time answering machines will be put through to agents. The result of this is that the AMD algorithm will mis-classify live calls as answering machines in 15% of cases. This is a 15% abandon rate on top of the number of calls Softdial CallGem™ is allowed to abandon; use of AMD in legislatures where abandon rate is constrained to 3% or 5% will place the end-user in a situation where they do not comply with legislation.

Clearly AMD should only be used in environments where there is a strong business case for its use. Where AMD use is a requirement, we recommend taking the following actions to ensure the best possible results:

• With most AMD implementations there are a range of tuning parameters that can be set. Gaining an understanding of how these work and tuning the AMD algorithm is key to successful implementation. We suggest running test campaigns against employee's home numbers (where some employees have answering machines) as a good way to experiment with parameter settings.
• In order to perform inband signal detection effectively, including Answer Machine Detection, media must be delivered to the call originator as soon as the call is proceeding. In a VoIP environment this means that the carrier must deliver 'early media'. In addition, voice media should ideally be delivered using an uncompressed (typically G.711) codec.
• It is possible to perform media processing on compressed audio, but this involves re-inflation of the audio stream and loss of resolution, which is not ideal. In circumstances where the bearer network is delivering media using G.729 or another low-bandwidth codec, carrier compliance with RFC2833 must be undertaken to ensure the carrier equipment reliably converts inband audio to out-of-band signalling before compressing the audio stream.
• Agree realistic goals with end-users of the technology; AMD is an imprecise technology. The industry has been misled by claims from some vendors that close to 100% detection is possible.
• Have a failure strategy. When using AMD you have to expect that on occasions answering machines will be passed to agents. The agent desktop application should have a means for the agent to kill the call quickly and classify it as answering machine.
• Capacity planning. AMD results in a slight increase in trunk usage. Sytel's planning tool, Oceanic®, can be used to plan trunk capacity for AMD.