Before joining AWS, one of the services my company provided was building Enterprise Contact Centers for customers. We had been doing it since 2004, right about the time VoIP revolutionized Contact Centers in favor of TDM based solutions. Having worked with Amazon Connect in my lab for a while now, I believe it to be another leap forward, another evolutionary change in Contact Centers. This post will try to compare and contrast the different components of the Contact Center between Connect and the legacy systems I worked with while giving a practical example of how Amazon Connect works.
Deploying the Contact Center
Deploying Connect and taking calls was very easy to do. Granted, I already had an AWS account. If I did not, it would have added another few minutes to create, and no other AWS services are required to be configured. Once logged in, there are a number of ways to access the Connect service, I select if from the A-Z list of services. Once on the Connect dashboard, I click the blue "Get Started" button. The prompts are very simple: I give it a directory name for identity management (created and managed by AWS), create an administrator account, enable incoming and outgoing calls via checkbox, accept the default S3 bucket connect creates for logs and recordings and create the instance which takes about a minute to provision. Next, I hit another blue "Get Started" button, claim a phone number (Direct Dial or Toll Free), and that's it! The Contact Center is now deployed. An agent tool automatically launched allowing me to take calls from the default queue. The other defaults are fine for now, I'll build out a sample IVR and Queue below, but from the dashboard, I can configure: Hours of Operation, Queues, Prompts, Contact Flows, Routing Profiles and users. The best part? Building all of this did not require any capital outlay. In other words, I didn't have to purchase servers, switches, software licenses, operating systems, hypervisors, UPS, cables or even phones. A full functioning Enterprise Contact Center was deployed without spending any money and investing just a little bit of time.
Here are some of the steps I would have gone through to Deploy the Contact Center in the old days of 2016. These steps are not necessary in Amazon Connect:
- At least 5 servers/switches would have been needed: Contact Center Management, System Management, Call Control, Trunk Management and Call Recording. The sizing of this system would require Solution Architecture and Sales Engineering, calls to distributors or manufacturers to configure, installation of the operating system, rack and stacking including power and cooling, integration with directories and network configuration. Engineers smarter than myself would need to be dispatched and it would take significant effort to get working. The phone system, contact center and call recording are really three separate systems.
- Redundancy (N+1, etc) and Backups were always a concern. The system would need to have extra components procured and provisioned to account for failures. Anticipated spikes would also require additional capacity to be provisioned to accommodate the spike. The numerous directories (configurations, call recordings, logs, call detail records, prompts, etc) would need to be backed up reliably.
- The infrastructure would need to be managed on an going basis. This included such tasks as patching, anti-virus, managing failed components, cooling, power, etc.
- The phone numbers and dial tone for the Contact Center would need to be provisioned. A services provider would need to be selected, and they would need to provision multiple circuits into the call center. Vendor meets would need to be scheduled to coordinate the activation of the circuits and signaling compatibilities. This could take 4-6 weeks and hopefully the circuit is clean and reliable and doesn't go down in bad weather, nor have problems with the smart jack inside the premise. An existing, or new, phone system would need to be integrated to route the dial tone from the carrier to the Contact Center.
- Separate 800 services would need to be procured and provisioned to point to the lead number in the call center.
- The agent software would need to be deployed on each agent's station. This would require an msi pushed out through active directory and minimum requirements to be met.
Configuring the first Contact Flow
Creating the first Contact Flow (Connect nomenclature) was really easy. There were 19 sample Contact Flows to start from which provided some great examples. I used the contact flow editor to create an IVR which answered the call from the inbound dialed number, read 2 choices to the user from the text in the action block, sent the caller to an agent if 1 was pressed and dipped to a Lambda script if 2 was pressed. Here is what the completed Contact Flow looks like:
The first action box plays a prompt and reads the text entered (more on that below). The second action box "Get customer prompt" reads text as a prompt and takes as input DTMF tones (buttons pressed on the phone) and then based on the numbers pressed, branches to another contact flow.
In the Transfer to flow action box, the contact flow branched to is selected, see below for an example:
Finally, I went to the phone number in the phone number section and assigned it to the contact flow created above:
Prompts
Creating and playing prompts is refreshingly easy. In the "Play Prompt" action block, which the contact flow is linked to via the contact flow editor. Clicking on the Play Prompt action box brings up a configuration panel. From here, I select Text to Speech, and the Text entered is actually read to the caller using AWS Text to Speech (TTS). The Set Voice action block can be used to select from 24 different languages, and based on the language, different voices can be selected. A prerecorded prompt can also be selected from an S3 bucket. Here is what the Play Prompt action block looks like:
In the old systems, text entered in prompts was only used for information purposes, it wasn't read to the user via TTS. Instead, it was a cumbersome process of having a professional record prompts, name them properly, upload them to the prompt folder and then link them to the prompt to be played to the caller.
IVR through Lambda
One of Amazon Connects greatest features is it's ability to leverage AWS Lambda to build applications into the IVR. This was also very easy to do. As noted above, option 2 of the contact flow calls a Lambda function which will speak back the phone number dialed from, in other words, the inbound DID. Lambda and Connect are very powerful together. In the older system I worked with, call control was provided from a separate system than the Contact Center system. They were lightly integrated, but not to the extent Connect and Lambda are integrated. One aspect of the old system is that applications could only be connected via ODBC and the IVR could only dip into external applications via SQL commands sent through ODBC. This made it very difficult to program because so much, including state, had to be managed within the third party application database tables. With Amazon Connect, any application or system can be called by using Lambda and variables can be set and passed into the Lambda function and then passed back out. Setting is very easy using the "Set contact attributes" action block. It is impressive how many variables of the call detail record are available to the Lambda function on a global basis, which can be viewed here: http://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html
Creating the Lambda function was easy:
- Went into the Lambda console in the region the Amazon Connect instance is configured.
- Named the function readphone, chose node.js 6.10 and assigned a role that would provide lambda_basic_execution.
- Noted the arn of the lambda function, the arn of the connect instance and the AWS account number.
- Followed this document http://docs.aws.amazon.com/connect/latest/adminguide/connect-lambda-functions.html to created a resource policy via the AWS CLI to allow Amazon Connect to invoke the Lambda function, it looked something like this: aws lambda add-permission --function-name function:readphone --statement-id 1 --principal connect.amazonaws.com --action lambda:InvokeFunction --source-account
123456789012--source-arn arn:aws:connect:us-east-1:123456789012:instance/def1a4fc-ac9d-11e6-b582-06a0be38cccf - Entered this code into the actual function code window in index.js:
'use strict';
console.log('Loading function');
exports.handler = (event, context, callback) => {
const phoneNumber = event.Details.ContactData.CustomerEndpoint.Address;
const state = phoneNumber;
callback( null, { State: state } );
return;
};
Here is what the Lambda contact flow looks like:
Lambda with Amazon Connect as an IVR is very powerful and very simple. Variables can be set from within Lambda which can then be seamlessly accessed by an action block. In the case of this example, a prompt to read back the number. The following step of the contact flow reads the variable callerNumber set in the Lambda function by simply using the "$.External." reference. Note below the first image is the Lambda console, see where the variable is passed back from Lambda in the code:
callback( null, { callerNumber: phoneNumber } );
Note the second image is the Play Prompt action block and see where the variable is accessed and then read to the caller: <speak>Your phone number is <say-as interpret-as="telephone">$.External.callerNumber</say-as></speak>
Lambda console:
Play Prompt action block:
Agents
The agent tool is web based (although can be configured to use a deskphone). It installed very easily and agents are able to accept calls immediately. In the old system, this would require an agent client to be installed on the computer with operating system dependencies and OS by OS availability. With Amazon Connect, the agent goes to a URL for the Amazon Connect instance and logs into the queue. The agent functionality includes all that is expected, including listen-in, wrap-up and robust supervisor/agent interaction.
SSML Integration
The older system I worked with was able to read back digits in a simple computerized manner. It wasn't able to exert control over how speech is generated from the text provided or dynamically generated. On the other hand, Amazon Connect supports Speech Synthesis Markup Language in a number of places, which is on top of the ability to set languages and voices before reading the prompt. According to Wikipedia, SSML is an XML-based markup language for speech synthesis applications. In the IVR connect flow mentioned above, one of the action blocks would read back the phone number generated by the Lambda call in the previous action block. When "interpret as" was set to "text", it read the phone number as a number so it sound like +1 2,412,254,786 "Plus twelve billion four hundred twelve million, two hundred fifty four thousand, seven hundred eight six". After changing "interpret as" to SSML, the number was read as a phone number with each digit read individually and pauses after the "-" in the phone number. The SSML in the action block looks like this (notice the variable passed back from the Lambda call in the previous action block): <speak>Your phone number is <say-as interpret-as="telephone">$.External.State</say-as></speak>
Here is what the action block looks like:
Comparing Connect to other Cloud Contact Centers
There are other Cloud Contact center solutions on the market and I have also worked with a number of those. Amazon Connect has significant advantages to these other providers. Many are run as traditional phone companies which means they lock you in to long term contracts. Amazon Connect, as with other AWS services, can be consumed on an On-Demand basis where only what is used is paid for. There is no commitment and the Contact Center can be turned off at anytime, or simply calls aren't routed to it, while all of the programming is preserved so it can be used again at anytime. It will always be available without incurring charges except when it is being used. Other Cloud Contact center solutions are hard pressed to keep up with the pace of innovation from AWS. Amazon Connect integrates with all of the other AWS services, including Lambda, Lex, Polly, S3, Analytics, Dashboards, Machine Learning, Artificial Intelligence, Bots, etc. By doing so, the Amazon Connect based Contact Center can be natively extended using these services in ways that the other providers cannot.
