WXCC - IVR Query - IVR on outbound / warm transfer call leg?

[Gerry O'Rourke]

Hi,

Does anyone know if this is possible on Webex Contact Center IVR?

Summary of IVR App

Caller A makes a call into IVR.

IVR Answers and asks Calling Party A to enters PIN, if PIN is correct, IVR attempts to make an outbound call to Called Party B.

If Called Party B answers the call they hear an IVR message which asks them "to press any key / or DTMF 1".
If they do so they are then connected to Calling Party A.

If the Call to Called Party B fails or Called Party B answers the call and does NOT press a DTMF tone (e.g. perhaps connected to voicemail) - the IVR hangs up the call (after a timeout) and then attempts to Call the next contact on a list (e.g. Called Party C).

The same process is then repeated for Called Party C as Called Party B.

The Complexity here is that you have IVR on the initial Inbound call leg (to Calling Party A) - this is standard and typical.
but the IVR needs to play out on the outbound call leg (you could call this the warm transfer call leg) to Called Party B / C .

I don't believe this possible with UCCX.

You could on UCCX I believe have a solution similar to UCCX Callback option, where the Caller A after entering a PIN and confirming they want to initial a callback (and confirming their phone number). The Call hangs up and then attempts to call Caller B (or Caller C) and then if they answer and enter DTMF -  to THEN reconnect (redirect) to the Callers A phone number.

Any help or guidance appreciated!

Gerry

[david.macias]

Not possible, biggest issue is that WxCC like CCX can't take the call back. I've solved this use case with Twilio, but it's not ideal either.

david

[ptindall · Accepted solution]

Gerry,

Your call flow is achievable exactly as described but unfortunately not on CCX or WxCC.  On CVP it is possible using an enhanced bridged transfer element to perform whisper transfer with explicit accept/reject by the called party.  Many years ago I was asked for precisely this scenario.  Do you have the requirements latitude to solicit the far-end using SMS or messaging app to see if they will take the call?   That would of course be possible using WxConnect digital channels invoked from the IVR script.

[Gerry O'Rourke]

Paul,

Thanks for the useful info. 
Is the below a valid description of what are describing with WxCC with WxConnect ?
1) Make an inbound call to IVR - answer the call and confirm PIN is good

2) Send an SMS to "Contact No1" with a "can you accept a call - reply Y/N"

3) Wait 60 seconds, and if they reply with a confirmation / Y proceed and do a transfer call to the number, otherwise attempt to contact "Contact No 2" (via SMS, i.e. repeat from step 2 but with "Contact No 2")

It sounds a bit clunky?

Just for info - I assume you created and have that custom CVP enhanced bridge transfer element available if needed? 
Could this be standalone CVP or Comprehensive CVP or both? Although I don't believe CVP is likely an option here.

Gerry

[ptindall]

Gerry,

It does become a bit clunkier with SMS if messaging becomes unreliable but even with calls you have to allow a reasonable time to answer and for the recipient to respond.  Calling is a bit more robust in knowing that the call transfer leg was successfully established but things like going to voicemail can introduce some more clunkiness and delays.  Whatever the notification method, the effectiveness is always going to be impacted by how primed and ready the recipients are to detect and respond to solicitations.

For the CVP approach, yes, it is a real element you would normally use standalone as an alternative to the standard VoiceXML Transfer element although I'd have to check if I ever fixed it for VVB -- like most custom elements doing call control, the VVB broke things and required some fixes. 

For CVP there is an alternative and possibly more efficient approach using call parking, depending on whether you can offer the call to multiple recipients concurrently in your use case.  You essentially park the caller at the gateway and alert/message the likely suspects to call a particular number to accept/connect the caller.  That does overcome the serial solicitation issue.  In fact, how about concurrent SMS to the candidate list and connect the call to the first responder?  Does open up potential for abuse though by slow and non-responders.

Paul