SMS Return Message Routing
In part 1 of this blog we looked at three options that enable an Agent to make originate an SMS message:
- Option 1 – User a TASK Template
- Option 2 – Create an HTML Form (DrVoIP favors this approach)
- Option 3 – Create an Email to SMS solution
The key flows in any of these solutions, is to write the Send_TO_Number, smsMessageContent, AgentID (extension number, login, username), and timeStamp to a dynamodb table when originating and outbound SMS. This is possible with all three solutions, but we like option 2 the best. Option 1, with all of its strangeness has the advantage of being an action taken within the contact center, making a historical record more practical. The other two options, start outside the call center and the origination event is not noted for historical records in the out of box archive methodology of the Amazon Connect Instance.
Option 1 Task Template launches Contact Flow
The TASK solution gets the Origination SMS job done and works just fine. The Contact Flow the TASK points to contains an invoke Lambda that sends the messageContent and phoneNumber on to Pinpoint SMS. There is no real way however, to capture the Agent that initialized the Task. We tried writing the phoneNumber and TaskID along with a timestamp to a dynamoDB table, then invoking another lambda to look up the phoneNumber it in an inbound contact flow, but it was just ugly and did not identify the agent that originated the outbound SMS. You need someway to ID the Agent so you can “set working queue” by agent and get the incoming return message routed accordingly. Given that custom fields (as of this blog) can not be passed as a contact attribute, there was not way to add the Agent ID to the Task Template.
Another major challenge is that the CHAT API used by SMS (and chat for that matter) does not, in general, support Contact Attributes. Let us assume you want to ask the customer to enter the order number so you can look up the status. They might provide that number, but there is no way to extract that data and assign it to a Contact Attribute for further processing later in the contact flow.
Enter Option 2 (Static website to launch HTML form)
The benefit of popping an HTML form is that you can prompt the Agent to enter something to identify themselves. This would enable you to invoke a lambda function to write the phoneNumber, AgentId and timestamp and even the smsMessgeContent to a dynamoDB table for later processing. That function would also include the SDK that enables you to find the agents unique ID and also route that to the database. The entire DB item would include:
customerNumber – this would become the partition key in your dynamodb table;
smsMessageContent – the text of the outbound SMS message content;
agentID – obtained by using the Agent username and the SDK to get the agentId a unique value for each agent.
timeStamp – date and time of the item creation.
The inbound contact flow handler we could grab the Customer Number, invoke a lambda function to request the agentId so that the chat session (i.e. SMS) could be routed to the agent that originated the outbound message using the “Set Working Queue by Agent” step in the contact flow associated with the SMS number. We would also invoke a lambda function to retrieve the smsMessageContent from the stored item and assign it to a contact attribute for later use. (Developer Note: It would be possible to retrieve both the agentId and the smsMessageContent in one invocation, but parsing a JSON object in a contact flow is not worth the trouble, it is easier to make two invocations).
When the agent accepted the incoming chat, the ongoing back and forth of the chat transcript (i.e. SMS) would be captured and stored. How would the agent know what the original outbound message contained? We need a strategy for presenting that to the agent and adding it to the transcript for historical reporting, or additional processing by LENS etc. Using the Agent whisper function, we would use the contact attribute created for smsMessageContent to satisfy this requirement.
This option, in our opinion, is the optimal solution for originating an outbound SMS message and routing the return message to the agent who created the message in the first instance. It captures all the activity, makes it available to the agent and other features of the Amazon Connecct instance.
Enter option 3 Email to SMS
In this option we want to use email to launch the SMS handler using the configuration provided in Part 1. The thinking here was to use SNS rather to trigger a Lambda rather than Invoking Lambda from inside a contact flow triggered by the Chat API. Do not connect the SMS phone number direct;y to the Instance. We created two SMS handlers: one inbound Lambda to handle either an SMS that did not ordinate by an Agent. it could also handle a return message originated by an Agent.
Email Outbound
Using the email client we were able to launch an outbound lambda that would be able to parse the message and write the From (i.e. Agent ID), Subject (i.e. target recipient phone number)and a times stamp to a dynamoDB table. No need to log the message content, we would pass all the variables off to the Pinpoint SMS number.
SMS Inbound
The inbound SMS triggered the lambda which would use the phone number to index the dynamoDB table and bring back the AgentId. It might be necessary to use the AgentId to look up the Agent Name or ARN, but the result was much cleaner and seemed to work just fine! With the AgentId we were If there was no matching number in the database then the message was treated as a new incoming SMS and routed to the default workgroup set in the contact flow.
TTL
We needed a ‘garbage collector’ that could go into Dynamodb and clean out any entries that had a time stamp that exceeded whatever we set as the Time To Live (TTL) value.
Quick Connects are very useful speed dials for agents, queues and external telephone numbers but they are an actual pain in the head to administer. You quickly learn that creating a quick connect and assigning a quick connect are entirely different tasks. Quick connects are created in the Amazon Connect admin portal. The actual configuration is easy, but assigning the quick connects is twenty acts of vaudeville. Quick connects are assigned by queue. This means you have to open each queue, after you create the quick connect, and select the entry from a drop down list in the queue configuration interface. Not a big deal in a small call center, but if you have hundreds of users and dozens of queues, it is a real pain in the head.
