Fermer

août 15, 2018

Comprendre Twilio Studio Flow – Blogs performants


Twilio Studio propose un canevas où un concepteur de centre de contact maîtrisé peut capturer un flux lisible et offrir une expérience client exceptionnelle. Il existe de nombreux excellents tutoriels proposés par Twilio et ce que j'espère offrir dans cet article est la manière dont j'ai compris les flux en général, leur exécution et leur débogage. Je vais inclure un ensemble de documents de référence à la fin et je me dirigerai vers la documentation Twilio.

Trigger AKA Le point d'entrée

 Trigger Twilio Studio avec un ensemble de messages entrants et d'appels entrants

Chaque flux contient un seul widget Trigger qui sera le point d'entrée dans le système. Le déclencheur est conçu pour gérer les canaux de chat les requêtes vocales et Web. Twilio utilise le terme Omnichannel pour décrire la possibilité de cibler tous ces différents points d’entrée. Les flux bénéficient de cet état d'esprit, car ils peuvent être conçus pour gérer plus qu'une cible spécifique. Un flux pourrait initialement être conçu pour les SMS, puis intégrer des fonctionnalités vocales sans trop de perturbations. Comme Twilio ajoute des canaux, davantage de personnes / appareils peuvent atteindre un flux. Si vous avez besoin d'intégrer une nouvelle technologie, il est toujours possible de parler via des requêtes Web.

Réflexion en termes de flux

Les composants de base de tout flux sont les widgets . Le but d'un widget est d'opérer sur des informations et potentiellement générer une réponse. Cela peut être aussi simple que d'envoyer un SMS ou de dire une invite vocale, mais peut devenir plus complexe avec les demandes aux fonctions Twilio qui peuvent faire des demandes aux systèmes externes. Je préfère approcher les widgets avec le mental: Quelles sont mes entrées, sorties et où allons-nous ensuite?

Entrées

Je classe mes entrées dans les catégories suivantes: [19659012] Statique – Données codées en dur

  • Interne – Données fournies par le flux
  • Externe – Données extraites d'un système externe tel qu'une base de données, une API Web, un système CRM
  • Blended – création d'une meilleure expérience en incluant le interne / externe avec des données statiques
  • Commençant par un simple objectif de saluer le texter / appelant, nous parcourons rapidement une démonstration de chaque style et voyons comment le mélange peut améliorer l'expérience globale.

    1. Bonjour du développement de Perficient Équipe. Que pouvons-nous vous aider?
    2. Bonjour de l'équipe de développement de Perficient, nous remarquons que vous appelez de # + 1312 … .. et vous connectera avec notre équipe basée à Chicago . Que pouvons-nous vous aider?
    3. Bonjour Shelby de l'équipe de développement de Perficient, Que pouvons-nous vous aider?
    4. Bonjour Shelby de l'équipe de développement de Perficient, nous remarquons que vous appelez de # + 1312 … .. et vous connectera avec notre équipe basée à Chicago. Que pouvons-nous vous aider?

    Si vous avez un système externe avec des données client, commencez par faire une recherche avant d'essayer de démarrer l'interaction avec le client. Si les données sont là, cela peut ajouter à l'expérience globale. Gardez à l'esprit que le flux doit également gérer le cas où un client n'est pas présent. Pour éviter de répondre avec: Bonjour indéfini par l'équipe de développement de Perficient …

    Résultats

    Un sous-ensemble de widgets fournit des informations au flux pouvant être utilisé dans les widgets ultérieurs. L'utilisation des widgets HTTP Request / Run Function pour extraire des données de sources externes et transformer ces données en texte brut ou en JSON peut apporter un contexte à la personne qui appelle. Il y a une grande opportunité de commencer à tirer parti de la compréhension du langage naturel, de la NLU, des services pour traiter les réponses, que ce soit la conversation ou la voix, à la recherche d'intentions et de contextes connexes. Cela permet de réduire les flux complexes en une question de rassemblement, de NLU avec traitement et de passer à travers le système de RVI traditionnel. Accélérer le client là où il veut.

    Transitions

     Exemple de collecte avec regroupement par repli pour capturer le nom d'un client

    Chaque widget comporte des transitions pour déterminer où aller ensuite. Si un client ne parvient pas à fournir suffisamment d'informations lors d'une étape de collecte, le flux devrait-il continuer normalement? Évitez d'envoyer le client par une boucle infinie de demande d'informations si sa réponse ne correspond pas à ce que le flux attend. Si un widget prend en charge plusieurs transitions, veillez à l'évaluer pour vous assurer que, dans un cas d'échec, le flux ne laisse pas brusquement un client dans l'abîme. Les impasses dans un flux peuvent être manquées des opportunités ..

    Exécution de flux

     Page d'exécution avec deux exécutions répertoriées

    Chaque exécution d'un flux est capturée dans un ensemble de journaux par flux appelé ]. Il est pratique de les plonger pour voir comment s’est déroulé un flux et vérifier les données utilisées dans les widgets. J'ai écrit quelques fonctions Twilio pour apprendre plus tard que je ne faisais pas correctement référence à ces données dans le flux.

    Exécution simple

     Page d'exécution chargée avec les informations de débogage chargées pour le widget Say

    Dans un flux simple utilisant le widget Say / Play nous pourrions nous attendre à un l'exécution ressemble à ce qui précède. Le point d’entrée du déclencheur se produit toujours suivi des étapes attachées à ce canal. Dans ce cas, c'était un appel et nous pouvons voir que le flux passe à un widget nommé Say . Développez un widget pour voir plus d'informations sur ce que le widget a réalisé et la transition. Je n'ai pas développé les propriétés Widget & Flow car elles contiennent toutes les informations sur le flux jusqu'au point après l'exécution du widget. C'est ici qu'il faut regarder lorsqu'un widget HTTP Request / Run Function semble ne pas fonctionner comme prévu.

    Nettoyage de l'exécution

     Journal des exécutions avec une exécution d'arrêt encerclée en rouge

    Une exécution peut rarement entrer dans un état où le traitement ne semble pas être en cours. Si une exécution est active pour un numéro de téléphone, il ne pourra pas redémarrer le flux et fournira généralement une erreur dans le débogueur. Examinez l'exécution spécifique de la page Exécutions et assurez-vous que l'option Stop Execution n'est pas disponible. Pendant qu'un flux est actif, il sera possible de terminer l'exécution via ce lien. Les données avant l'arrêt sont disponibles en cliquant dans cette exécution.

    Débogage général

    Voici ce que j'ai utilisé pour déboguer des flux:

    1. Localisez l'exécution en question via Logs / Executions pour le flux spécifique
    2. Recherchez le widget qui est ne pas se comporter et développer les propriétés Widget & Flow
    3. Commencez à regarder quelles sont les entrées / sorties du widget
    4. Si le widget est une fonction d'exécution je charge la page de la fonction spécifique via Manage et réexécutez le flux à la recherche de toute sortie de console attendue
      • Arrêtez l'exécution si nécessaire
      • Ajoutez plus de consignation de console si nécessaire
    5. Le débogueur peut également fournir un contexte de dernier recours

    Common Task

     Flux agrégé avec recherche de clients, collecte de noms et agrégation de branches en hello person

    La tâche la plus courante que j'ai effectuée dans un flux est de loin celle consistant à regrouper des données de deux branches en une seule. Si le flux branche pour obtenir le nom d'un nouveau client, il peut être logique que, par la suite, cette branche puisse rejoindre le serveur principal. Pour rejoindre une branche, il faudra regrouper les données entre les deux branches. Il y a deux façons de penser à cette agrégation:

    1. Vérifier plusieurs paramètres dans le widget suivant
    2. Envoyer plusieurs paramètres dans un seul widget et récupérer A ou B

    Dans l'une des options ci-dessus, le widget doit prendre en charge plusieurs paramètres. paramètres ou avoir une déclaration complexe. Sans étape d'agrégation, un flux peut rapidement augmenter en taille pour prendre en charge les widgets en double dans chaque branche. Nous avons décidé de créer une fonction pour gérer le choix entre deux paramètres JSON comme suit:

     exports.handler = function (context, event, callback) {
        console.log (JSON.stringify (event));
        let response = new Twilio.Response ();
        response.setStatusCode (200);
        response.appendHeader ('Content-Type', 'application / json');
        
        si (event.a) {
            response.setBody (JSON.parse (event.a));
        } else if (event.b) {
            response.setBody (JSON.parse (event.b));
        } autre {
            response.setStatusCode (404);
            console.log ('a et b non définis');
        }
        
        rappel (null, réponse);
    };
    

    À mesure que le flux s'exécute, nous nous attendrions à ce que A représente le nom d'un nouveau client et B représente le nom d'un client existant. Nous récupérons B au début de la consultation du client. Si nous ne les trouvons pas, nous devons exécuter le chemin get A . Une fois que nous avons les deux, nous pouvons agréger dans notre fonction et nous nous attendons à ce que le flux atteigne la fonction avec l'une des deux valeurs définies et renvoie ce résultat sous forme de données agrégées. Les données agrégées alimentent ensuite à nouveau la branche principale et A et B ont tous deux le même message.

    Références

    				
    				
    				
    				
    
    				
    			




    Source link