Lately, we’ve been focused on learning as much as we can about the Amazon Connect contact center service. This interest is driven not just by our partnership with AWS, but also by the rapid uptake in a complementary callstats.io Monitoring and Analytics service we launched last year. So, last month, our engineers organized a one-week Amazon Connect hackathon with the objective of identifying additional opportunities for callstats.io to complement the Amazon service with new capabilities of our own.
If you’re familiar with the 2-day boot camps run by Amazon Connect consulting partners in various cities around the world, our hackathon had many similarities but with a wider scope. After building out an Amazon Connect instance, the team broke up into 14 small groups, each focused on developing in-depth knowledge about a specific Amazon Connect capability. The groups dedicated their entire work-week to expanding their knowledge base. We wrapped the week with a company-wide meeting to share the results.
While we can’t disclose our future product roadmap, our engineers learned many lessons during the hackathon about how to deploy and leverage various Amazon Connect features. This article begins a series of blogs that share our experiences and insights for the benefit of other Amazon Connect users. This overview previews future blogs that will dive deep into various subjects.
To ensure all our engineers are familiar with the product, we began the hackathon by building a new contact center instance in the EU central region. This instance is incremental to an earlier instance built in the US east region. Amazon makes it easy for anyone to get started with Amazon Connect. It is a completely self-service, cloud-based contact center available nearly world-wide. Even the callstats.io engineers who were previously unfamiliar with the product were able to build a fully functioning contact center in minutes without help.
Designed to meet our own business needs, the contact center includes basic IVR functionality that captures caller attributes and uses them to route calls to two queues. We configured the system to record all calls. We implemented a courtesy call-back function that enables callers who reach the contact center outside normal business hours to request an agent callback.
Because callstats.io is a WebRTC monitoring and analytics company, we are particularly interested in the Amazon Connect Contact Control Panel (CCP), which uses WebRTC to exchange real time voice communications between the agent and cloud. Our team extended the basic CCP functionality with a station-station transfer capability, as would be needed for customer escalations.
Abundant Operations Data
Our interests ranged much wider than CCP and included a thorough review of the metrics provided by Amazon Connect for monitoring contact center operation. We found the system delivers on the open approach that Amazon promotes. An abundance of data is available through multiple APIs and the Cloudwatch console. Our engineers found the data easy to access and integrate into external applications. We’ll review some detailed API authentication and access insights in a future blog.
We noted the interfaces provide overlapping access to most metrics. However, certain metrics are available only through a specific interface, such as communications session metrics.
Amazon Connect Metrics API - Comprehensive data for agents and contacts
Kinesis Data - Data warehouse service based on Redshift that captures and stores contact trace records (CTR), agent logs and contact flows
Cloudwatch - Console presents the same data available through Kinesis (above) and includes an API
CCP Streams API - Collects basic communications and session metrics from CCP, which runs in the agent’s browser, or may be integrated into a web application using the API.
Significant Data Gaps
Of course, you’d expect we would compare the communications metrics provided by Amazon Connect against the metrics collected by our own WebRTC monitoring and analytics platform. We wanted to see whether Amazon provides the basic metrics needed to monitor call quality and troubleshoot voice communications problems.
Here, we found some significant gaps. Amazon provides data about basic session state, such as connection start/stop and ICE connectivity status. But, there is no detailed data for the media streams. We believe this is essential data for troubleshooting network and communications problems. We’ll do a deep-dive comparison between the available metrics in a future blog post.
The Agent Interface
As we mentioned earlier, our team took a special interest in the CCP. With over four years experience helping application developers create a wide range of WebRTC applications, we’ve got some strong opinions about how to build an easy to use and reliable communications interface.
Our engineers generated a long list of enhancements they’d like to see put into the CCP, ranging from richer call indicators to mechanisms for collecting call quality feedback. Given its current capabilities, our team believes agents and IT managers need to take special care to ensure customers receive the best possible call quality and experience using CCP.
Based on our WebRTC expertise, our team has developed a ten-point checklist that prepare agents to use the Amazon Connect CCP. We’ll cover this in a future blog post.
Our team concluded the hackathon excited about the possibilities to complement the Amazon Connect platform with our own services and create richer solutions for our mutual customers. We learned many lessons during and following the event which we’re glad to share with you. We think they will benefit the entire Amazon Connect user community and promote more rapid migration and adoption of its contact center service.