Easily monitor call quality with Amazon Connect
September 8, 2021: Amazon Elasticsearch Service has been renamed to Amazon OpenSearch Service. See details.
When managing your contact center, call quality has a significant impact on the customer experience. If your agents take calls on Amazon Connect using the softphone over the internet, the audio quality is typically high. However, changes in networking conditions can result in varying audio quality from factors such as increased latency or packet loss.
By capturing and storing real-time call metrics, you can proactively monitor call quality. In this blog, we describe a solution which captures real-time metrics from the Amazon Connect softphone, creates easily understandable dashboards from the metrics, and makes this data searchable for further analysis.
The dashboards give your contact center supervisors and operators insights into the customer experience from both a business and operational lens. They can help you answer questions like how many calls are abnormally short, how many calls experience poor audio quality, and other common operational questions. This allows your business to take actions to improve the customer experience.
The Amazon Connect softphone uses the WebRTC protocol, which produces metrics related to packet loss and latency. This solution deploys an open source implementation of a custom Amazon Connect softphone with extended capabilities to capture the WebRTC metrics.
Once the metrics are captured by the custom softphone, the data is sent to a backend system that processes, stores, and visualizes the data. If you have implemented your own custom Amazon Connect softphone, the solution also makes it easy to integrate with your existing custom softphone.
Call quality dashboard
This solution deploys two dashboards out of the box:
- A dashboard with metrics for business users. This includes the number of active calls, the number of calls experiencing high latency, and the number of calls with an uncharacteristically short duration.
- An operational dashboard with visualizations for more technical users with granular WebRTC metrics such as round-trip time and packet loss over time.
These dashboards are based on the WebRTC metric data that is transmitted by the custom softphone. The detailed data model can be found in this GitHub repository, so you can customize the dashboards to display metrics and aggregations relevant to your business. For example, if your agents are reporting that customer audio is consistently quiet, you can customize your dashboard to display the number of calls with audio levels less than a specific decibel value. If you don’t have a dashboard for a specific scenario, you can dive into any issue by exploring the data in OpenSearch.
In the two figures below, you can see the business user dashboard as well as the operational dashboard.
You can deploy the solution from the AWS Serverless Application Repository. Once the solution is deployed, agents answer phone calls via a custom softphone that is served by an Amazon CloudFront distribution backed by an Amazon S3 bucket. As the softphone captures WebRTC metrics, it publishes the data to an Amazon API Gateway endpoint. The API Gateway endpoint then invokes an AWS Lambda function that indexes the data into an Amazon Elasticsearch cluster.
Amazon OpenSearch Service is the search layer that enables you to perform complex searches over the collected quality metrics. OpenSearch Dasbhoards then lets you visualize and explore your data inside the Amazon OpenSearch Service domain.
Access to the OpenSearch Dashboards is controlled by an Amazon Cognito User Pool, which authenticates and authorizes users. You can create users inside the Amazon Cognito User Pool for the those who require access to dashboards and operational data such as call center managers and operations engineers.
This solution creates daily indices for the data that is inserted into OpenSearch. These daily indices allow you to manage data retention and storage tiering. This deployment uses default shard configuration (5 primary, 1 replica) and does not manage storage tiering and data expiration. If you plan to implement this in a production environment, be sure to implement data management practices with a proper shard strategy and Index State Management policies.