Sequential Call Transfer on no answer - can it be done

[Bhoward48]

Hello all:

 

First, thank you to anyone who takes the time to help me out. I am a volunteer at a Not-for-profit in the US in Rochester NY serving an at risk community. We are using the IVM to tend to calls after hours to reduce (or eliminate) the need for a human answering service.

 

We have purchased the software (version 3.07) in November of 2006 and have been phasing in its use. We only use the sytem when the office is closed. We have all our OGM's set up including a prompt to "Press 1" if this is an emergency need and you will be connected to a person that can help. We set up a blind transfer and that would send the call to our human operator answering service and they would screen the emergency and implement the needed actions.

 

We have now assembled a group of volunteers to screen these calls and wish to transfer the caller to the volunteers cell phone. So far so good, blind transfer works fine. The problem is that we need a "backup" in case the volunteer called doesn't pick up the call (let's say in 15 seconds) then we want to transfer to another volunteer and another, etc. I'm sure you understand.

 

The blind transfer obviously won't work here because the IVM hands off the call not knowing if answered or accepted and loses control.

 

I have tried every combination of settings under confirmed transfer and answer detect rather than blind transfer. I think I am missing something basic. I can't get either of them to work (now). At one point I got the settings so the call would transfer and ask the transfer receiptent to accept or not and then it would go to the next number. Now I have lost that ability as well. That wouldn't work well for us as a backup because what I really want is if first number doesn't answer the call in 10-15 seconds, the transfer to the second and if then fail transfer to the third, etc. The call confirmation part now plays the auto message about "This is a call from the IVM..." to the incoming caller (who knows how I made that happen )

 

I have clicked on the answer detect setting and set it for the software to do the detection but no combination seems to work. We are using a Dialogic D/21H telephony card. I assume because the blind transfer works fine that it isn't a TAPI issue or a hardware failure. However, is it possible that the hardware needs some setting change to allow "software" to control? Or is there some other "general" seeting that I am missing.

 

Thank you for helping and I am sorry I was so long winded but I wanted you to have as much information as possible.

 

Best regards,

 

Barry Howard

BHoward48@aol.com

[pythonpoole]

The first step is to understand completely what is meant by a "confirmed transfer." Although it sounds like it should be a simple check whether the call was answered or not, that is not the case with IVM. The only method of doing a confirmed transfer is to play a message to the receiving end asking if they wish to let the call go through (much like an operator would ask if you want to accept a reverse charge / collect call).

 

The way it works is if the receiving party accepts the call (by pressing 1), then the call is immediately transferred. If the receiver rejects the call, it is sent back to IVM and dealt with by the OGM (in your case, a transfer attempt to another number). And finally if IVM receives no input from the receiver, it will eventually consider the call rejected as if the caller had pressed the reject key (2).

 

Some things to note:

- It is possible to change the message audio that is played to the receiving party that asks if they wish to accept the call (see Settings->Prompts->TransferQuery)

- It is possible to define how long before a transfer is considered an automatic rejection (not answered / no response), by changing the number of times the TransferQuery is played (see Transfer Call to->Confirmed Transfer->Repeat call transfer prompt before failing), however the minimum is 5 tries. You can however keep the TransferQuery message very short (e.g. "1 to accept, 2 to reject") so that even when played 5 times, it will only take about 10 seconds or so to time-out/fail.

- It is also possible to set-up the receiving phone system to automatically accept call transfers (if you have control of the system). To do this, simply set it up to play a "1" DTMF tone on the line when calls are answered, and IVM should detect this and assume a successful, accepted transfer.

[Bhoward48]

The first step is to understand completely what is meant by a "confirmed transfer." Although it sounds like it should be a simple check whether the call was answered or not, that is not the case with IVM. The only method of doing a confirmed transfer is to play a message to the receiving end asking if they wish to let the call go through (much like an operator would ask if you want to accept a reverse charge / collect call).

 

The way it works is if the receiving party accepts the call (by pressing 1), then the call is immediately transferred. If the receiver rejects the call, it is sent back to IVM and dealt with by the OGM (in your case, a transfer attempt to another number). And finally if IVM receives no input from the receiver, it will eventually consider the call rejected as if the caller had pressed the reject key (2).

 

Some things to note:

- It is possible to change the message audio that is played to the receiving party that asks if they wish to accept the call (see Settings->Prompts->TransferQuery)

- It is possible to define how long before a transfer is considered an automatic rejection (not answered / no response), by changing the number of times the TransferQuery is played (see Transfer Call to->Confirmed Transfer->Repeat call transfer prompt before failing), however the minimum is 5 tries. You can however keep the TransferQuery message very short (e.g. "1 to accept, 2 to reject") so that even when played 5 times, it will only take about 10 seconds or so to time-out/fail.

- It is also possible to set-up the receiving phone system to automatically accept call transfers (if you have control of the system). To do this, simply set it up to play a "1" DTMF tone on the line when calls are answered, and IVM should detect this and assume a successful, accepted transfer.

 

Thanks for your help. I do believe I understand the confirm transfer as we had that working at one time. The problem I have now is that I can't get the setting to do it again. Right now when I set the transfer protocol to confirm it dials the number and the plays the message to the incoming caller rather than the person being called. What have I done wrong? I like the idea of shortening the query so the 5 attempts take only 10-12 seconds before fail as that would prevent going to voicemail, etc. If I can get the confirm part to work again I will try it.

 

Any ideas about the setting for letting the software control the hand off - like failing after 15 seconds if no answer?

 

Thanks again for your help. This volunteer work is getting complicated.

[pythonpoole]

Well the first problems sounds like you have the incorrect OGM set as your default Answer OGM.

 

In the IVM main window, you should change the "Default Answer OGM" option to the OGM you have set-up to transfer the call.

Once that is done, you should be able to get the confirmed transfer setup working again.

 

As for a transfer fail.. it is handled just as if the person on the other end rejected the call.

 

EXAMPLE:

- "TransferQuery set to" 2 seconds long

- "Repeat call transfer prompt before failing set to" 5 (the minimum)

- "If transfer fails" set to "transfer" and in the Details dialog, set-up the same settings as above, but with the new number, and then "If transfer fails" to Leave Message for Mailbox

 

In this example:

Person calls in. IVM calls transfer number. If person answers @ transfer number and accepts call, call goes through. If the person rejects the call, or if no answer is given after approx. 10 seconds, then the transfer is rejected/canceled and IVM will call up the next transfer number and do the same. If the call is not accepted, not answered, or rejected it will ask the caller to leave a Voice Mail message.