cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1649
Views
5
Helpful
10
Replies

Call back error when main queue is full.

garethpeart
Level 3
Level 3

Hi all,

 

I'm having an intermittent issue on my call back script. After looking at the logs, it's due to the main HD application being full and all CTI ports being in use. Is there a way around this at all?

 

UCCX 12.0

Enhanced seat license

 

Gareth

1 Accepted Solution

Accepted Solutions

Well, actually, it sounds like just before the menu step. See, if the menu step is offering callback, such as: "press 1 for callback" then you want to secure the resources before that. If the resources are available, then offer the callback with the menu step, otherwise, pretend like it doesn't exist, much like you're doing now with the EWT < 10 minutes.

 

E.g.,

contact = Place Call (to callback trigger)
  Successful
    Set resources_available = true
  ...
ewt = Get Reporting Statistics (EWT)
If (resources_available && ewt > 10 minutes) Then
  True
    Goto Offer Callback
  ...
Offer Callback:
Menu (Hey Elsa? Would you like to have a callback?)
  1 - Yes
    Goto Setup Callback
  2 - No
    Terminate (callback)
...

 


Also, the get enterprise call step is not the number entered in the call back step, right? That's the number I wan presented to the agents if possible.

I'm not sure I understand your question here, but typically, or actually, always, if you want the Agent to see data about the call, you're going to use the Set Enterprise Call Info step.  In this case, you could use that step in the calling script (just remember to swap out the triggering contact for the contact from the place call step), or you can use it in the called script (using triggering contact).

View solution in original post

10 Replies 10

Anthony Holloway
Cisco Employee
Cisco Employee

Aside from the obvious answers such as: through more bandwidth at it, I would think you could re-write the scripting such that you conditionally offer Callback based on available resources.  As opposed to what I assume you are doing now, which is the classic way of: offer callback, hang up the call, then place call to callback (which is when it fails).  Am I right?

Yup, you are right - script is pretty much the same as the original (excluding some pieces that you've helped me with!). How would you pass that resource counter into the call back application? (Trying to do the same thing with adding the original calling number).

 

I've already doubled the original port count for the HD application (laziness), but at the start of the school year things get crazy.

 

Gareth

Actually, I was thinking that you could do the place call before offering the callback at all. This would effectively secure both ports/sessions needed for the callback to work. Then, if they take the callback, keep it going from there, else if they decline, drop those resources.

I usually pass data between calling and called scripts with enterprise data, since the contact from the place call step is the same contact in the called script's triggering contact value. A set on one, results in a get in the other. E.g., Set Enterprise Call Info in the calling script, and a Get Enterprise Call Info in the called script.

So... At the moment, the script offers the call back if the estimated wait time is greater than 10 minutes and then offers a call back inside a menu step. The system requests all information needed and, if successful, places a call to the call back application to put the call in a holding pattern.
When you say "do the place call before offering the callback", do you mean to move the place call step to just after the menu step? How does that work?
Also, the get enterprise call step is not the number entered in the call back step, right? That's the number I wan presented to the agents if possible.


Gareth

Well, actually, it sounds like just before the menu step. See, if the menu step is offering callback, such as: "press 1 for callback" then you want to secure the resources before that. If the resources are available, then offer the callback with the menu step, otherwise, pretend like it doesn't exist, much like you're doing now with the EWT < 10 minutes.

 

E.g.,

contact = Place Call (to callback trigger)
  Successful
    Set resources_available = true
  ...
ewt = Get Reporting Statistics (EWT)
If (resources_available && ewt > 10 minutes) Then
  True
    Goto Offer Callback
  ...
Offer Callback:
Menu (Hey Elsa? Would you like to have a callback?)
  1 - Yes
    Goto Setup Callback
  2 - No
    Terminate (callback)
...

 


Also, the get enterprise call step is not the number entered in the call back step, right? That's the number I wan presented to the agents if possible.

I'm not sure I understand your question here, but typically, or actually, always, if you want the Agent to see data about the call, you're going to use the Set Enterprise Call Info step.  In this case, you could use that step in the calling script (just remember to swap out the triggering contact for the contact from the place call step), or you can use it in the called script (using triggering contact).

Is there a call-back script I could take a look at? A sample perhaps?
As an educational institution, we have 1283#9124@78103 students calling last minute to enroll, with wait times often exceeding 45 minutes... I'd love to take a look at a script that could help me add this into the step...

One of the things to remember is that's you'll need a new call control group for the call back application. I work for a K-12, so I feel your pain.

I see where you're going with it and try it out the next time there's some semblance of normalcy.

Thanks again - you rock!

 

Gareth

Cool! Do post back whether it works or not; we'd all love to know!