Text-Based Channels In Twilio Flex – Routing the Interaction

Let’s explore another consideration for Flex text-based communication channels from my introductory post: Routing the Interaction with Flex.

In this post, we’ll look at the second focus area…

• How does that interaction get routed on the Flex platform so I can get it to the right agent or expert? 

Routing the Interaction to Flex

Let’s go through a high-level overview of how interactions get routed to Flex from the customer, without getting super technical. In most cases, text-based interactions out of the box are enabled by something called a Flex Flow. A Flex Flow is a configuration entry and is part of initial Task Channel setup. Twilio sets up some of these for you when you install Flex in a project, including SMS and web chat.

Originally these were a bit hidden, but they are now being surfaced on the Flex Messaging screen in the console. You can change which Studio Flow each handler points to and this updates the Flex Flow for that channel. There is a good overview in the Flex messaging docs if you want to dig deeper.

Like most things Flex, you can also interact with Flex Flows using an API and this is probably how most developers will work with them. You can just take a look (https://flex-api.twilio.com/v1/FlexFlows, use your Account SID and Token for security) if nothing else. It’s interesting to see all the different Twilio services that come into play.

More About Flex Flows

A Flex Flow configuration is effectively the glue connecting the Flex Chat Service, a Studio Flow, a channel type and optionally a contact uri. The contact uri is used for channels like SMS, where there is a configured phone number you message. Text-based channels that don’t use a number can have a null contact uri.

In the initial versions of Flex, there was really just one type of Flex Flow that mapped into a Studio Flow (integrationType = studio). As the Channels orchestration layer has matured, Twilio has recently started adding more integration types. If you haven’t reviewed the docs in awhile, there is brand new documentation describing new functionality. The two newest integration types are Task and web hook, each of which put their own twist on how you begin to interact with a customer.

Channels Tied To A Phone Number Identity

For channels that work over standard mobile numbers (SMS, WhatsApp, etc.), Flex passes the inbound messaging into a Proxy session. This allows the Flex platform to perform some orchestration to enable the communication to start. It also sets up the connection between the telephony boundary and the agent side. Both can then continue to send messages via the Chat Channel inside Flex.

Using the Flex Flow configuration, Flex can set up various services needed for the integration type. Actions for the “studio” type include Chat Channel setup, routing the first message to a Studio Flow and creating some security context for the user in the Chat Channel.

Certain channels may require additional coordination with the platform vendor, such as WhatsApp, Apple Business Chat and Facebook Messenger.

Web Chat Interaction

For web chat, the  customer side of the communication is effectively anonymous. I’m assuming you are using the web chat sample code or hosted version that Twilio provides, although you can create your own versions of this interaction. When a customer starts messaging, the Flex web chat code first requests an auth token. This creates an identity in the Flex Chat Service with very limited rights. Other than that, it works much the same way as the process above.

With web chat, you can’t easily tie the user’s identity back to something concrete like a phone number. You can ask for other identifying information in the web chat pre-engagement form, such as a phone number, email address or customer id. This must be verified through other means before providing any personal information back to the user, but does allow you to perform data dips in Studio for context or verification purposes.

Verifying User Identity

Speaking of user identity and anonymous communications, treat chat communications as anonymous by default. You should certainly take care before providing sensitive information back to the customer. Even mobile numbers change frequently and it is no longer sufficient to just look up the phone number in your CRM or customer profile system and assume that the person on the other end is verified. It’s helpful to think through how you would verify the customer for each type of text-based channel you want to enable. Audit the types of information being provided and make sure agents are trained in compliance with GDPR, HIPAA or other standards. Bring in your privacy and security teams early when designing your Flex text-based channel workflows and usage.

Authenticated communication can be a good option here. This is where you know who the customer is based on a separate authentication/authorization flow already used in your application. It is possible to have authenticated web chat with some custom work. I believe Twilio is working on some ways to make this more of a native experience. In a similar fashion, custom Task Channels can be used in your mobile applications or other applications used by customers. With these interactions, you can also force these channels to be authenticated from the start.

Custom Task Channels

if you wish to create your own text-based channel, the Channels API combined with a custom Flex Flow can cover most use cases. Twilio has made significant progress in this area since Flex went GA last fall. There are some good details in the docs. You can also use existing APIs, web hooks and other services to orchestrate this behavior yourself for complete customization.

AutoPilot is another option you can use with text-based channels to facilitate more of a self-service or bot type of interaction. AutoPilot uses its own version of these platform tools, but many of the same principles apply.

Typically you start by creating your own Task Channel. You then create a separate FlexFlow for your custom channel. This will show up on the Messaging screen for “studio” integration types. There may be some UI work needed to support your custom Task Channel in the agent desktop. However, if you are happy with using the default chat experience for your channel you can support this with just a few lines of code.

Next Steps

Is your company interested in investigating a text-based channel not natively supported by Flex? Or would you just like a better understanding of the native text-based channel offerings in Flex? Perficient would love to discuss solutions with you and help you come up with an implementation plan.