On Call Redirects with Contact Center and Google Sheets

One call flow I always end up working with is how to deliver calls to an on call resource after hours.  Communications Manager, Unity Connections and UCCX had lots of little tricks that always got used, but when you get to Cloud Calling and Contact Center those tricks aren’t the same.  In order to stretch whats possible we looked at how we can build a generic API that looks at something as simple as a Google spreadsheet to find an on call resource, and then let Webex CC just hit that REST endpoint to get the number.  In this point we’ll walk through how these pieces fit together and what kind of interactions we can pull out of this same flow. We won’t get hugely technical with the API because that would take a lot of space, but we’ll look at the functionality.  If you interested in walking through it deeper just let me know and we can follow up 1:1.

Similar to our Time-API post we are leveraging a Google Cloud Function to provide the more complex logic to what we are doing.  That logic is based around a simple spreadsheet that provides a lookup of the on call person, contact info and when they are on call. Because we are using Google for the function it’s easy to create a service account for this API so you can also keep it secured and not just openly exposed on the internet. We can also reference different tabs of the sheet to pull different on call schedules so it becomes a single source for all departments if needed. This was my first time really working in Google Sheets and I will say it was awesome. The interface is very intuitive and simple things like locking rows and adding validation to a cell was super easy and much better than Excel.  Doing cell validations in Sheets also means the data is more reliable and less code is needed when it hits our function because the input is already sanitized to an extent.

The rules are simple.  Webex CC will let us do a REST call and parse the results.  It will also let us redirect the call to another number.  So what we expect back as part of this API is to fetch the first matching person based on the current date/time and provide Webex with that phone number and then transfer that call.  The Webex CC Flow is fairly straight forward if you’ve made it through the Time of Day API post from before.

When we make the REST call to our on call API we specify some info about the call like the ANI, the DNIS and what “Team” or the on call tab we are going to look at.  Then we parse out the results.  An important field here is onCallStatus.  If the lookup was unsuccessful we’ll let the caller know they aren’t getting transferred so they aren’t expecting more than they’re getting.  We also get the on call resource’s name and number.  Using the Text to Speech functionality we can tell the caller who they are being transferred to if needed.

Now you might have noticed a “space” variable in that REST request. Part of the beauty of using REST calls and outside resources to pull info and complete tasks is that a computer somewhere with code on it, is a lot of times going to be more powerful than the niche product your using ( like a contact center) at some tasks.  In this case we are using that function to alert a Webex space of the call.  We can provide more detail of the call and the work flow requires the on call resource confirm taking the call, so calls don’t go nowhere and we have a record of the transaction.  If we did have an issue looking up a resource, we post that info in the space too so that people are alerted of who called and have the means to reach them back.

This is a simple demo of how you can really expand on your call platform by building APIs into it.  Because this is an API source only, the call platform doesn’t matter as long as it can make a REST call and parse the results.  Here we outlined it with Webex Contact Center, but the same functionality is easily done in UCCX, UCCE, Five9s, Twilio you name it.