Webex Contact Center Time of Day without Routing Strategies

So maybe you made it through the last post around Routing Strategies in Webex Contact Center and realized you had a lot more work to do than you thought you did for your deployment. Or maybe you ended up here because you started to do a lot of work and thought maybe there’s a trick.  We good news – there are some tricks.  One of these tricks is to build out your own API backend to provide the time of day for you in a format that you can easily handle from the Flow Editor.

Disclaimer: If you use a random time API on the internet and that person forgets to renew their domain one year, or their internet goes out for the afternoon or whatever AND you’ve designed your contact center to rely on that API, guess what also goes down for the afternoon?  If you are going to do this in production I’d recommend taking precautions to make sure the API is always up and ready.  Maybe that just isn’t worth not using Routing Strategies, maybe it is. Your call.

Part 1: Requirements

The Flow editor gives us a REST block we can use to hit endpoints and parse out the response.  That will be the basis of what we are doing.  Because of are parsing abilities in the Flow Editor are fairly limited, we can use the API to respond in a format that we can easily parse. This site has pretty much what we need – a simple free API over the internet that is formatted correctly (hope they pay their bills) – https://www.timeapi.io/.  What we are looking for is each piece of the date broken out so we can piece them together the way we want as an integer instead of as time.

"year": 2020,
"month": 12,
"day": 13,
"hour": 9,
"minute": 30,
"seconds": 17,
"milliSeconds": 0,
"dateTime": "2020-12-13T09:30:17",
"date": "13/12/2020",
"time": "09:30",
"timeZone": "America/Los_Angeles",
"dayOfWeek": "Sunday",
"dstActive": false

Part 2: The Flow

Now that we have what we need, we can jump straight into the Flow Editor and start building.  The biggest part of this is making the REST call and parsing out the variables.  The rest is just evaluating those variables.  First we will need to create a Flow variable to cover pretty much each of the options we are returned, ei: year, month, day, hour, minute.  As part of this API we can specify what timezone we want the time out of too so that will be set by us.

Next we want to make the REST call by dragging over the HTTP Request block and configuring the endpoint.  Remember to specify your timezone, and then scroll down to the Parse Settings.  Here we will use JayWay syntax (https://jsonpath.herokuapp.com/) to associate the JSON variables to actual Flow variables.

Now that we have the variables we need, it’s all about stitching together conditions to get to where we need to be. I always like to parse Holidays first.  We can do that with a Case statement so we can easily read and modify it later.  Let’s take all of our variables and stitch them back together in a reliable string that we can check against. {{currentMonth}}-{{currentDayOfMonth}}-{{currentYear}}  Each of these dates will lead off to a portion of the flow that handles holidays.  I’m just playing a prompt and disconnecting.

The “Default” branch from this Case will be any value not matched (any other day) and we will send that off to our next parsing task – Day of Week.  Cause who works on the weekends right?  Because the API was nice enough to give us the day spelled out we can just make it easy to read and create another Case statement around that.  If it was an integer day we could use cases 0-6 or could do a condition 0<>6.  Just like Holidays, any day that we know are closed (weekends) we just dump to a closed prompt and disconnect.  Everything else goes into the next condition.

In order to sleep at night we are going to close between 5pm and 8:30am.  Because a case statement doesn’t make sense for this type of evaluation we will use the Condition block which is basically an IF/THEN/ELSE statement.  Again we’ll piece together the variables in a way that we can check them against what we want.  9 to 5 is pretty simple, but notice we need to expand the condition to catch that 30min before 9. {{ ( (currentHour >= 8 and currentMin >= 30 ) or currentHour >= 9) and currentHour <= 17 }}

Here we are evaluating if we are open so if True we will move on to queuing or whatever we need to do and if false we’ll send them to that closed prompt prior to disconnect.

Part 3: The Finale

Routing via time API brings everything under one script which is nice and easy to manage. The drag and drop nature of the Flow Editor adds a lot of connection lines, but that’s not anything you wouldn’t deal with otherwise.  Below is the full example script so you can see how each piece feeds the others.  We’ve also added in some checks to make sure the REST call was good, logging points that we push off to our logging API and a manual check block that we put in for future use.

So now we have some options when it comes to call routing.  We’ll keep down this same time path if future posts around Webex CC and see how we can tweak it further.