Courtesy Call Back - ICM vs CVP queuing

[JEAN-FRANCOIS DIOTTE]

Hi,

We have setup CCB in a customer environnement. I would to know if I can return to ICM if the customer doesn't want a courtesy callback. The reason is simple it's because I need to check if agents are login (in case of emergency). The ICM script is pretty simple.

My questions is simple.

1. Can I return the call to ICM if the customer doesn't request a CCB

2. Can I return the call to ICM once the callback is established and customer is on the line.

My concern is if I don't queue all calls within CCB it will break how CCB is working.

[Ramachandran J · Accepted solution]

Can I return the call to ICM if the customer doesn't request a CCB

Ans: Initial potion of the CCB IVR is handled in callbackentry application. In the OOB application, If customer doesn't opt CCB then Callbackentry application will transfer the call to Billingqueue application. You need customize callbackentry application, So that if customer doesnt opt for CCB then callbackentry application should return the call to ICM with any flag. Next in the ICM script you can check the flag and based on the flag condition you can route the call to another application.

Can I return the call to ICM once the callback is established and customer is on the line.

Ans: By default, Once call back is established, CVP return the call to ICM and ICM reroute to callbackwait to handles callback IVR portion of call.

Regards,

Ram

[JEAN-FRANCOIS DIOTTE]

My current call flow is as follow

ICM -> CVP CB_ENTRY -> CCB YES -> Wait in CVP until call is establish with customer -> Back to ICM for Hold and queue treatment.

ICM -> CVP CB_ENTRY -> CCB NO -> Back to ICM for Hold and queue treatment.

I don't want to play hold and music in CVP since I need to check if there is agent login into the queue. If not then I need to play a disconnect message or re-route the calls.

In this scenario what will happen with the dequeing process of the calls that have selected callback?

[SEAN NILSEN]

As Ram said, you can customize the Call Entry.

Sometimes, I've seen folks move the entire prompting of whether or not to engage CCB back to microapps instead of in the CallbackEntry application to make the decision point a little more clear.

Also, to your concern about not Queueing all calls in CCB being an issue - calls have to be queued in ICM before engaging CCB. CCB needs the metrics from the queue in order to even offer CCB. This means that all CCB is really doing is taking over control of the PSTN leg of the call so that the customer can drop. It's then also initiating a count-down to re-engage that caller when the math works down to zero, this is the DEQUEUE part of the whole process. Those "Queue" apps are just providing media and prompting to the caller, they are not controlling the actual ICM Queue in any way.

While all of that is happening on the CVP side, ICM still thinks that there is a caller on the line in the ICM Queue because the signaling and messaging has all been maintained by CCB, so whether the call is CCB or not doesn't matter to the queue itself.

Hope that helps clarify what some of those pieces are.