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.

[ptindall · Accepted solution]

You can return control back to the ICM script in both cases.  Once the caller has declined a callback or been retrieved the call is essentially no different from a normal inbound call.  Any further queuing should still be handled using the CCB queuing application to allow the mechanism to accurately track the calls in a common logical queue.

[JEAN-FRANCOIS DIOTTE]

Thanks Paul.

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?

[ptindall]

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

In this case, by default, the call won't be returned to ICM for queuing so I'm assuming you modified the default app to return to ICM if the caller opts not to be called back.  When you do go back to ICM, by default, the call end class will remove you from the CCB queue.  If you then continue to queue the call in the ICM with microapps there will be a mismatch between what the CCB mechanism thinks is queued and the actual situation, which will lead to further inaccuracies in dealing with CCB handling its wait times.

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

In this case, because the callback phase is handled at CVP via a non-interruptible VRU script the CCB mechanism absolutely has to return control to ICM in order to run a queuing app that is interruptible.  When control is returned to ICM, the call end class is run as normal but in this case, it doesn't remove the call from the CCB queue -- the expectation is that this is a momentary return to ICM and control will be sent back immediately to CVP for the queuing phase (with interruptible enabled).   So, if you hang on to the call in the ICM script and use microapps for queuing, CCB will have a zombied call in queue that will eventually by tidied up and removed.  However, it will still skew the CCB mechanism with regards to predicting callback times.

So, the bottom line is that you can return to ICM, you can control whether the call end class dequeues the call in CCB, but if you then provide the queuing treatment outside of the CCB application, you will introduce further wayward callback times into something that is already operating on a predictive basis.

In your particular case, are you able to go back to ICM briefly and then return control to CCB for queuing or do you have to repeatedly do checks in ICM?   Have you tried using the ICM Lookup element from within your CCB queuing app to check ICM status?