Don't telework with spreadsheets: build a virtual call center in a day
In another article (which you may want to read first if this one seems too technical), I made a case for why you shouldn't rely on spreadsheets to support your new teleworking regime.
I followed that up with a second article talking about how to use Quickbase to create a customer request tracker for a small to medium sized organization or department of a larger organization.
That request tracker is something that can easily be built in a few hours and help solidify your teleworking infrastructure. But it's still solving a fairly simple problem.
In this article I'm going to give an overview of a more complex application that can also be built very quickly. I will show you how you can use Amazon Web Services (AWS) Connect, their loud based telephony offering, and Quickbase , a low/no-code application builder, to build a virtual call center.
This takes more than just the point and click configuration of the request tracker as it requires writing javascript code to tie the two systems together. However the level of coding skill required is well within the scope of a novice self-taught coder since most of the heavy lifting is done with pre-built code libraries and API calls.
The intent here is mostly to illustrate how easy it is to work with AWS Connect and Quickbase in particular. I also wanted to get this up quickly so while it's complete, it's not a step by step detailed guide. I would be happy to share code and walk people through in more detail, just reach out to me.
AWS Connect plus Quickbase
AWS Connect uses a browser based "softphone" to make and receive calls. It has powerful tools that easily allow savvy but non-technical business users to built a custom call center solution but really just handles the telephony aspect. It must be integrated with another tool to handle the post call request tracking and handling.
As a result, to implement this quickie call center we are going to create a Quickbase app that has a custom html page with the AWS connect softphone embedded. The integration will use the AWS Connect Streams library that routes events such as an incoming call to handler code that looks up the caller in the customer table of the app.
The application flow is as follows:
Call comes in to browser based softphone that is embedded in a quickbase page.
The caller's phone number is automatically looked up in customer table. If it doesn't exist, a new customer record can be created.
Other call information is pulled (which choice in a automated menu the caller picked for example) and saved in a new request which is attached to the customer
Other workflow steps can then be carried on within Quickbase but that's easy to set up and so we won't cover that here
The steps to create this integration are as follows;
Create AWS Connect call flow
Create custom HTML page in Quickbase
Embed AWS Connect browser based "softphone" in the custom page and use AWS Connect Streams API javascript library to integrate with Quickbase tables etc
Deploy this virtual call center to your staff
Step 1. Create AWS Connect Call Flow
As mentioned earlier, AWS connect provides a bare bones browser based "soft phone" that call center agents can use to answer calls coming in from customers. It uses the concept of a "Call Flow" to handle interactions with callers. These define things like prompts, getting user inputs, and routing to the agents handling the calls.
In this case we will create a fairly simple flow that prompts the user to enter either 1 for request type "A" or 2 for request type "B". This choice is then passed through the AWS softphone embedded in the Quickbase page to the integration code running in the page itself.
Here's the connect flow (you can click on it to get a bigger version):
It's very easy to configure through this visual interface. We just need a fairly simple flow for this purpose. The main blocks are the one prompting the caller to make the request type choice and two follow on blocks that set a variable based on that choice so the javascript on the Quickbase page can access it.
The main thing to note is that I set a "requesttype" variable based on caller input and that variable is then available to the integration in Quickbase.
Once I've created the call flow, I create the page that implements the interface and integration in Quickbase.
2. Quickbase Custom HTML page
One big advantage Quickbase has over other no-code platforms is that you have the option to use actual code if you want: you are able to use custom code to enhance the native user interface. For example, you can create special fields that embed javascript to create a button that does something interesting by calling the Quickbase API.
However, in addition to these one off uses of custom code, Quickbase also provides the ability to write custom html pages completely from scratch. These pages can contain whatever arbitrary code that you like and can integrate with the Quickbase API to do some very interesting custom applications.
Here's a simple example of a custom interface for updating the teleworking status of staff:
This is unrelated to our AWS Connect integration but demonstrates how you are not stuck to using the Quickbase interface.
For this application we will create a custom Quickbase page that is accessible directly and is what our call center staff would use to handle actual calls coming in. However, the standard Quickbase interface is also a part of the application for reports and managing post-call work etc. We won't go into that part but we can still use those standard Quickbase features to create whatever workflows, notifications, permissions, integrations to other systems, etc we need to fully support our call center staff
For now, we'll just create two tables. A customer table that has the customer's name and phone number and a requests table that has details of each call request coming in. Each customer can have one or many related requests but every request only has one customer.
Customer table (showing a report view of multiple records):
Request table (showing a single record view):
We can create more complicated interactions but for now, that's enough to walk through this integration.
Now that we have the tables, we create the page that will hold the custom interface code:
Here's the code. It's not pretty but it gets the job done and hopefully it's understandable:
There are two files, each will be a separate Quickbase page.
awsconnect.html - the html and javascript that implements the user interface and the integration code. I go into the way that is done further down.
utility.js - a set of utility functions I've cobbled together over the years to work with quickbase. I will go into my approach here in another article but there two important things to pay attention to in this file. The first is the way I get data out: by calling a regular Quickbase report with the API call "API_GenResultsTable" to get the data from a table as a set of four javascript arrays that I store in my "JSAResult" object. The second is the way I push data in: I create a csv format "file" and push that into the table via the Quickbase API call "API_ImportFromCSV". Doing it this way updates a record if it exists or adds it if it doesn't.
Now its time to tie everything together
3. Embed AWS softphone in Quickbase page and create integration code
As mentioned above, AWS Connect provides a javascript library that allows integration to the AWS Connect Streams API. It works off of events such as agent logging into the system, calls coming in, etc.
I used this superb blog post by Perficient, Inc to figure out how to write the integration code:
You should definitely read this as it is a very detailed step-by-step guide to using the streams library and there are a couple of configuration steps needed to setup AWS Connect before using the library.
Speaking of which, here is the actual AWS Connect Streams library used to integrate the ccp with quickbase via javascript events:
The key facets of the this approach are event handlers that get called when a phone call comes in. The data from the call is made available for the handler to use. Not only the standard call info like caller number etc, but also internal variables we pass through like the caller's choice of request type.
The application flow is as follows:
Page is initialized and reference to the URL for the softphone in our AWS instance is used to embed the phone in the user interface. The AWS streams API is used to register functions which will be called when a call comes in.
When a call comes in, the function we subscribed to these events is called with a AWS streams "contact" object passed in. This object contains various parameters about the call including the caller's number and the 'requesttype' variable that was set in the call flow.
The call is saved in the "Requests" table.
The caller's number is looked up in the "Customers" table. If that customer is found, then the request is attached. If not, then a new customer record is created and the request attached to that.
Initialization
The first thing here is to embed the AWS Connect softphone into your html page and register the incoming call event handler (some extraneous code has been stripped out for clarity):
here's the incoming call event handler (modified from what was in the Perficient blog post listed above):
Customer lookup
It's worth going into a little detail on the way I lookup the customer as again it shows how versatile Quickbase is.
First I created a report in quickbase that looks for a phone number inputted by the user by using the "ask the user" feature in the filter criteria of the report. If you look at the URL when you access this report, you can see the input value is just a string after the "v0=" part.
I then just call this report URL with the aforementioned API_GenResultsTable call and tack on the caller number at the end of the string to get the customer information in a format that we can use in javascript.
Final Product
And finally, here's what it looks like when a call comes in:
Final Thoughts
My code is very hacked together but I did try and comment it but this application is very straightforward. It really is only about one full day of solid work to get this basic system up but it is just a starting point.
There is so much more you can do once you've gotten this dialed in. For example, since this is on AWS and the call recordings are sent to an S3 bucket, what I've done in the past is point AWS Transcribe (voice to text) and AWS Comprehend (Text Analytics) to that recording and do a sentiment analysis to identify which calls are relatively negative interactions so you can focus on those for training and/or reaching out to the customer.
Teleworking can be an opportunity for innovation, not just an emergency parachute. I hope you find this helpful for the former. Good luck and I hope you are all staying healthy and safe.
