cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1503
Views
0
Helpful
5
Replies

UCCE Courtesy Callback

1rst time post...

I apologize in advance if this is the wrong area of the forum to post my question.  My Question relates to UCCE Courtesy Callback.When a caller elects to get a call back, there’s a EWT calculation telling the caller that they’ll get a callback at (n) time and the caller is contacted at that calculated time. My issue is on all reporting the call shows up in the queue for the total (n) time that’s been calculated even if agents are available.  Can this be addressed?

1 Accepted Solution

Accepted Solutions

rosaho
Level 3
Level 3

This discussion has been reposted from Additional Communities to the Contact Center community.

View solution in original post

5 Replies 5

rosaho
Level 3
Level 3

This discussion has been reposted from Additional Communities to the Contact Center community.

Thank you!

The way that Courtesy Callback is designed, ICM doesn't know that the caller has hung up. The call has to remain in queue for the callback to occur. Basically, CVP is staying in queue on behalf of the caller, and when CVP thinks that the caller's position is coming soon, it calls them back. From ICM's perspective, they're no different from a caller that remains on the line.

-Jameson

Thanks for your response Jameson!  The Cisco Docs on Courtesy Callback confirms what you've described.  But, we are seeing these calls in queue on our realtime CUIC reports and other 3rd party reporting systems  even though agents are available just since we've implemented  Courtesy Callback. These next available agents should be receiving these calls that are remaining in queue. This led me to believe that CVP was queuing the call for (n)time but the documentation describes it just as you have so I'm really not sure why these calls are queuing with agents available.

You may need to review your EWT calculation. It sounds like CVP is not doing the callback early enough to get the caller "back in queue" in time for agents to answer.

If agents become available earlier than expected, CVP isn't going to know about it. The CVP script that does the callback queuing is not interruptible - it has to be set this way so that the call doesn't drop, and so an agent doesn't get connected with a call that isn't there.

My suggestion is to either pass a shorter EWT from ICM, or set the "Reconnect Time" longer in the CallbackEntry application. Ideally, you want the caller to be called back before agents are available to answer their call.

-Jameson