Amazon Connect provides a great way to get up and running very quickly by using the Graphical Interface with Drag and Drop design, however we have found that most phone lines across our multiple clients tend to all utilise the same feature sets/patterns, which often results in repetitive contact flows with only minor differences.

For example, a client may have 50 different phone lines, however they all play a slightly different Welcome Message, Call Steering Menu, or go to a different queue but play the same prompts throughout the customer journey. This would result in either 50 different contact flows, or a smaller subset, but lots of IF THEN ELSE logic, making the contact flows unreadable and gigantic.

We use a small set of “Core” contact flows which handle the majority of common features used in a customer journey, allowing you to scale from 1 to Infinite phone lines without having to amend a single contact flow. Some of these features in the Core flows include:

• Welcome Prompt – Wording to be played to the customer via Text to Speech, SSML or Recorded Prompts stored in Connect or S3.
• Default Queue – For the number that has been dialled, determine which queue the call should be allocated to; though it can be changed further through the journey via other routing logic.
• Call Steering Menus – Provide IVRs to customers using JSON configuration to determine the settings for the menu, including prompts, options available, where each option goes once selected etc.
• Queue Configuration – Based on the queue selected, determine its Call Recording, Analytics, Redaction, Screen Recording settings along with custom Agent Whispers.

‍

Overview

This blog will walk you through deploying a subset of these Core flows to illustrate the approach we take in deploying Contact Centres at scale, quickly, and with low risk.

A CloudFormation Template will deploy a DyanmoDB table to store data that will be retrieved by the Contact Flow via a Lambda function. Wilst we have given a set of pre-defined attributes which can be used by the Contact Flow, you are able to add anything you wish without having to amend the code, allowing you to quickly develop and add new features to the contact flow which are then made available to the entire contact centre without duplication.

The components we’ll use are as follows:

• Amazon Connect
• Lambda
• DynamoDB

‍

Prerequisites

• An AWS account with access to the services mentioned
• An Amazon Connect instance, configured and taking inbound/making outbound calls

Deployment  

1. Obtain the Infrastructure as Code from the following repository: https://github.com/Cloudnteract/ci-blogs-connect-dynamic-flows ‍

2. Create a new CloudFormation Stack using the template `.\src\cloudformation\cfn-connect-dynamic-flow-data.yaml`, this will deploy the following resources:

a. DynamoDb Table for Contact Flow Data to be stored

b. Lambda used by the Contact Flow to retrieve data to be used

c. Core set of Contact Flow Modules/Contact Flows

d. Some example Delivery Numbers, Queues and Hours of Operation to be used as part of this guide (can be omitted if you wish to use your own resources)

3. Create a DynamoDb Item for each JSON file: (DynamoDb Table Name can be found in Stack Outputs: oDynamoDbTableConnectFlowDataName)

a. .\src\dynamodb\DeliveryId\: Updating the Primary_Key to the Delivery Phone number claimed in your Connect Instance (in e.164 format)

b. .\src\dynamodb\Queue\`: Updating the Primary_Key to the Queue Name (each Queue should have its own item in DynamoDb)

c. `.\src\dynamodb\SteeringMenu\`: Updating any destinations that require a ARN (e.g. Queue/Contact Flow ARN's)

‍

‍

Walkthrough

Now that we have the resources deployed, we can walk through how to utilise the features provided and how to create different journeys based on the number the customer has dialled.

A description of each Attribute and expected values can be found in .\dynamodb-schema.md

‍

CloudInteract_Core_Initiation

This is the starting point; all Delivery Numbers should be pointing to this contact flow. When a Contact arrives at this flow, we enable logging and set a default voice then trigger a Lambda to fetch the item from DynamoDB using the Sytem>Dialled Number attribute. The response data from this Lambda is then used in the rest of the flow, including setting what the default queue for this contact should be.

Once we have set the working queue, we attempt to play a Welcome message, followed by an Ad-Hoc Welcome message (a message which can be quickly amended without impacting the normal Welcome Message). To do this, we first check to ensure the attribute exists and has a value; if it does, then we pass it through to a Play Prompt Module which plays the prompt based on the value inside. It support Text to Speech, SSML, S3 and Prompt ARN values.

In our example we set “Prompt_DeliveryId_Welcome” to play “Welcome to Sample Department” via text to speech, and “Prompt_DeliveryId_WelcomeAdHoc” as an empty value so will follow the “$.Attributes.Null” path since they are both empty.

‍

‍

Once these prompts have been played, we determine what should happen next, we have configured the following options:

• steeringmenu – Play the customer a prompt advising of the options available, then route according to the option selected.
• flow – Go to the Contact Flow ARN given, ideal for journeys which are unique and not covered by the other options given here.
• disconnect – Play a prompt (optional) and disconnect the contact.
• external – Dial out to an external phone number and transfer the contact.
• queue - Go to the Queue ARN given (or the default queue if none given).

In our example we set Flag_DeliveryId_NextActionType as steeringmenu, meaning we will go to the Call Steering Menu flow and pass through the value of Flag_DeliveryId_NextActionValue, which is SampleDepartment_Retail, as our call steering menu name.

‍

‍

CloudInteract_Core_SteeringMenu

After using a Lambda to fetch the Item from DynamoDB based on the Steering Menu name, we play a pre-menu option which is non-interruptible, followed by the interruptible menu prompt.

Once the customer has selected their option (or not), we determine which option was selected and copy the corresponding values to a central set of keys, for example if Option 5 is selected, we take the Type/Value/Prompt from Flag_SteeringMenu_NextActionXXX_5 and place into Flag_Flow_NextActionXXX .

‍

‍

We then play a prompt if one has been configured, followed by sending it to the destination of that option selected, as we do in the Initial contact flow. If no option was selected, or the selected option was not configured in DyanmoDB, the flow checks against the number of retries and if this is exceeded, the Default option is taken.

‍

‍

CloudInteract_Core_PreQueue

The PreQueue flow is the final destination before placing the contact in the queue. This should ideally be the only flow which has the “Transfer to Queue” block to ensure all contacts follow the same logic before being placed into the queue.

We fetch the Item from DyanmoDB based on the currently assigned Queue Name, some of these attributes are stored as User Defined as they will be used outside of this current Contact Flow (e.g. The Agent Whisper). Once we have the Item, we check to ensure the contact is in hours, if not, it will route to the out of hours destination (similar to Initiation contact flow).

‍

‍

From here we invoke the Recording Analytics Behavior Module to determine if calls should be recorded, redacted, analysed and screen recorded based on the data from DynamoDB followed by playing a prompt before placing into queue and setting the Agent Whisper Flow to allow for a custom whisper to be played.

‍

Conclusion

Dialling the number you configured to deliver to the Initial Contact Flow, should now route according to the data you have stored in DynamoDB. You can now add/amend data to these tables and have the customer journey updated in real-time without having to amend the contact flows for already configured features: meaning you can create as many phone lines as you require, without worrying about managing and maintaining an enormous amount of Contact Flows. For features not currently provided by this blog, they can be added to the existing flows and enabled/utilised via the DyanmoDB item, meaning you can role the feature out to all existing phone lines once, and only need to update data to enable/disable them instead of re-deploying the feature to X amount of contact flows.

‍

Ian Hartwell

Contact Centre Solution Architect at CloudInteract

‍