Just wondering if anyone knows a way to prevent calls being transferred to destinations that are invalid/busy? (i.e. an optional system parameter or setting that could be changed)? For example: Caller A is with IC User and they need to transfer to Destination B. - The IC User can use the 'Transfer' (Blind transfer) option, but Call A will be immediately transferred to Destination B even if the number is invalid or busy. Caller A is then inconvenienced by getting the error/engaged tone having to call back. - Alternatively, the IC User can use the 'Consult' (Consultative transfer) option, but they have to stay on the line and listen if Destination B is valid and available, can't complete the transfer during the Ringing event until the Destination answers. Ultimately it would be great if either: a) upon initiating a blind transfer, if the destination returns a invalid/busy SIP message, the transfer is rejected and the Caller remains with the IC User and displays why the transfer failed. b) after performing the blind transfer, if the destination returns a invalid/busy SIP message, the Caller is returned back to either a User queue or Workgroup queue (a common feature on receptionist/operator platforms when the transferred destination doesn't answer) We are currently working around the issue by training all IC Users to always Consult transfer and check the destination is valid and available, and whilst this is better for customer experience it adds additional handling time to calls. Thanks, Jeff.

Jeff, How often are your agents blind transferring to an invalid or busy number? Assuming every call is external there is a customization point within System_TransferCallRequest called CustomExternalTransferRequestFailure that you can add custom logic so that the call goes somewhere else instead of being disconnected. For internal extensions I'm pretty sure the system will not let you transfer to an invalid extension, or at least it use to prevent this but it's been a while since I tried it so maybe it changed. - Mark

We prevent this by using a speed dial for transfers, Agents drag the call on the speed dial item (and can't fat finger the number). This doesn't solve for busy signals but for our purposes that is not needed.

Originally posted by MarkT;36835
Jeff, How often are your agents blind transferring to an invalid or busy number? Assuming every call is external there is a customization point within System_TransferCallRequest called CustomExternalTransferRequestFailure that you can add custom logic so that the call goes somewhere else instead of being disconnected. For internal extensions I'm pretty sure the system will not let you transfer to an invalid extension, or at least it use to prevent this but it's been a while since I tried it so maybe it changed. - Mark

Hi Mark, Most of the transfers are to our Cisco platform which are considered an external calls. I went through the System_TransferCallRequest handler for external calls and found the steps it follows: External Call > Step (Complete External Blind Transfer) > Step Outcome (Busy) > Set Call State (Move to System queue from User queue) > Customisation point (CustomExternalTransferRequestFailure) > Selection Step (Busy) > Play Prompt Phrase (Busy tone) > Disconnect So the handler knows the line is busy and actually doesn't complete the transfer - it just takes the call away from the User queue and plays a busy tone from CIC/PureConnect for 60 seconds and then disconnects. I can see the customisation point that could perform some additional handling, but because it's been taken out of the User queue already it's not as simple as just "stopping" the external transfer and leaving it with the user. It would need to identify the user it came from and allocate it back to them. At least I know there isn't anything out of the box that could be configured and would need handler customisation. Thanks, Jeff.

Jeff, The call attributes should be able to help you here. There should be an attribute which shows the last user and last workgroup the call made it to so you could referring. Granted if this was an ACD queue then the caller would be at the bottom of the queue again instead of their previous spot. You could always modify the set call state step, granted this is a base handler so you will have to modify the logic and then remember to put it back if it is overwritten during an upgrade. You will want to test this as I'm not sure what actually happens if the transfer fails as it might be impossible to just connect the agent again. -Mark