Amazon Connect is a managed, omnichannel cloud contact centre solution. The solution was born out of Amazon’s retail business needing a contact centre that would give their customers personal, dynamic, and natural experiences.
I wanted to take the opportunity to share my own additional direct experiences with Amazon Connect to highlight its value while also voicing concerns so that you can put countermeasures in place for your deployment.
The Good
The power of Lambda and the power of Lex
The most powerful element of Amazon Connect is that within a call flow, you are able to invoke Lambda functions, save their outputs to then build subsequent decisioning flows. This allows you to leverage your systems that are used to power other digital experiences within the call channel. Further to this, inputting keys on a keypad can be quite cumbersome, however building a natural language input using Amazon Lex as a voice channel input allows you to build rich decisioning with complex inputs.
Within the AWS marketing collateral for Amazon Connect, they speak of a flight booking system. This is one of the diagrams:
Here on the call, a CRM lookup is performed based on caller id to return a user identity. A subsequent lookup is performed on a fight system booking based on user identity. Then Amazon Polly responds back with a rich message. Input is then requested using Lex bot with a predefined Lex intents.
All in all this ecosystem is quite powerful and your call flow is now only limited to the lambas you can write, systems you can integrate with and the user experience driven largely by call flow logic and Lex.
The out-of-the-box Amazon Connect integrations
Amazon and its partners have provided integrations with tools like Salesforce and Zendesk. These integrations and marketplace solutions are a quick way to build in a call centre IVR into your existing CRM solution or ticketing system.
There is a predefined Zendesk / Amazon Connect pattern that allows you to build a simple inbound and outbound call flow that is backed into Zendesk as a CRM and ticketing system. This solution is further enriched by logging the transcript and voice recording of the call into the Zendesk ticket as well as attaching sentiment analysis of the call. Further, this solution also provides a way of seeing a live transcript with sentiment analysis in real time during the call itself.
It’s bloody cool
Using a drag & drop interface, it’s quite straightforward to build your own call centre logic.
Being able to drive your call centre IVR in such a flexible way unlocks new ways to deploy and validate your call centre call flows. It’s even possible to do canary call centre flows to provision that ideal call flow for your customers.
Using the user interface, you’re able to update call flows within minutes, save and publish. If the call flow is attached to an inbound number, the call flow execution is then live within 10 seconds.
The overall cost
The overall cost of Amazon Connect is very good. Here are some cost dimensions to factor in.
Baseline Connect Costs
Base inbound call usage
- $0.10/ day for claimed number (direct dial) and $0.005 /minute call usage (inbound)
- $0.39/day for claimed number (toll free) and $0.054/ minute call usage (inbound)
Therefore if you have 10 internal queues that each have a direct dial and a single toll free number that takes all the inbound calls with 20 hours a day call volume, your costs are in the realms of $2.50 a day for Connect.
Note – these are all USD figures
Other things to factor in are
- Cost of S3 storage for call recordings and transcripts
- Cost of Lex invocations
- Cost of Polly speech
- Cost of Comprehend and Transcript
I find the cost of Connect itself being an order of magnitude more than the associated services however.
Optional Extras
Amazon Connect allows you to build your own integrations or use Marketplace alternatives. The Marketplace provides a great set of pre-configured integrations at an additional cost. Ones that I recommend exploring are
- An IVR test suite (eg https://cyara.com/solutions/contact-center-testing/)
- An IVR monitoring suite (eg https://operata.com/)
- A payment gateway “bot” (if there are PCI-DSS call flows) (eg https://payshield.com.au/)
the bad
User management for SAML integrated Amazon Connect
Most of our customers have a central identity store for staff – for instance Azure or Okta. Amazon Connect supports SAML for user based identity authentication for call centre staff however it does not support any role based authorisation or any types of lazy provisioning from an identity store.
Instead, Amazon Connect manages users within its ecosystem and within the Connect ecosystem, accounts are attached to a role and security profile.
This therefore means you need to manage your call centre staff within both your primary identity store (eg Azure/Okta) and also within the Amazon Connect ecosystem.
It’s not all bad as Amazon provides APIs for user provisioning within Connect itself so writing some middleware to provision and de-provision users is possible, however it is just more work that would be better handled by the identity store and SAML claims.
Comparing this to how Zendesk manages authentication and authorisation it seems the Amazon Connect permissions model leaves something to be desired.
Most of the big iDPs provide a way to push user provisioning into the application – this is Azure’s example. All in all, everything is possible, however you must do that leg work yourself.
No overarching permissions model when integrating with other applications, like Zendesk
Further to (and to reiterate) the complaint about roles based access, an overarching view of permissions is missing particularly when integrating with third parties like Zendesk, Salesforce or similar. For these implementations you want to provision your user in one location and have their permissions flow through all of the associated systems.
Again, for Zendesk / Connect implementations, the call centre agent will spend their time within Zendesk using the embedded Connect softphone dialler. A business really wants to authenticate the call centre agent in one place and those permissions and access propagate down to the right systems. Unfortunately the only option is custom engineering work to poke and prod APIs to address what is reality a security concern for the business.
No hardware phone support
Amazon Connect (client) provides a soft phone pop up. It uses WebRTC for all of it’s magic, though I fear some places might miss that physical desk phone. The current option for those that want a traditional telephone is to, in essence, call forward their soft phone to a traditional telephone service using PSTN. If Amazon produced a desk IP based phone powered with PoE (power of ethernet) backed into Amazon Connect, I think they might attract more people onto the platform.
What do I need to whitelist on my corporate network?
Enterprises love to have tight control over their internal networks to minimise risk of data loss. Up until recently, the documentation of what elements to whitelist in Amazon Connect was very thin. Further, leveraging new web technologies like WebRTC to generate a reverse tunnel to drive telephony might result in interesting conversations with the local network and infosec teams.
Note – Amazon Connect doesn’t use SIP between the call client and Connect – it is all web traffic.
The following page provides detailed information around what network access is required for connect: https://docs.aws.amazon.com/connect/latest/adminguide/ccp-networking.html
Amazon provides a diagnostic site to validate your network connectivity that is linked from the page. The page fires local javascript to establish a TURN connection over WebRTC.
The page will provide a quick way to validate connectivity as well as the call quality (eg latency) that you will expect from your current location.
Lastly, Chrome in particular has internal instrumentation of WebRTC that can be used to validate connectivity. More details osf using chrome://webrtc-internals can be found here .
Call quality metrics over WebRTC
Amazon provides call metrics of call performance – however it is a broad metric from the perspective of the Connect instance and not specific to each agent.
Therefore, what does the metric even mean? What can you do with it? Not too much!
It would be nice to have per agent WebRTC metrics to allow call centre managers to identify agents with poor network connections. There are however some third party solutions on the market that do just this. One is from a Melbourne based provider called Operata that provides a method of being able to instrument each call for audio quality. In my view, Amazon Connect really should have a better first party solution in this space.
Call flow logic debugging
Amazon Connect provides a set of attributes that can be leveraged to build decisioning flows. This concept is further enriched by using Lambdas to return back additional attributes.
However there is a gap in not knowing what attributes are available during the call flow itself which makes the decisioning during the development phase hard. More generally providing a way to do local or ‘dry run’ call flows will help enrich the development process.
Missing configuration as code for Lex
When building rich call flows, you’re likely going to be using Amazon Lex. One big misgiving of Amazon Lex is the lack of Cloudformation support for the build, package and deployment. There are some positives as there are exposed API calls though being able to wrap them into a continuous delivery toolchain is highly tedious.
These tools are powered by boto3 API calls and therefore it is possible to define these steps within CloudFormation using custom resources however there is a risk of rework if the CloudFormation team ever introduces Lex support.
If you consider that Lex and Lambda will be the AWS services iterated upon to build really rich call flows encapsulating your business logic, you’d want support for continuous integration to be able to iterate upon your bot in a fast and safe way.
One final gripe with Lex is its concept of versioning. It is possible to name a version of a bot however the name is limited to letters only. Therefore it’s not possible to tag via a build number or git sha. This seems quite a basic flaw and representative of what appears to be the under investment of modern development practices in this space.
the ugly
Missing Configuration-as-Code for Connect
You’ve been using CloudFormation for many years and you’re asked to build out Connect. The first thing you do is look for the CloudFormation definition!
Unfortunately there isn’t CloudFormation support for Amazon Connect at all which is extremely disheartening. There are many parts to Connect that require governance including
- Creating and updating the Connect instance itself
- The trust relationships between integrated lambdas and services
- How to manage Kinesis Video Streams (for call audio processing) and Kinesis Data for instrumentation from the call centre
- Provisioning phone numbers into call queues
- Provisioning queues
- Provisioning users
- Provisioning user profiles
- Provisioning speed dials (quick connects)
- Provisioning call flows
There are some APIs for some of those components but it’s left to the end user to do the heavy lifting on management and management of Connect.
Leaning on my professional AWS Ambassador network as to whether anyone was aware of any APIs to build automation from, here were the Arjen Schwarz and Ian Mckay’s response:
Ian’s toolchain leverages a headless browser to ‘clickops’ key elements in Connect with a CloudFormation resource interface to them. It’s quite cool, but practically dangerous as it does not provide any committed consistent interface to leverage configuration-as-code.
This is not recommended.
Applying a lens of change frequency, most of those components are set once and use however there are a few that are generally iterated upon including
- The Lambda / Lex invocation permissions
- The Call Flows themselves
Amazon must do something here to close this gap!
Configuration-as-Code for Call Flows
As mentioned above, there is a lack of configuration-as-code support for Call Flows. The toolchain provides a way to import (and export) Call Flows, however this is such a critical aspect of Connect that misses the underinvestment.
Applying agile philosophy to the IVR, it is imperative to be able to make safe small incremental changes to the call IVR. The IVR supports A/B type testing and we want to use it safely.
There is a “least worst” method to address this critical issue – build your own toolchain.
The above diagram proposes an inhouse development effort to address this gap. By
- Creating a DSL definition of the importable Call Flow Json
- Using git and CI practices to test and publish
- Manually load the json into a pre production environment
- Run a IVR test automation suite
- Manually load the json into a production environment
- Smoke test
This requires real engineering investment to build this toolchain. There are some existing solutions on integration testing however. Cyara has a promising IVR test automation suite which can hook into this type of process.
Speech Synthesis Markup Language (SSML) support in the call flow
SSML is a standard way of enriching phonetics and is used to assist Connect correctly read out phone numbers, highlight important text and generally make the automated bot sound more realistic. For instance
Normal volume for the first sentence. Louder volume for the second sentence
The gap however is being able to save syntactically incorrect SSML and not notice. Then, when Connect gets around to playing that voice segment, it fails to process and therefore moves onto the “default” next flow. This, combined with the lack of configuration-as-code support then makes it very difficult to debug incorrect SSML during the build process.
Here and here are decent references for SSML. Note however that Amazon Connect does not support the full SSML definition – injecting audio as an example.
There are two useful tips to help debug SSML:
- Open the AWS Polly window to validate SSML prior to updating the Call Flow definition. This is the best way to tune the robotic voice
- Enable Contact Flow logging and identify the SSML event within he CloudWatch Log- and play that SSML in AWS Polly – this is the best way to debug broken SSML
Wait, It’s not all that bad
While this might come across as overly negative towards Connect, it is not intended to be. I think Amazon Connect is a fantastic product, however being aware of some of its misgivings can help you better plan and design your solution to avoid any one way doors you might come across.
For more background information, check out our solution for Amazon Connect here
