One of the things we hear from customers building their contact center on Twilio is that they want a way to test their contact center with the same ongoing methods that they test other software applications. Today, we’re going to show you how to do exactly that.
We’re going to use Twilio’s reference contact center application to get us started. It is open sourced on github under the project twilio-contact-center. It isn’t officially maintained, but it works rather well.
The Twilio Contact Center reference application showcases 4 different customer journeys. Of those, 3 make use of a technology called WebRTC:
We are going to use testRTC, an online service that enables testing and monitoring of WebRTC based services. I’ve chosen testRTC because:
- It is suitable for the task and rather easy to use for it – it provides the environment for running such tests and to evaluate the quality of your service
- I am a co-founder there, so obviously…
Set Up the Test Server
To setup the server, just follow the installation instructions available on the github page of the project.
What you will need on top of that to run these tests are:
You can create a testRTC account here. It is quick and easy.
All test scripts for testRTC are available in this github project. You will need to download these JSON files, then import them as test scripts to your testRTC account AND update the Service URL field of the test script:
Here’s the workflow we’re about to test: Customer fills out video call request form -> Form submitted to server -> Task on TaskRouter and video room created -> Find available and matching agent -> Agent accepts reservation -> Agent joins video room
For this, we will use Twilio Contact Center – Video Call.json
Once you change the Service URL and direct it to your server, you can run the test script.
What this one does is:
- Assigns the first test probe to the Customer, direct her to the call request form and submits the form
- Assigns the second test probe to the Agent, logs her in and have her accept and join the video room. This will initiate the video call between the Customer and the Agent
- Have both test probes stay in the video call for a full minute and take a screenshot while at it
After running this test script, you’ll be able to find a screenshot similar to this one in the test run results:
This is what the customer saw in her web browser 30 seconds into the call.
We started with this one because it is rather simple and easy to understand. What I really wanted to share is how we handle PSTN→WebRTC and WebRTC→PSTN scenarios.
Callback Voice Calling
Here’s the workflow we’re about to test: Customer fills out online call request -> Form submitted to server -> Task on TaskRouter created -> Find available and matching agent -> Agent accepts reservation and dials customer out (PSTN) -> Connect customer to agent (WebRTC)
For this, we will use Twilio Contact Center – Callback Voice Calling.json
To run this test script you will need to change the Service URL and the dial out number:
You can place your own phone number as the dial out number and answer it manually – or better yet – set a Twilio number for it, so the call gets answered automatically.
The easiest way to do that is by setting a TwiML bin/app to your phone number’s configuration under “A CALL COMES IN”:
To do that, you just need to create a new number or modify how an existing number you have is configured. You can do all that from the Phone Numbers section of the Twilio dashboard.
TwiML also gives you some powerful features with little effort on your part. We needed it for answering a call and putting some voice on the line, but it can do much more.
Inbound Voice Calling
Here’s the workflow we’re about to test: Customer calls Twilio phone number -> Twilio requests webhook -> Server generates TwiML for IVR -> Caller selects IVR option -> Task on TaskRouter created -> Find available and matching agent -> Agent accepts reservation -> Connect customer to agent (WebRTC)
For this, we will use Twilio Contact Center – Inbound Voice Calling.json
The tricky part this time is that we need to be able to get a PSTN number to dial in to our contact center at a very specific time when our agent is waiting in our test script. To achieve that, I created an AWS Lambda function. Once the REST API for that function is called, the function instructs a Twilio number to dial into our contact center.
Things we will need this time:
AWS Lambda function – here’s the code I’ve used. You will need to modify the first 4 constants in there:
authToken place your Twilio credentials (do not to share them with others).
fromNumber holds the Twilio number of the customer dialing to the contact center and
toNumber holds the Twilio number configured for the contact center.
You will also need to setup the Amazon API Gateway so you’ll have an exposed REST API that can invoke the AWS Lambda function.
Once ready, you will need to change these parameters in the testRTC test script:
I want to show you how this is taking place with the test script itself. If you scroll down, you’ll find this code:
In line 45, the Agent logs in to his console in the contact center.
Line 46 calls the invokeIncomingCall() function, which ends up calling the REST API that will cause the incoming PSTN call to hit our contact center.
Line 57 tells our agent to wait for the incoming call and accept it.
Next steps with testRTC and Twilio
We’ve seen how to use testRTC to dial a video call into a contact center, dial out to a PSTN number and answer an incoming call from PSTN.
I haven’t shown the dashboards, graphs and quality statistics that testRTC offers as a result of these test runs, but these details can make it a lot easier to find and fix bugs in your service.
You can take these scripts off our github account and configure them to fit your contact center implementation.
My suggestion? See how you can modify them to cover larger test scenarios, where calls get transferred between agents, calls get ignored or routed to specific agents, and then scale the test to 1000’s of agents in a contact center.
Tsahi Levent-Levi is an independent analyst and consultant for WebRTC, and a co-founder at testRTC. He has over 15 years of experience in the telecommunications, VoIP and 3G industries as an engineer, manager, marketer and CTO.