Passing parameters between instances of a script

[pmowry]

Hello,

  Short version is in CCx 8.5(1) I need to limit the number of calls in queue to <= 16, but my callflow allows a 15 second to a minute where additional calls can sneak in.  Call volume is high enough that the customer has noticed up to 20 calls in queue

I don't want to ask the caller for their account number if they are not going to queue, and I need them to complete entering their account number before sending them to an agent.  Between the TotalCallsInQueue comparison and the select resource step is where the opening for additional calls happens.  So I was looking at using an enterprise data field (CallsEnteringQueue as a possible name) as a variable that I would read and add to the calls in queue count,  If the total is <16 then the 1st step under True would be to increment the Enterprise data field so other instances of the script would know about this call, then decerement it right before the Select Resource step.

Can I use Enterprise data like a global variable in this way?  I was thinking about using an XML file, but from what I've read it is not "thread safe", and i do not have an external database I can use for this step.  I do not see an alternative Get Reporting Statistic step I could use to get total calls in an application or other alternative, but I'm open to suggestions.

Thanks,

[Anthony Holloway · Accepted solution]

I have to be honest, I didn't read your whole posting, but I read the first sentence and thought I'd share something.

In your screenshot, I don't see how you are setting the variable: totalCallInQueue.  But there is a Get Reporting Statistics step where you can get the total callers in queue for any CSQ name.

So, when you say "I need to limit the number of calls in queue to <= 16", I immediately think "That's easy"

Variables

int queue_depth_threshold = 16
int callers_in_queue = 0
String csq_primary = "HelpDesk"

Script

...steps leading up to queuing...
callers_in_queue = Get Reporting Statistics (Contacts Waiting from CSQ IPCC Express)
If (callers_in_queue > queue_depth)
     True
          /* too many callers in queue, do something else */
          ...handle this scenario...
     False
          /* we're good to go, prepare for queue */
Select Resource (csq_primary)
     Connected
          End
     Queued
          ...queue treatment...

Forgive me if you know this alread, however your post did not show how and where you were pulling in the callers in queue metric.

Now I'll go back and read the rest of your post, and see what else you got for us.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[pmowry]

I'm using the  Get Reporting Statistic (Contacts Waiting[CSQ]) step.  My problem is there is an opening during the time when a caller is entering their account number that additional callers can be doing the same thing and will not be picked up by that reporting statistic.

[Anthony Holloway]

Ok, I see what you're real problem is, and forgive my rush to answer the basic question above.

Problem: You perform a GRS step on Calls Waiting, and then ask the Caller for their Account Number, and by the time you do a Select Resource, several seconds have passed and you are now over your queue threshold."

Even if you use a global place holder for data, you will always run into a race condition, because nothing in UCCX, other than a queue, is treated fairly.

Two quick solutions I have for you:

1. Select Resource with Connect = No

Perform your GRS step for Calls Waiting, and if passed, do a Select Resource Immediately after, but set the Connect to No, and then ask the caller for the Account Number.  This will reserve their spot in line, as well as reserve the Agent for them (the agent will literally be in the reserved state), and minimize the time between the GRS step, If step, and Select Resource step to millseconds.

Pro: Virtually eliminates the delay you are experiencing

Con: Puts the Agent in reserve state longer than they are use to, and will increase your total queue time for each call.

2. Only ask once queued; Otherwise let the Agent ask.

Perform you GRS step for Call Waiting, and if passed, do a Select Resource immediately after.  If connected to an Agent, just let the Agent ask for the Account number.  This is not bad customer service, and if anything the person will be happier to talk to a human sooner, versus typing in a number on a phone.  However, if the caller get's queued, then ask them for it while they wait in queue.

Pro: Caller talks to human sooner = good customer relationship building

Con: Two methods for asking caller for their Account number

I guess a third option is to remove your requirement to only ask if <=16 people are queued, and just ask for the Account Number always.  But that doesn't seem like a good fit for your environment.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[pmowry]

"1. Select Resource with Connect = No" seems the best way to go in my situation.  A global variable would drastically reduce the timeframe for the race condition, but this eliminates it.

As for the original subject line for anyone else searching and coming across this thread.  Can Enterprise Data be used to pass information between instances of a script?  Unfortunately I can't think of a different example at the moment.

[Anthony Holloway]

pmowry wrote:
As for the original subject line for anyone else searching and coming across this thread.  Can Enterprise Data be used to pass information between instances of a script?  Unfortunately I can't think of a different example at the moment.

Yes it can, but for the Triggering Contact only.  I will always prefer Sessions over Enterprise Data, unless I'm interested in: passing data to CAD, or storing data for reporting.  In your case, you may want to tag each call record with the Account number, so I say go for it.  You'll benefit in three ways: global data store and retrieval, CAD Enterprise display, and historical reporting.

If you need a contact agnostic global piece of data (like XML files, or DB's), then the Session object is a good choice.  You can actually create new Sessions on the fly, add a common mapping name, such as "Global", and read and write to it from any running script, regardless of contact.

This is accomplished very similarly when caching documents from the repo into session objects to limit the burden on the document repo.

Here are two threads where I describe the feature of global sessions.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.