Francis,
Please read and employ Mike's suggestions. I'm just going to add a little "explanation" to what may be happening. Based on your description, this is an agent-based campaign doing progressive or predictive dialing. In that case, POM will detect that the call has been answered and do various things based on your settings. Normally, you'd have AMD on (not Background AMD in most cases) to determine whether it is an Answer Human case or an Answer Machine case. The process of determining that the "voice" is from an answering device rather than a person can take a bit of time -- it isn't instantaneous nor is it 100% accurate. The longer you allow the AMD algorithm to run, the more accurate it can be but there can be other consequences. Usually there is a Nuisance timer that will deliver the call to an available agent -- typically 2 sec -- even if AMD has NOT returned a decision. This ensures that your campaign can meet regulatory compliance and have fewer abandons before an agent is connected to handle the call, but this also will deliver some calls to agents that subsequently prove to be answering devices. There is NO "cure" for this -- if the AMD takes longer than the Nuisance timer, agents WILL get those calls even if the agent then determines it was an answering device. Either you set a longer Nuisance timer to have fewer of these or you tolerate it. Setting a longer Nuisance timer may violate some regulatory compliance. Pick your poison.
The behavior you report would appear to result from calls where the AMD didn't resolve to Answer Machine soon enough and the call was delivered to an agent. However, you also appear to have Background AMD turned ON. That lets the AMD algorithm continue even after the call was delivered to an agent. If POM determines that "Oh, this isn't a person; it's an answering device," then it will take the action that you've specified when you configured Background AMD. As Mike pointed out that can be disconnect, rip the call away from the agent and play a message, or leave the call connected to an agent. You appear to have this set to Disconnect, so the called party and the agent are both disconnected and the call leg to the called party is dropped.
Despite what your customer wants POM to do, there is no way to ensure that every Answer Machine condition (regardless how long it takes to get to that determination) is simply dropped without being connected to an agent. I assume that your Answer Machine action in your strategy just disconnects. With Background AMD on and Disconnect set, the agents will have these answering device calls "ripped away" from them and disconnected as soon as POM makes this determination. You probably already have the "best" configuration to minimize "wasted" agent time and the behavior you report is what I would expect to happen. However, from a called party experience perspective and an agent experience perspective, this may not be desirable. Since AMD is fallible, some people who answer are currently getting your Answer Machine treatment (e.g. disconnect) just as some agents are getting answering device calls that are ripped away and disconnected. Agents typically find having calls ripped away either to leave a message or to be disconnected dissatisfying even if it may "waste less time" than simply having the agent handle these cases by disconnecting or leaving the desired message.
I'd recommend your customer listen to this explanation and decide what is in their best business practice interest. There is little that can be done when a person answered but POM thought it was an answering device. Those called parties will just be hung up on unless some message is left. Realize that this would be a person hearing a message intended for an answering device in the case where POM's AMD got it wrong -- not optimal, but not quite as rude. For the calls delivered to an agent but Background AMD made a delayed decision, agents may find it more acceptable to manually disconnect rather than having the call ripped away.
Hope this explanation helps.
|