Environment Based Routing Using the Summit Platform

Swami Tech Talk Series

This post provided by Ryan Cayton, Advanced Enterprise Solutions Engineer

A while back I was tasked with completing an IVR application on the Summit platform that would enable a caller to be routed to a secondary call center based on a percentage of the received calls.

The need for this application stemmed from the customer needing a way to push calls away from their minimally staffed call center during increased call volumes or in the event of company-wide training or holidays.

This application also had to be adaptable in that the administrator of the call center needed to be able to make changes to the routing percentages on the fly.

In this article, I'll walk through a high level overview of the layout of the routing application. Hopefully it will spark ideas that you could potentially use in your own day to day operations. 

The Summit platform is ultra-versatile and basically leaves you with a "sky's the limit" on what can be done within the platform.

In this case, we use the datastore functionality combined with cross IVR application data sharing to enable both an admin IVR and the actual call routing application (IVR) to integrate with each other. We even have a third survey application that the callers are sent to once the agent who took their call has disconnected from the call.  

Anyways, I tend to babble so let's get to the meat and potatoes of this post. First, we had to seed values into the Summit datastore. I used the "Map" table type and called it "Service_Percentages". This customer uses two third party call centers(MO/SD), plus their own(HQ).

They have 5 different destinations/departments that we need to account for as well. As you can see from the snippet below, the data is stored in a JSON dataset which makes it easy to pull these values into the IVR application when needed. This dataset can be modified from a separate application by dialing in and following a set of menus but we are not going to cover that here. 

As a precaution, we create and seed three variables containing default routing percentages just in case there is an issue pulling the values from the datastore.

We also store variables with the telephone number to each call center. I've only shown the three here (in the image below) for member services but there are actually separate numbers for each call center and service destination type. 

Once a call has been answered by the IVR, we play a greeting then present the caller with the main menu.

In this case they have 5 options to choose from (shown in image below).

The channel.gather function is limited to one attempt and silence if an incorrect selection is made. This allows the caller to stay on the line and be routed to the default "ALLOTHERS" destination or route to all others if they press an unexpected digit, rather than hear an error message and have to enter a value again.  

"Route_caller" is a separate function that pulls in the percentages from the datastore, writes them to local variables(serviceHQpercent, serviceMOpercent, serviceSDpercent) and routes the call based on those stored values.

If you remember before, we seeded default routing percentage values, which means the route_caller function will use these values if there is an error pulling the values from the datastore. getRoutingNumber is also a function that allows the IVR to determine what call center the call is going to and returns the needed phone number to the channel.dial app call. 

Here's the route_caller function:

getRoutingNumber is a simple function to return the correct number that we specified prior:

So let's walk through a call to show how the pieces really do fit together. 

We assume that the following values have been pre-configured either in the datastore or as a local variable. 

• serviceHQpercent = 55 
• serviceMOpercent = 25 
• serviceSDpercent = 20 
• serviceMOMember = '8885551234' 
• serviceSDMember = '8885559876'  
• serviceHQMember = '8885552727' 
  

1. Incoming call received and answered. 
2. Caller presses 1 for membership services in the main menu. 
3. The main menu for option one calls the route_caller function sending over "MEMBERSHIP" as the parameter value. 
4. route_caller stores the percentages from the datastore using the "get_percentages_values" function. 
5. A random seed value is forced into the pseudo-random generator using math.randomseed(os.time()). 
6. Using the random number generator we store a random number between 1-100 into "randomNum" 
7. We determine if randomNum is contained in the percentage for HQ/MO/SD by process of elimination.
   • For example, our randomNum was pulled in as "78". 
   • serviceHQpercent is equal to 55 so in step one of the logic we evaluate if our generated randomNum (78) is less than serviceHQpercent (55).
   • We fail this evaluation and move to the next comparator. In this case we qualify that 78 is greater than serviceHQpercent(55) but also that it is less than (serviceHQpercent + serviceMOpercent), which is 80 (55 + 25). Since this validation is successful, 78 is indeed greater than 55 and less than 80, we call the channel.dial function.
8. "channel.dial(getRoutingNumber(menuSelection,'MO'), {destinationType = "outbound"})" calls a function (getRoutingNumber), which returns the value stored in "serviceMOMember". Take note that we pass the "menuSelection" parameter into getRoutingNumber function so that it is aware of what the caller selected on the main menu. channel.dial('8885551234', {destinationType = "outbound"}) is the end result and the caller is then routed to 8885551234. 

#mindblown right? Nah, this is but a fantastic voyage into the endless possibilities of the Summit platform.

Think of ways to use this in your own organization. Account payments, patient lab results, finding a location based on zip code, geographic based routing, product release dates and... Wait! I lied, it is limited, but only by your imagination!