AWS Contact Center

Routing contacts based on external assessment of offline agent workload with Amazon Connect

Customer service departments where specialists answer incoming calls as well as perform back-office or offline duties (case processing, follow-ups, research, and troubleshooting), require different mechanisms for routing incoming contacts. Examples include mortgage originations, complex sales, and IT helpdesk to name a few. Most of these involve complex, multi-day, multi-step interactions with customers. The specialist workload is determined by the amount and complexity of the offline case work. As a result, businesses want to route incoming contacts to specialists who have the least overall offline workload, which is often captured in backend databases external to Amazon Connect.

The out of the box routing algorithms within Amazon Connect look at agents who are skilled to answer the incoming contact, and route it to the next available agent, or the agent who has been available for the longest time. The time spent on answering calls by agents is the primary unit of workload here. This is an efficient algorithm that maintains a balance between evenly distributing incoming contact handling workload, and optimizing service levels and response times for incoming contacts.

However, as artificial intelligence (AI) and machine learning become prevalent in helping make decisions, businesses will want to leverage custom models developed in the enterprise to make routing decisions. Whether this is based on matching the customer to the best agent based on their personality, or a combination of factors involving their account attributes, location, and relationship with the enterprise, the possibilities of unique routing requirements are plenty. Even without AI, rules-based engines can also be employed to determine the target destination of an incoming contact using a combination of user input in IVR, user account attributes, location regulations, and user preferences.

In this blog post, I will walk you through the steps to route incoming contacts to specialists who are handling the least amount of offline workload at that point in time vs. the standard routing algorithms of Amazon Connect. The approach can also be extended to n-best routing, where an external system returns a list of most suitable ‘n’ agents in a priority order, and Amazon Connect routes the contact to a specialist based on real-time availability in that order.


To follow along with the solution presented in this post, you need to understand the following AWS services and features:

To begin, you need an Amazon Connect instance configured for inbound and outbound calls. Claim a phone number after you create your instance. The Getting Started with Amazon Connect and Understanding Contact Flows documentation, and Getting started with Amazon Connect YouTube tutorial all provide valuable background knowledge for this process.

Solution Overview

When offline workload or external decision-making becomes a critical factor in contact routing, we can leverage the following capabilities in Amazon Connect to accomplish this:

  1. Ability to invoke an external system or backend to obtain candidate agents.
  2. Ability to determine agent availability real time within a contact flow.
  3. Ability to route a contact directly to an agent.
  4. Ability to recover from real-time error conditions and have the control to route the contacts to default queues (standard out of box routing as fall back).

In the above architecture, the following sequence of steps takes place for an incoming contact:

  1. Amazon Connect answers customer contact and invokes contact flow.
  2. Amazon Connect invokes Lambda by passing the customer id and type of the contact.
  3. Lambda checks in Amazon DynamoDB whether this customer is a new customer without any associated agent. If new, then Lambda returns a list of candidate agents for this contact type in ascending order of their offline workload.
  4. Amazon Connect iterates through this list of agents in received order, and routes the contact to the first available agent.
  5. If all agents are unavailable, the contact is default routed to the queue using out of the box Connect routing algorithm.
  6. For those contacts with an associated agent, Lambda returns and Connect routes to the associated agent for continuity of context, and good customer experience.

Step 1: Deploy CloudFormation template

The CloudFormation template below creates the following instances required for this solution:

  1. One Lambda function offlineWorkloadSimulator
    1. index.js – Main handler
    2. initializeDB.js – Initialize DynamoDB connectivity
    3. checkIfCustomerAssociatedWithAgent.js – Check if customer has associated specialist already (existing customer)
    4. findThreeBestAgentsBasedOnWorkload.js – Find three best agents to handle a new customer
  2. Environmental variables (AWS Region, table names, index name, default routing queue)
  3. 2 DynamoDB tables
    1. CustomerAgentMap (CustomerId, AgentName)
    2. AgentWorkload (CallType, AgentName, Workload)
  4. One IAM policy and one IAM role that allows the Lambda function to access DynamoDB, CloudWatch logs, and AWS X-Ray.
    1. customOfflineWorkloadSimulatorLambdaPolicy
    2. OfflineWorkloadSimulatorFunctionRole

Follow the steps below to deploy the template:

  1. Log in to your AWS Management Console.
  2. Confirm that the AWS Region selected has the Amazon Connect service available.
  3. Click on the button below Launch Stack
    Launch CloudFormation Stack
  4. On the AWS CloudFormation page, modify the stack name if you prefer a different one. You can keep the other options as default. Note that if you do change the stack name, the text in this document referencing the prefix offWorkRouting– will be inaccurate.
  5. Click the Create stack button after selecting all three check boxes.

Step 2: Populate data into DynamoDB

The necessary two DynamoDB tables were generated using the CloudFormation template. Below are the steps to populate test data into DynamoDB.

  1. In your AWS Management Console, open Amazon DynamoDB and choose Tables in the menu on the left.
  2. Choose offWorkRouting-CustomerAgentMap, then select Items tab, and click on Create item.
  3. For customerId, enter the phone number that you plan to use to test your completed contact flow and make sure to include the + sign and country code (i.e.: +19725550101), add a field called agentName and set a value of one of the agents you will be configuring to test this algorithm (for example, agent1).
  4. Click Save.
  5. Next, Choose offWorkRouting-CustomerAgentMap, the Items tab, and Create item. Click Save.
  6. Create at least four items as indicated in the screenshot below by choosing Create Item, populating the item data and clicking Save after each entry.
  7. The two values for callType allows you to test and ensure that this algorithm works for multi-skilled agents. The value mortgage-originations should match exactly as listed because the contact flow sends this value as a parameter to Lambda. If you need to use a different call type, you will need to change it in the contact flow Lambda invocation block as well. The data sample uses three agents (agent1, agent2, and agent3). These names should also match the actual agents that you will be creating in Amazon Connect later.

Step 3:Grant Amazon Connect permission to execute your Lambda function

To make sure that our Amazon Connect instance has access to this newly created AWS Lambda Function by following these steps.

  1. In the Amazon Connect console, choose Contact Flows and scroll to the bottom of the page in the AWS Lambda section.
  2. On the Function drop-down menu, select the offWorkRouting-OfflineWorkloadSimulator function and click on +Add Lambda Function, as shown in the following screenshot:

Step 4: Import and configure the Amazon Connect contact flow

  1. Download the pre-built contact flow.
  2. Click on the Overview tab and then click the Login as administrator button to log into the Amazon Connect console.
  3. On the left side of the Amazon Connect console, select Routing -> Contact Flows
  4. Click the Create contact flow button at the top-right.
  5. Click the drop-down at the top-right and select Import Flow
  6. Click the Select button and select the downloaded offlineWorkloadRoutingContactFlow file from Step 1 above.
  7. Click on the header for the Invoke AWS Lambda function block and select the Lambda function that you granted Connect permissions to in the section above.
  8. Save and publish your contact flow.

Step 5: Create agents in Amazon Connect

  1. In your Amazon Connect instance, choose the Users icon from the navigation bar, and choose User management.
  2. Click on Add new users, then Next
  3. Enter agent1 for Login name, select Basic Routing Profile from the dropdown for Routing Profile, and Agent from the dropdown for Security Profile. Enter values of your choice for other fields. Click Save. Click Create users on next page.
  4. Click on Create more users to repeat the above step to create two more agents (agent2 and agent3). These three agent login names should match the values in the Amazon DynamoDB tables populated above.

Step 6: Try it out

  1. In your Amazon Connect instance, choose the Routing icon from the navigation bar, and choose Phone numbers.
  2. Choose the phone number to associate with your new contact flow to edit it. Choose the name of your contact flow from the Contact flow/ IVR drop-down menu, and choose Save.
  3. Call the phone number you claimed.
  4. Log in to CCP using at least one of the agent logins (for example, agent2)
  5. Call from a number that is not in CustomerAgentMap table to experience new customer scenario. Log in as different agents to validate availability vs. least load scenario.
  6. Update the workload values in AgentWorkload table to test different load scenarios.
  7. Call from the number that is in CustomerAgentMap table to experience existing customer scenario.


  1. Note that the Lambda does not update the workload of the agent after routing. In a real situation as well, this aspect will be covered by the appropriate system that creates the ticket/mortgage application. In order to test different scenarios, you can change the workload values in the table to confirm that the system always routes to the agent in order of workload.
  2. In case of any error or inability to obtain the list of agents from the external system, this application needs a queue to route calls to. Every Amazon Connect instance comes with a BasicQueue. For simplicity, BasicQueue is used to route calls in error scenarios. Using BasicQueue also allows the use of BasicRoutingProfile for agents and overall reduces the configuration in Connect, which is not the primary focus of this article. You have the flexibility to create a new queue and a routing profile. Make sure that you update the queue in the contact flow.
  3. The Lambda function along with the DynamoDB simulates an external system. The contact flow invokes this simulator Lambda to retrieve a list of candidate agents, checks real-time availability of the agents in order, and routes the contact directly to the first available agent. In a real-life application, the Lambda would integrate with the external system to bring the data back to Connect for routing.


In this post, we implemented a simple approach for routing contacts, where the best agent choice is determined by a system or repository outside of Amazon Connect. This can be used to improve balancing workload across workforce. You can now use this solution in your environment, or even think big and use sophisticated machine learning algorithms on AWS to determine the best agent match for a given customer to improve both, handling efficiencies as well as customer outcomes.