Utilisation de SMS avec Amazon Connect Chat

Perficient a récemment conclu un hackathon de 3 jours pour créer des solutions de centre de contact répondant à la crise du COVID-19 (Coronavirus). En utilisant Amazon Connect Chat mon équipe et moi avons implémenté une solution pour la déviation SMS. Nous avons traité le scénario suivant:

1. Le client appelle dans un centre d'appels à forte demande.
2. Le client est invité à indiquer que son temps d'attente est supérieur à 2 heures et se voit proposer de passer au canal SMS.
3. Le client choisit de utilise SMS et est placé dans une file d'attente dédiée aux SMS.
4. Le client peut envoyer des SMS à un chatbot en attendant dans la file d'attente.
5. Le client se connecte et discute avec un agent par SMS.

Pour ceux familier avec les API Amazon Connect Chat, vous savez qu'elles ne sont pas conçues pour le canal SMS. Voir cet article de blog pour un rappel rapide sur le fonctionnement des API de chat.

Les API de chat s'appuient sur WebSockets pour relayer les messages de Connect au client. Les API sont destinées à une application Web où le WebSocket peut être stocké dans le navigateur du client. Pour prendre en charge SMS, nous devions créer un service qui maintenait des WebSockets actifs pour tous les clients entrants.

Voici ce que nous avons créé.

Nous avons hébergé un service Node.js , appelé service SMS, dans une instance Amazon EC2 qui maintenait les connexions client. Nous nous sommes appuyés sur le gestionnaire de processus PM2 pour exécuter indéfiniment le service SMS.

La connexion client est établie lorsque le client appelle dans l'IVR et choisit de passer à SMS. Amazon Connect envoie ensuite un texte d'adhésion au client via AWS Lambda. Une fois que le client a répondu, le service SMS est responsable de la communication bidirectionnelle avec Amazon Connect, Amazon Lex et le client. Le service assure efficacement le proxy des messages de Connect et Lex vers SMS.

Nous avons intégré Amazon Pinpoint pour communiquer avec un client par SMS. Les SMS sortants sont gérés directement par l'API Pinpoint. Le SMS entrant est acheminé via une file d'attente Amazon SQS . Le service SMS a interrogé la file d'attente pour les messages entrants. Une fois un message reçu, le service a décidé si le message devait être acheminé vers Amazon Connect ou Amazon Lex.

Nous nous sommes appuyés sur les API de conversation pour communiquer avec Amazon Connect. Le service SMS a stocké une carte en mémoire du numéro de téléphone du client sur le WebSocket créé par les API de conversation. Cela a permis au service d'envoyer et de recevoir des messages vers Amazon Connect. Nous nous sommes également appuyés sur les API de conversation pour déterminer si un client était dans la file d'attente ou non en fonction des messages «marqueurs» envoyés par nos flux de contacts.

Pendant qu'un client attend dans la file d'attente, le service SMS achemine les SMS du client vers Lex. Lex fournit une API PostText pour gérer les communications bidirectionnelles. Je vais expliquer comment nous avons créé notre bot Lex.

An Side: Scraping a FAQ to create a Lex Bot

Pour créer un bot Lex pour répondre aux questions de base sur la crise COVID-19, nous avons gratté le CDC Page FAQ . Cette idée a été introduite à la dernière minute dans notre projet. Nous avons fait ce qui suit:

1. Grattez les paires de questions et réponses à partir de la page FAQ CDC et stockez chaque paire dans une table DynamoDb avec un identifiant unique.
2. Écrivez et exécutez une Lambda ETL pour créer une nouvelle intention pour chaque paire de questions et réponses, où le nom de l'intention est l'identifiant et la question est le seul énoncé.
3. Créez une Lambda de réalisation qui interroge la table Dynamo pour la réponse lorsqu'une intention est remplie.

Évolutivité

Vous vous demandez peut-être comment ce service peut évoluer. Et c'est une bonne question!

L'exécution d'un service qui gère WebSockets pour tous les clients nécessitera une mise à l'échelle sophistiquée. Nous n'avons pas résolu le problème d'évolutivité dans le cadre du hackathon, mais nous avons quelques idées. D'une part, mettez à l'échelle l'instance EC2 en utilisant AWS Auto Scale! Nous pouvons choisir d'ajouter plus d'instances EC2 si nous implémentons une instance EC2 de «contrôleur».

Une autre idée est de passer à sans serveur l'architecture! Nous voulons rechercher des options pour utiliser une architecture sans serveur, y compris l'option d'implémenter un canal SMS direct agent-client. Aller sans serveur nous permettra de faire évoluer notre solution en mode natif. Nous continuons d'étudier cette option.

Notre équipe a créé un service qui permet aux clients de communiquer avec Amazon Connect via SMS. Nous pensons que cette solution peut réduire le volume élevé d'appels rencontrés dans les centres de contact pendant cette crise mondiale et à l'avenir.

Nous aimerions étendre notre solution pour prendre en charge des canaux supplémentaires tels que Facebook Messenger. Recherchez cet ajout dans un prochain article de blog!