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.
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
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):
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
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.
Now its time to tie everything together
3. Embed AWS softphone in Quickbase page and create integration code
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.
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.
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):
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.
And finally, here's what it looks like when a call comes in:
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.