Recognizing call backs

Answered Question
Apr 25th, 2012

Hello,

Does anyone have a script that shows how the IVR can recognize a call that has called back within the last 30 minutes?  I reading you can use Session ID and map it to a phone number so that the person does not have to go through the IVR again.  Any help would be greatly appreciated.

I have this problem too.
0 votes
Correct Answer by Anthony Holloway about 1 year 11 months ago

No problem.

So there is an idea of a Session Object.

For every new Contact, there is a new Session Object created by the system, automatically.

In order to interact with it, you must create a Session variable to hold a reference to the Session Object, and then use the Get Contact Info step to store the Session Object reference in your Session variable.

For the remainder of that Contact's life (until the caller disconnects) you can store and retrieve information from the Session Object.

This is a handy way of implementing persistent data accross multiple script transfers as the data in the Session follows the caller around within UCCX.

One additional thing you can do with Sessions is recall them in the future.  But the time limit on how far in the future is limited to a System Parameter for Session Idle Timeout; a default of 30 minutes by default.  Don't forget what I said eariler: This timer resets every time you access the Session Object!

Sessions are normally referenced by an Object ID, but this is a long string of alphanumeric mess, and how do you manage the mapping of Object ID to Caller?  Well, there just happens to be a feature to create that mapping for you.  It's in the Session Mapping Step.  You can use anything to create the mapping. In fact I would encourage you to prefix the mapping you use with the application name, such that if you implement this solution in multiple applications, you can have a per application mapping.  E.g., mapping = "helpdesk" + calling_number

Now, when the caller calls back, they technically have two Session Obects: the one from < 30 minutes ago, and the new one from this return call.  It's now time to figure out which one you will use.  This is actually a very easy task: you "attempt" to get a Session Object, based on a Mapping ID, and if it does not exist, your Session Object will be == null.  Otherwise, you found the previous session.  And from this point forward you can simply use this retrieved Session Obect instead of the new Session Object.  Just ignore the new one.  Nobody likes the new guy anyway.  Am I right?

Ok, how are you feeling about Sessions now?

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
Anthony Holloway Wed, 04/25/2012 - 11:25

You have the right information, now all you need is the solution.

Here is a high level of how you accomplish this:

  • Call Arrives
  • You Grab the Calling Number (ANI)
  • If there is no ANI, abort this check all together
  • You Check for an Existing Session with the ANI as the mapping
  • If there is no Session found, create a new Session Mapping with this ANI as the mapping ID
  • Check the Session object for a session variable named "last_action" (this name is up to you and defined below)
  • If last_action is null or empty, start the IVR at the beginning
  • Play a helpful message to the caller to let them know you are resuming where they left off last
  • Use a switch step on the value of last_action, with a branch for every possible last_action value
  • Inside of each branch, place a goto step to jump to the respective section

Throughout your script you will need to keep rewriting the value of "last_action" to keep track of where the caller has been/is now, and store it inside of the Session object.  This way, when the call disconnects, the Session object holds the last place in the script the caller accessed.  You can use any variable name you want, I chose "last_action" as an example.  Also, it doesn't have to be any specific Type either: you can make it a String, I.e., last_action = "Main Menu", or an int, I.e., last_action = 1349 (where 1349 means Main Menu).  It's arbitrary.

The session timeout, which is 30 minutes by default, is reset every time that session object is accessed.  So if a caller calls in @ 3:00pm, and then calls back at 3:10pm, then the new timeout of their Session would be 3:40pm, not 3:30pm.

Make sense?

mdeserio@ Wed, 04/25/2012 - 12:03

Thanks so much for the answer.  One question, when you say "Check for an Existing Session with the ANI as the mapping."  Is the ANI stored within the mapping ID?  How would you go about checking the existing sessions?

Thanks for you help.

Correct Answer
Anthony Holloway Wed, 04/25/2012 - 12:38

No problem.

So there is an idea of a Session Object.

For every new Contact, there is a new Session Object created by the system, automatically.

In order to interact with it, you must create a Session variable to hold a reference to the Session Object, and then use the Get Contact Info step to store the Session Object reference in your Session variable.

For the remainder of that Contact's life (until the caller disconnects) you can store and retrieve information from the Session Object.

This is a handy way of implementing persistent data accross multiple script transfers as the data in the Session follows the caller around within UCCX.

One additional thing you can do with Sessions is recall them in the future.  But the time limit on how far in the future is limited to a System Parameter for Session Idle Timeout; a default of 30 minutes by default.  Don't forget what I said eariler: This timer resets every time you access the Session Object!

Sessions are normally referenced by an Object ID, but this is a long string of alphanumeric mess, and how do you manage the mapping of Object ID to Caller?  Well, there just happens to be a feature to create that mapping for you.  It's in the Session Mapping Step.  You can use anything to create the mapping. In fact I would encourage you to prefix the mapping you use with the application name, such that if you implement this solution in multiple applications, you can have a per application mapping.  E.g., mapping = "helpdesk" + calling_number

Now, when the caller calls back, they technically have two Session Obects: the one from < 30 minutes ago, and the new one from this return call.  It's now time to figure out which one you will use.  This is actually a very easy task: you "attempt" to get a Session Object, based on a Mapping ID, and if it does not exist, your Session Object will be == null.  Otherwise, you found the previous session.  And from this point forward you can simply use this retrieved Session Obect instead of the new Session Object.  Just ignore the new one.  Nobody likes the new guy anyway.  Am I right?

Ok, how are you feeling about Sessions now?

mdeserio@ Thu, 04/26/2012 - 08:19

Quick Question: The default is 30 minutes from the last activity.  Have you seen issues with increasing that time to say 60 minutes?  90 minutes?  Is there an equation out measuring amount of calls and idle time?

Thanks again, script works great!

Anthony Holloway Thu, 04/26/2012 - 09:27

No I haven't.  The problem you'll want to avoid is as follows:

If storing a Session object takes 1KB of memory, and you get 100 calls every 30 minutes, then your system is burning 100KB of memory for storing all of those sessions.

If you increased the timeout to 60 minutes, you (and this is really simplified) could expect 100KB in the first 30minutes, and then 200KB in the second 30 minutes.

So the real threat is, if you increase the timeout to the max value, you are just putting a heavier load on the server and eating away more memory.

As a best practice, I would lower the timeout to a value which gets you what you want, but no more.

If you have the means, I would use a a test system to try and profile the memory usage when increasing the timeout and just load the server up with all kinds of calls.

There is a short document on Best Practices which goes into shallow detail of memory and CPU utilzation you may want to read.  Though it will not address this specific issue, it's still worth a read.

http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_7_0/reference/guide/UCCX_Best_Practices.pdf

mdeserio@ Fri, 04/27/2012 - 12:55

OK...last question.

The script recognizes that there is a previous session and (previousSessionID==null is false).  I am trying to pull the variable string "last_Action" out of the previous session.  I can't seem to get any data out of previous session. 

1. How are variables stored in th session?  Do I need to do this explicitly through the "Set Session Info"?

2. How do I use the context portion of the Get Session Info to pull the data in.

Thanks again.

Anthony Holloway Fri, 04/27/2012 - 14:20

No problem.

I have created this illustration to help you understand it.  Let me know if you need more details than this.

EDIT: Sorry if you saw the previous image I had uploaded but I saw I had an error in my script, and have since replaced it with this correct vesion.

Actions

Login or Register to take actions

This Discussion

Posted April 25, 2012 at 8:00 AM
Stats:
Replies:9 Avg. Rating:5
Views:580 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard