Showing results for 
Search instead for 
Did you mean: 

UCCX callback script on 10.x

Looking to UCCX 10.6 release notes it said:


Unified CCX does not support the following configurations

  • Within the same script, using the "Place Call" step to generate a call and then placing the call in a queue.


That's the way that Cisco script on the repository uses the CallBack????


Any ideas?

Tanner Ezell

Simply put the call on hold on the receiving script. It makes better design sense to break up the logic that way anyway.

Tanner Ezell

Hey Tanner

Long time no see :)

About putting a call on hold, you mean inside the Queue on the receiving script?



Does anyone have good notes on setting up the callback script? I am missing something - when I try to get the callback to work - It simply fails. I am thinking of calling TAC for help.


thanks for any pointers.

Hi Neal

The most common mistake I see with this (after 'deciding to use it' :-) ) is not setting up each script/app (i.e. original script, callback queue script) with a different Call Control group.

After that any other failure should be pretty easy to diagnose with a reactive debug.


Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

I am trying to get callback working within my script.  The triggers of the callback script are in a different Call Control Group ID and Dialog Group.  My "Place Call" step is set to use those CMG and DG settings.  If I do a reactive debug, I see the call being placed to the callback script and rolling down through and even selects the agent and rings the agent phone.  When the agent answers the call, it just hangs for a couple of seconds and then disconnects. I eventually get the attached error message in the editor. 


Any help would be greatly appreciated.







Firstly, the callback script is a bit rubbish IMO. Time we had a proper callback feature that integrated with the outbound system built into the app, so it wouldn't 'lose' calls.

Secondly - what they mean (I think) is taking the customer call, placing a call, answering that call with the same script, and routing to agent.

That's why the repo example splits it out - place call in Script 1, receive and queue the placed call in Script 2.



Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Hey Aaron

Yes, call back feature is long overdue (like phone poll after call, Accurate estimate waiting time, etc).

Doing callback using scripting (as today) is really rubbish (you need to use a CTI port for nothing and keep the system looping)

Using the same script is worst because same script usually has prompt, menus, is longer, etc.  But in theory is a different thread then i don't see the problem...


I 100% agree, Aaron.  I actually wrote the whole thing using the new API with the REST step and an agent preview dialing campaign.  Unfortunately, there was no way to override the fact that the same contact can't be inserted into a campaign more than once every 48 hours.  While this may not be a problem 99% of the time, those few callers who call back in and request another callback would get lost!  It doesn't fail, it just ignores it at the campaign level.  I have asked for a change to the system so that, when using the API, it allows us to override that "feature".   Not holding my breath.. 

Sadly, dialing campaign is a totally different module that has lower priority over inbound calls. Then if agents are busy all the time answering inbound calls  (agents are shared) you will not have outbound calls = no call back ever. Also forget about position in queue whatsoever...

I don't have a problem with the position in queue loss with doing callbacks. If your call is urgent enough you will skip the callback and hang on. Having your call technically queued at the end is a minor inconvenience for the upside of the feature.


We did toy around with a proof of concept which effectively worked like this: 

Drop the caller after the requested callback.

Monitor calls as they progress through the selected queue.

When the caller ahead of the original callback caller in queue is answered by an agent, call the caller back.

Jack up the priority of the callback call to 10 so it is next in line, and is answered by an agent.


It certainly works well enough and for some customers they demand that kind of treatment (versus having the agent call the caller back). We haven't pushed this solution much because it's quite complex, can be error prone (answering machine detection) and the reporting is skewed somewhat because of the priority manipulation. 


I think in an ideal world we'd initiate a CPA enabled call to the endpoint then connect it back to a CTI Port/Application.


hmm, I might have to toy with this...

Tanner Ezell

Ha... good to see everyone else has tried what I tried with REST and got the same conclusion. Still, always fun to play with a new API...


Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

I never liked that approach, we played around with it but ultimately our implementation far exceeded it and other common implementations in terms of features and functionality. For instance, most callback implementations leave the menu playing constantly in a loop leaving an agent to hear the callback prompting in the middle or often enough in the silence part of the message. Also, our implementation protects against abuse such has hanging up on the callback application and when the customer isn't available will re-queue the call.


Lastly was scheduling, this was the big upside to using the REST api and outbound campaigns but had the problem you describe, reporting implications and it required Premium licensing which is prohibitively expensive for smaller call centers. We built our solution to take both Web based and voice based scheduled callbacks that is compatible with Enhanced licensing and doesn't negatively affect reporting of callback calls as with the campaign option.


I don't see this being corrected in the system anytime soon either. If you look at the internals as to how CallContacts are queued I suspect it would take a considerable effort on Cisco's part to add in that functionality. I think we're stuck with the CTI port method for now.

Tanner Ezell

"The same contact can't be inserted into a campaign more than once every 48 hours"

Sorry to dredge up an old post - but is this 48 hour limit true? It seem's a little crazy to add such a limit, did cisco every look at correcting this?



Recognize Your Peers
Content for Community-Ad