cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
15081
Views
50
Helpful
40
Replies

UCCX Scripting question

PhillDay1
Level 1
Level 1
We have a requirement from our client running UCCX version 8.5 to
route calls within a certain time period to the same agent that dealt with the last call
from that specific calling number.  I recognise that this is probably a fairly complex scripting issue,
but it's very pressing nonetheless, and any helpful pointers I could get from an expert
would be most gratefully received.  We are working on a project which will depend on this
feature, and I don't know how to achieve it.  Thanks in advance
1 Accepted Solution

Accepted Solutions

Oh that's beautiful!  Nice work!

Have you tested it?  Does it work like you want?

View solution in original post

40 Replies 40

Aaron Harrison
VIP Alumni
VIP Alumni

Hi

I've previously set up a customer with a system that bumped up priority for return callers. This was on CCX7.0, and I did it by setting up a DB data source pointing back to the CCX historical DB, and searching for the calling number in the last x hours of calls.

I've not tried this on CCX8+ so don't know if it's even possible to do this to the Informix HR DB. Either way 'supportability' by TAC is contentious.

A 'supported' way would be each time you connect to an agent, write it out to an external DB (e.g. the time, caller number, and agent connected to). Then when a call comes in, read that DB, and if there is a call logged attempt to route the call direct to an agent.

Regards

Aaron Harrison

Principal Engineer at Logicalis UK

Please rate helpful posts...

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

You could leverage a global session for this task.

It basically works like this:

A global session mapped to a common name, say "scoobydoo", holds ANI's from callers and an Agent User ID.  At the start of every call, you check this global session for the ANI, and if it's in there, you read out the Agent User ID.  If it's not there, then you simply add it once you complete the select resource step or the connect step.

The default session timer is 30 minutes, however, that's 30 minutes of inactivity, not absolutely 30 minutes.  therefore, if you wanted to expire the "remembering" feature, you would also need to store the timestamp of the last call, as well as the Agent User ID.  Of course, if your doing this type of thing, why not attempt to send it to the same agent all the time?  they might develope a personal relationship, and then friend each other on facebook.  =)

EDIT: I just broke a rule of my own, and replied to Aaron instead of the OP.  Sorry to those who have nested view turned on.

Hi,

I think this is how I pictured it working. I remember learning about the session timeout, and I figured we would need to check the session of inbound contacts. I know this is a shot in the dark, but would you have a simple example you could share, just so that I can dial in exactly how to build it?

Very grateful for your help!

Phill Day

No sorry, I don't have any code on this.  I have written a script which uses global sessions, but it was to cache XML documents from the repo.  so I know it works.  Instead of caching the document, based on filename, you cache the Agent User ID based on caller ANI.

How about this, go ahead and read up on how sessions work in the documentation (scripting guides vol 1 & 2), and put a rough draft together, and the community can help you refine it here.  It's also the weekend now, so this post may not get much attention until Sunday Monday.  I'll do my best to check it through the weekend though.  I know I get excited to make fresh ideas turn in to actual working scripts.

Thanks, I'll give it a go!

Phill Day

How's progress?

...Actually, here is a rough sketch of what I think I want to achieve.  I've attached the AEF below - not sure if it will come across. Where I get slightly lost is with the Get Session Info step.  I can't work out how I extract the information I need from the existing session to act on with a boolean switch.  I think once I have that down I'll be on the way.

Phill Day

Always start small, and build upon proven code, testing each new piece as it's added.

Start simple.  Take a look at this script example of how I:

  1. Created a session
  2. Stored something in the session
  3. Retrieved that something from the session

Once you master the simple I/O of a session, then you can move on to more complex tasks.  See if you can pick apart what you see in that example, and recreate it from scratch.

Also, I'll add that you do not necessarily need to create a new session for every caller, as the system does that for you automatically.  Just get a reference to it with the Get Contact Info step.  If you wanted to have a singular session object, with a different data container for every caller, you could do that too, but it's a little more complex and wouldn't net you much gain.

…ok I have a couple of questions then, and apologies if this is turning into tuition, but although I’ve worked with scripts for a while, they have never needed to do anything like this! My assumption is that the “session input” in this scenario would need to be the calling number, and then the session output would match the input if the same caller called in. This kind of makes sense (although it’s certainly not properly dialled in yet!) but then how would we associate the user who hasn’t even taken the call yet? This seems like we need information that isn’t present in the application yet. Would we select a resource and then map that agent to the session as well? Again, apologies, but I’ve read and reread the guide and for some reason it’s still not crystal clear. ☹

Phillip Day wrote:

...and apologies if this is turning into tuition...

Don't worry about.  This is a support community.  We're all happy to help! =)  Keep those questions coming.

Phillip Day wrote:

My assumption is that the “session input” in this scenario would need to be the calling number, and then the session output would match the input if the same caller called in.

The session input would be the Agent ID of the last Agent the caller spoke with.

The ANI plays a role as the session mapping.  See, you need to check if a session exists at the start of every call (remember the 30 minute timeout?). You have to do that with the Get Session step, and the only way to refer to that session is by name.  Or mapping, as it's called.  And that mapping name can be anything from "apple" to "zebra".  However, I ask you, what unique piece of information do you know about the caller, which would be suitable for a mapping name?  Their first name?  Probably not, unless you performed some kind of data lookup prior in the script.  This is where the ANI is helpful.  If you don't know anything about the caller, then the ANI can be used as the mapping name: "6125551000" (as opposed to "apple" or "zebra").

Phillip Day asked:

...but then how would we associate the user who hasn’t even taken the call yet?

I'm not sure what you are asking here, but I will say this: at the start of every call, a new session is automatically created for the caller (remember the Get Contact Info step?).  What you need to do is, check for an existing session (Get Session step), based on the ANI/mapping name (remember that?), and if it does exist, you read the session output to get the Agent User ID.  If it does not exist, then this person just goes to the next available agent.  Once connected to the Agent (successfully I might add), you use the Set Session Info step to write the Agent User ID as session input.

I like that this is turning into a lesson, as opposed to you just receiving a working script.  I hope you feel that way too.  =)

...OK I've slept on it, and drawn up the attached.  If I'm reading you correctly, this would do the trick?

Oh that's beautiful!  Nice work!

Have you tested it?  Does it work like you want?

I haven't had the chance to test it yet, I need to add all the trimmings such as prompts and timers etc, and I'll add it to the live system early next week.  Nonetheless I'm buoyed by your response given that you clearly have a deeper knowledge of this than I do!  Thanks very much for the pointers.

Hi Phillip!

Do you have a chance to share your script1.aef in a print screen? I'm trying to share some session data between some of my scripts and it sounded on Anthony that you did a great job! I can't open that script in a CCX 8 editor nor in a CCX7 editor! I get = unsupported version format:7

I look forward to see your great work!

Rgds, Mikael