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.
4 responses to “On Call Redirects with Contact Center and Google Sheets”
I have a question about an agent transferring a call to another queue within WxCC. when doing that, it keeps the original flow but updates the queue block to the queue that you transferred. is there a way for the flow to have logic on these types of transfers? meaning if the updated queue is “Sales” then do x / if the updated queue is “Support” then do y?
I typically try to create an Entry Point and Flow for each queue and contain all of the “queue logic” there for that group. From the main IVR you can use the Go-To step to move the call to the associated queue Entry Point and within the Agent Profile you can restrict the agent to only transferring to these Entry Points and restrict transfers to the Queues directly. Breaking the call flow down into individual components like this allows you to organize and reuse components easier and lets you be more specific with the intent.
Jon, This is a great post. Thanks for sharing. Could you please also add the steps for configuring the API settings on the google side, and the custom connector on the WxCC side?
For the API side on Google I’m just using a Cloud Function which provides a REST API endpoint by default which is nice. You’ll see it under “Trigger” within the Cloud Function portal. You can do similar with Azure Functions or AWS Lambda too if you’re using a server-less app type model. There’s no authentication to it so within Webex you can just do a standard REST request. Think of the Webex CC Connectors as an authentication keeper. You can setup basic or OAUTH credentials and then just reference them from within the script so your admins don’t need to hard-code or even know credentials while they are working on the flow.