Adventures in Amazon Connect
Detailing the pros, cons, and all the “gotchas”
Here at Soluto Nashville, we work extensively with Amazon Web Services (AWS). Some of the most important work we’ve done in the past year has been with Amazon’s new cloud-based contact-center service, Amazon Connect.
With Amazon Connect being such a new service, there’s slim documentation available so we’ve had to learn many of the “gotchas” on our own through trial and error. In our experimental approach, we’ve seen both benefits and drawbacks along the way. Let’s take a look at some simplified use-cases to highlight what Connect has to offer and what it’s still lacking in its early stages.
Additional documentation can be found here.
The Basics
Contact Blocks
Amazon Connect is a visual editing tool which outlines the logic needed to manage the experience a customer undergoes when calling into your place of business. Connect manages this experience in Contact Flow which must be be created and configured from the Amazon Connect console. These flows contain a variety of ‘Blocks,’ which are organized into five different categories (which Amazon refers to as Contact Blocks). These tools are generally standard among contact-center services–they allow for interactions with the customer, setting attributes/queues, and performing basic logical operations, among other things.
Although these tools are standard, the benefit of using Amazon Connect comes from being able to take advantage of the AWS ecosystem, using tools such as Lambda for integration and data manipulation, Lex for smart routing, and IAM roles for ensuring that these tools are only accessible from Connect.
One of Amazon Connect’s main benefits is its integration with AWS Lambda. This direct integration allows you to easily secure data operations through the use of generic or detailed function policies, as well as allows you to avoid exposing REST APIs that need to be secured. Lambdas can be configured to be triggered generically from any Amazon Connect contact flow, or can be more finely tuned to only allow integration from a single Amazon Connect instance using AWS Lambda function policies.
In order to begin directing calls to a Contact Flow hosted in Amazon Connect, you must first claim a number and link it to that Contact Flow. Pricing varies based on region, but is determined based on how many numbers associated with the Amazon Connect instance, as well as the length of time the customer was on the call.
Example
Here’s a simple example of what a Contact Flow may look like…
This initially invokes an AWS Lambda function which retrieves information stored in ElastiCache about what types of issues the caller intent Lex bot understands. If successful, it saves the output to an attribute called ‘defaultSpeech;’ if it fails, a static value (in this case, it says ‘Please state your issue’) is set to the defaultSpeech attribute.
After the defaultSpeech attribute is set, the Lex Bot is then invoked. Depending on the customer’s vocalized input, the Lambda connected to the Lex Bot may take some additional actions on the backend. If/when the ‘PurposeIntent’ match is made, the response from the LexBot is saved in the ‘customerIntent’ attribute, and the customer is transferred to another Contact Flow for further processing.
If the customer indicates that they need help, the data stored in the ‘defaultSpeech’ attribute is read to the customer.
If the customer does not say something which matches one of the intents the Contact Flow is attempting to match, or at any point there is an error (or, if the customer indicates that they wish to speak to an agent) the working queue is set, and a reoccurring attempt is made to transfer the customer to the working queue specified until there is vacancy in that queue. If that attempted transfer happens to fail, the call is terminated, which is never ideal!
User Management and Transfers
Agents can be added and managed in Amazon Connect under the ‘User Management’ tab. Here, an agent’s login username, first and last name, email, security profile, routing profile and desk phone number can be managed.
The routing profile that an agent is assigned to indicates which queues they belong to, and what the priority of each of those queues are in relation to the routing profile. When you set a queue flow to transfer a customer to, the customer will be transferred to someone in the routing profile with that specified queue in the priority specified in the routing profile.
When a call is transferred to a queue, agents who have a routing profile associated with that queue and who have an ‘Available’ status can receive the call on the phone number specified in their user profile. This number can either link to a desk-phone/handset, or a softphone; the agent can specify their status (such as ‘Available,’ ‘On Break,’ or other customized statuses) as well as take and transfer calls (among other things) through the Amazon Connect Contact Control Panel (CCP) which can be embedded in the application used by the call-center agents by using the Amazon Connect Streams API.
More information on the Amazon Connect Streams API and setting up the Amazon Connect CCP can be found in the Amazon Connect Streams Github repository and the online documentation.
Security
Additionally, integrating Amazon Connect with AWS Lambda and IAM roles allows you to transfer and manipulate customer information without stressing about securing your REST endpoints.
Although you should always consider security in your application, because the AWS Lambda invoked from Amazon Connect is set up with a policy to only accept requests from the particular Amazon Connect account in which this request originates, your requests are very safe compared to a similar REST call. There is no need to worry about securing publicly available endpoints from DDOS or injection attacks.
In addition to this, when you set up your Amazon Connect instance, you are able to set up how you want to manage your Amazon Connect users. These options allow you to manage users through SAML based authentication, link to an existing directory associated with your AWS account, or manage users in Amazon Connect directly (meaning, the managed users will have a username and password specific to Amazon Connect). This means that you can spend less time worrying about security, and more time focusing on the architecture of your application.
Pain Points
Integration
As of right now, Lambda is the only ‘integration’ tool that Connect provides; but, due to the flexible nature of AWS Lambda, you can do nearly anything imaginable with this single integration tool. Unfortunately, this means that you cannot integrate with REST APIs directly within the contact flow.
Although it is easy to set up a proxy Lambda to gather data from S3, DynamoDB, ElastiCache, etc. it would be nice to have the option to integrate directly with more of these services. In particular, I would like to see the ability to directly initiate a step function by ARN from Amazon Connect.
Documentation
The documentation on Amazon Connect is sparse. Due to this, some issues may arise which take much longer to diagnose than they should, leading to a lot of time lost on simple task. For example, it took us much longer than it should have to find diagnose that complex nested data objects are not yet supported in Amazon Connect. We were forced to find a work-around to such issues by flattening the data and using ‘dash’ notation in our key names. That is, accessing the value stored at the key value ‘foo’ in the nested object ‘data’ is done writing “data-foo” rather than “data.foo” or “data[‘foo’]” as one would expect.
This is documented–but it was not our first thought when initially debugging.
Integrated Logical Operations
Another shortcoming of Amazon Connect is the lack of supported mathematical operations. The team I’m on was in need of checking an external cache several times before terminating a call. The cache was populated with data based on a customer action, and as such, we wanted to act as close to real time as possible while we waited for them to take the action. To do this, we wanted to loop for a minute, check the cache, and terminate if/when the customer took this action.
We thought this sounded like a simple enough task, but Connect does not support looping based on time with a condition. We could put the customer on hold for a minute and then check the cache (keeping the customer on a one minute hold regardless of whether the action was taken or not), and we could loop over some condition (the counter logic had to be put in AWS Lambda) and take an action based on the result; but, we could not mix the two.
Small things like this make us think more simply about what we can quickly and easily achieve in Amazon Connect; which is unfortunate since the rest of Amazon Web Services tend to allow us to think about doing more complex things than having on-prem resources would allow us to.
CI/CD
By far the biggest frustration we’ve had with Amazon Connect so far is that, at this time there is no API for creating Contact Flows, nor is there an API to import JSON representation of Connect Flows. This makes integrating your IVR configuration into continuous integration (CI) platforms near impossible. In addition to this, the Contact Flow configuration language is complicated and includes data not needed by whatever CI tool you use, such as the x and y coordinate of the contact block the configuration represents.
That’s not to say Soluto Nashville isn’t crazy about Amazon Connect. The direct integration with Lex and AWS Lambda liberate us in a lot of ways. But there are still some kinks to be worked out and a few features we’re eager to have added.
