By harnessing the power of data stored in your CRM system and integrating it into your call flows, you're able to create a highly personalised journey for each customer. This not only enriches the experience for both agents and customers but also ensures that interactions are more meaningful and efficient.

There is a brilliant CTI connector already on the market which allows the integration between Amazon Connect and ServiceNow (SNOW) out-of-the-box. It gives you a great starting point for us to build upon and start to integrate Amazon Connect and SNOW. For the purposes of this demo, this is the point we will be starting from.

‍
Pre-Requisites

1. An AWS account with access to Lambda, Amazon Connect, Lex, System Manager.

2. An Amazon Connect instance.

3. A ServiceNow instance with the Connect CTI Adapter configured and you have admin access .

4. A phone number within your Amazon Connect instance.

5. Have the ServiceNow Voice for ITSM Plugin or ServiceNow Voice for CSM plugin installed (Optional).

Note: For 3, if not set-up, you can sign up for a free developer instance of ServiceNow and use the documentation to set-up the CTI adapter. For this blog we are using the Vancouver version of SNOW.

‍

Overview

Once you set-up the integration between the two systems, you will notice a number of features are deployed on both applications. The following are key ones we are going to refer to as part of this blog, so make sure you have access to view the contents of both.

1. Credentials stored in the parameter store with AWS Systems Manager

2. The interactionEvent handler in ServiceNow

The Scenario  

A customer recently opened an incident and would like to hear the latest update on their ticket. They would also like to be transferred to an Agent afterwards.

‍

Walkthrough- ServiceNow

As part of the CTI integration, whenever an inbound or outbound call is placed a interaction record is created. One of the handlers involved in this process is the interactionEvent handler. You can navigate to All > ServiceNow Voice Core > Operation Handlers to find it.  

TIP: When you implemented the CTI integration, aspart of that you are given an example contact flow for Amazon Connect. Use the Invoke Lambda Block in that flow to validate the name of the interaction handler to invoke. If there is a mismatch, ensure you’ve installed all the components of ServiceNow Voice for Amazon Connect. Seek the ServiceNow documentation for more information of the components installed.

For this blog, the part we are interested in is the values this script returns if a user is found by their phone number. The following fields are returned as attributes when we invoke this handler via the Lambda function in the flow:
‍

‍

The SNOW system ID (sysId) is an important variable for us as it is what we can use to identify a user and search for any information we want to retrieve.

‍
Part 1 of Building the Amazon Connect Flow:

Now, lets start to build out our contact flow and initiate the lambda function that will retrieve those details for us.

1. Add set logging and recording behaviour block

2. Select the Lambda Function that you get from the CTI integration, it usually takes the format of  ‘sn[ABCDEF]Lambda’.Ensure to add the two function input parameters as well.

‍

‍

3. After the invoke, we are going to add a set attributes block and set the following attributes on the current contact. The key value is what we will use in the flow and our future lambda functions, so please feel free to change these to what you’d prefer, this is just an example.

‍

4. Next, we will place a check attribute block. This block is going to check if we know the user or not by checking on the sysId attribute. We will check on the value USER_NOT_FOUND.

5. Finally, we will branch to two play prompts. One will personally greet the caller, “Hey, $.Attributes.firstName, welcome to our Amazon Connect& ServiceNow Demo!”. The other will be a standard greeting. “Hey, welcome to our our Amazon Connect & ServiceNow Demo!”

Your contact flow now should look something like this:

‍

Creating the Lambda Function

Now we are ready to tackle the next part. At this point, if the customer is known to us, we can take advantage of knowing their unique ID. This is what we will use in our API call.

Our Lambda function is required to search for open incidents based on the user's sysId. It should disregard any incidents that have already been closed.

‍

Step 1: Understand the fields for your request

A helpful approach is to utilise the ServiceNow UI for crafting the request, aiding in the identification of technical field names. To begin, we will navigate to All> Incidents. Using filters, we will specify our request to include the following criteria:

1.       State is New, In Progress or On hold.

2.       CallerID is SysId of the caller

Tip: To manually find your sysId, navigate to the User table and click the user you are wanting to view. Copy the URL, the sys_id is in the inside of the URL, after the parameter sys_id.

Once you have created your request, click search and copy the URL and save it in your notepad to use later. Secondly, right click on the filter bar, click copy query and save in your notepad as well.

‍

Step 2(Optional): Use Postman to validate your request works

For this step you will need the following:

1. Credentials:Create a user in ServiceNow that has the permissions to make API calls

2. Your ServiceNow Domain

3. URLPath: /api/now/table/incident

4. QueryParameters

For this blog, we are referring to the Table API. I have personally found the ServiceNow documentation to be really useful and detailed.

The set-up may look something like this:

‍

Step 3: Put it all together in a Lambda Function

This is an example of how you can lay out your code.

For line 63, you can use your previously copied URL from step 1 or turn your postman request into a cURL request, to help with the formatting of the path.

‍

Create a LexBot

All we need for this part is a simple Yes Or No lex bot. For this, I created a Lex Bot that has two intents: Yes and No. Put a few variations of ways to say yes and no for the recognised utterances. Make sure to add it to your Amazon Connect instance so we can use it in the flow.

If you prefer to use DTMF you can skip this stage and configure the flow accordingly.

Part 2 of Building the Amazon Connect Flow

Let's put it all together.

1. Insert a new invoke Lambda block, select your newly created Lambda function and add the sysId as a input function parameter.

2. Set the returned attributes; incident, comments and state.

3. Check on the incident attribute if we have an incident open for the caller.

4. Add a get customer input block and add the Yes/No lex bot you created. “We have one open ticket for you, would you like to hear the latest update?”.

5. Play the latest update: “The update on your ticket is $.Attributes.comments”.

6. In this flow, all paths end up to another Get Customer input block with the Yes/NoLex Bot added. It presents them with the question “Do you want to speak to an agent?”. If they say ‘Yes’ we transfer them to the queue, if they say no or don’t respond we end the call.

7. Save and publish your flow.

‍

‍

Test

1. Navigate to All > User Administrator > Users. Create a test contact in SNOW and assign the phone number you are calling from to either the BusinessPhone or Mobile Phone field and click Submit.

2. Confirm your user is added to User Table.

3. Next, we need to create an incident. There are several ways you can create an incident, but for now we will navigate to All > Incident > Create New.

4. Fill in the new record and ensure you have theCaller field assigned as the contact you created in step 1. Remember, the state can be anything but ‘Closed. for this example. Then click Submit. An example of a record can be seen below:

5. Next, add a public comment to the incident, this is what we will expect to hear on our call.

6. Ensuring you have linked the Amazon Connect phone number to flow you have created. Make a test call to validate it recognises you and the latest update is read out. For this example, we would expect to hear “Hey Charlotte, the update on your ticket is Email sent out to user with password reset link”.

‍

Summary

‍
This blog serves as an illustrative example of leveraging SNOW data to automate call flows within Amazon Connect. The scenario presented here demonstrates a simplified 'happy path' where a user has only one open incident and a single update provided. However, in real-world scenarios, customers may have multiple tickets open simultaneously or numerous comments added at various points in time. This complexity is something you may want to keep in mind when developing your code for production. Integrating user authentication for an added level of security could be something else to consider.

Overall, the CTI connector serves as a robust starting point, affording us the flexibility to innovate upon the foundational configuration, enabling us to creatively develop logic tailored to our business requirements.

Please feel free to reach out to the team here at CloudInteract for further thoughts and discussions on how we can integrate ServiceNow with Amazon Connect.

‍

Charlotte Laundy

Contact Centre Platform Engineer at CloudInteract